Какие права на самом деле есть у сотрудника в базе 1С и откуда они взялись

Роли пользователя в 1С проверяют двумя способами. В Конфигураторе: Администрирование → Пользователи, откройте пользователя и перейдите на вкладку Прочие — там отмечены его роли. В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) удобнее проверять в режиме Предприятия: карточка пользователя → Права доступа , а для детального разбора — отчёт «Анализ прав доступа».

Обычно вопрос возникает, когда бухгалтер жалуется на Нарушение прав доступа! или, наоборот, видит то, чего видеть не должен. Чтобы разобраться, мало увидеть список ролей: нужно найти конкретное право и понять, какая роль или группа доступа его выдала.

Как в 1С устроены права: роль, профиль, группа доступа

Прежде чем проверять, полезно понимать, из чего складываются права. В 1С:Предприятии 8.3 их четыре слоя.

• 🔑 Роль — объект конфигурации. В ней разработчик отмечает, что можно делать с каждым объектом: чтение, добавление, изменение, удаление, проведение, просмотр. Роли назначаются пользователю информационной базы.
• 📦 Профиль групп доступа — набор ролей под типовую должность: «Бухгалтер», «Кадровик», «Менеджер по продажам». Есть только в конфигурациях на Библиотеке стандартных подсистем (БСП).
• 👥 Группа доступа — связка «профиль + список пользователей + ограничения». Например, профиль «Бухгалтер» для сотрудников ООО «Альфа» только по этой организации.
• 🧱 Ограничение на уровне записей (RLS) — фильтр внутри роли. Роль разрешает читать документы реализации, а RLS оставляет видимыми только документы своей организации или склада.

Итоговые права — это объединение всех ролей пользователя. Роли складываются, а не вычитаются: если хотя бы одна роль даёт право изменять документ, пользователь его изменит.

Роли пользователя в Конфигураторе

Конфигуратор показывает «сырые» роли — то, что реально записано у пользователя информационной базы. Это самый надёжный источник, если результат отчётов вызывает сомнения.

Роли конкретного пользователя

1. Откройте базу в режиме Конфигуратор под пользователем с административными правами.
2. Выберите Администрирование → Пользователи.
3. Дважды щёлкните по нужному пользователю.
4. Перейдите на вкладку Прочие. В списке Доступные роли галочками отмечены роли этого пользователя.

На вкладке Основные заодно проверьте способ входа: аутентификация 1С:Предприятия, аутентификация операционной системы, флажок «Показывать в списке выбора». Проблемы со входом часто путают с проблемами прав.

Что разрешает конкретная роль

Роль сама по себе — просто название. Чтобы увидеть её содержимое:

1. Откройте конфигурацию: Конфигурация → Открыть конфигурацию.
2. В дереве раскройте Общие → Роли.
3. Откройте нужную роль. Слева — дерево объектов, справа — права на выбранный объект.

В роли же видны шаблоны ограничений и тексты условий RLS. Если у роли на документ стоит право «Чтение» с условием, значит пользователь увидит не все документы.

Сводная таблица по всем ролям

Когда ролей десятки, открывать каждую долго. В дереве конфигурации щёлкните правой кнопкой по ветке Роли и выберите Все роли. Откроется таблица: строки — объекты конфигурации, столбцы — роли, на пересечении — права. Так быстро видно, какая роль даёт право проводить, например, документ «Реализация (акты, накладные, УПД)».

Отчёт «Анализ прав доступа»: кто что может и почему

В конфигурациях на БСП есть отчёт «Анализ прав доступа». Он отвечает на два вопроса, на которые Конфигуратор прямо не отвечает:

• 📄 какие права у пользователя на каждую таблицу базы — справочник, документ, регистр;
• 🔍 через какую группу доступа и какой профиль пришло каждое право.

Где найти отчёт

Проще всего открыть его из карточки пользователя: кнопка Права доступа, а в открывшейся форме — команда отчёта по правам. Второй путь — через полный список объектов: включите команду Все функции в главном меню (Сервис и настройки → Параметры → Отображать команду «Все функции»), затем Все функции → Отчеты → Анализ прав доступа.

Как читать результат

1. Укажите пользователя (или группу пользователей) в отборе.
2. Сформируйте отчёт.
3. В строках будут объекты метаданных, в колонках — права: чтение, изменение, добавление, проведение и т. д.
4. Отметка об ограничении означает, что право есть, но действует RLS — пользователь видит часть записей.
5. Расшифровка по ячейке покажет, какая группа доступа и какой профиль дали это право.

Отчёт работает и в обратную сторону: выберите объект (например, справочник «Контрагенты») и получите список всех, кто может его изменить. Это удобно перед аудитом или после увольнения сотрудника.

Как посмотреть роли и группы доступа в режиме Предприятия

В типовых решениях на БСП пути к пользователям стабильны:

Дальше одинаково для всех трёх.

Шаг 1. Карточка пользователя

Откройте пользователя. Проверьте флажок входа в программу: если он снят, пользователь не войдёт вообще, и смотреть права бессмысленно.

Шаг 2. Кнопка «Права доступа»

Нажмите Права доступа. Откроется список групп доступа, в которые входит сотрудник. Галочка у группы — участие. Именно здесь чаще всего находится причина «не вижу документ»: сотрудника забыли включить в нужную группу.

Шаг 3. Профиль группы

Откройте группу доступа, затем её профиль. В профиле есть список разрешённых действий (ролей) — это и есть роли, которые получит каждый участник группы. Поставляемые профили («Бухгалтер», «Главный бухгалтер», «Администратор») менять нельзя — для правок их копируют.

Шаг 4. Ограничения группы

На вкладке ограничений группы доступа указаны значения: какие организации, склады или виды документов доступны. Пустой список с режимом «Все разрешены» означает отсутствие ограничений. Режим «Все запрещены» без значений — пользователь не увидит ничего по этому виду.

Сам флажок RLS в БП 3.0 включается в Администрирование → Настройки пользователей и прав (параметр ограничения доступа на уровне записей). Если он выключен, ограничения по организациям не работают вовсе.

Файловая и клиент-серверная база: что проверять сверх ролей

Роли хранятся в самой информационной базе, поэтому проверка ролей одинакова в обоих вариантах. Различается всё, что вокруг.

Файловая база

• 📁 Права Windows на каталог базы. Пользователю нужны права на чтение и запись в папку с файлом 1Cv8.1CD, иначе база не откроется или откроется с ошибкой блокировки — и это легко принять за нехватку ролей.
• 🔐 Защиты на уровне сервера нет. Любой, кто может скопировать файл базы, может открыть копию и разбираться с ней на своём компьютере. Роли от этого не спасают.

Клиент-серверная база

• 🖥 Администраторы кластера и администраторы информационной базы в кластере — отдельный уровень. Они управляются в консоли администрирования серверов, а не ролями конфигурации.
• 🗄 Пользователь СУБД (MS SQL, PostgreSQL), под которым сервер 1С подключается к базе, не имеет отношения к пользователям 1С. Сотрудник не входит в СУБД под своим именем.
• 👤 Аутентификация операционной системы: проверьте, что в карточке указан правильный доменный пользователь в формате \\ДОМЕН\имя. При ошибке сотрудник попадёт в окно ввода пароля.

Почему роль есть, а доступа нет: частые ошибки

Типичная картина: в Конфигураторе галочка стоит, а сотрудник получает отказ. Или наоборот. Разберите по симптому.

Ещё одна ловушка — первый пользователь. При создании первого пользователя в пустом списке платформа требует, чтобы у кого-то из пользователей были административные права. Если назначить первому пользователю только роль «Бухгалтер», база не даст сохранить такой список.

Проверка ролей кодом и внешней обработкой

Когда пользователей больше двадцати, открывать карточки по одной неудобно. Список ролей всех сотрудников выгружает небольшая внешняя обработка.

Встроенные функции для проверки прав

• РольДоступна("ИмяРоли") — проверяет роль у текущего пользователя сеанса.
• ПравоДоступа("Проведение", Метаданные.Документы.ИмяДокумента, ПользовательИБ) — проверяет конкретное право на объект у указанного пользователя информационной базы.
• ПользовательИБ.Роли.Содержит(Метаданные.Роли.ИмяРоли) — проверяет наличие роли в списке ролей пользователя.

Пример обработки: роли всех пользователей

Создайте внешнюю обработку, добавьте на форму реквизит Результат (строка, неограниченной длины, многострочное поле) и команду. В модуле формы:

&НаКлиенте
Процедура ПоказатьРоли(Команда)
	ПоказатьРолиНаСервере();
КонецПроцедуры

&НаСервере
Процедура ПоказатьРолиНаСервере()
	Строки = Новый Массив;
	Для Каждого ПользовательИБ Из ПользователиИнформационнойБазы.ПолучитьПользователей() Цикл
		Строки.Добавить(ПользовательИБ.Имя);
		Если ПользовательИБ.Роли.Количество() = 0 Тогда
			Строки.Добавить("    (ролей нет)");
		КонецЕсли;
		Для Каждого Роль Из ПользовательИБ.Роли Цикл
			Представление = ?(ЗначениеЗаполнено(Роль.Синоним), Роль.Синоним, Роль.Имя);
			Строки.Добавить("    " + Представление + " [" + Роль.Имя + "]");
		КонецЦикла;
	КонецЦикла;
	Результат = СтрСоединить(Строки, Символы.ПС);
КонецПроцедуры

Обработку запускают под пользователем с административными правами: получить список пользователей информационной базы без них нельзя. Код выполняется на сервере, поэтому работает и в файловой, и в клиент-серверной базе.

Чтобы проверить одно конкретное право у всех, замените внутренний цикл строкой с ПравоДоступа:

Можно = ПравоДоступа("Изменение", Метаданные.Справочники.Контрагенты, ПользовательИБ);
Строки.Добавить(ПользовательИБ.Имя + ": " + ?(Можно, "может изменять", "нет права"));

Права на запуск обработки в защищённой базе

В типовых конфигурациях внешнюю обработку открывают через Файл → Открыть только пользователи с правом интерактивного открытия внешних обработок. Остальным её подключают через справочник дополнительных отчётов и обработок. Для разовой проверки администратору хватает первого способа.