Администрирование · 10 мин
Как изменить права пользователя в 1С 8
Как изменить права пользователей в 1С 8.3: настройка ролей, профилей групп доступа, ограничение на уровне записей и проверка результата.
Изменение прав в 1С 8 решает две задачи: дать сотруднику доступ к нужным документам и отчётам и, наоборот, закрыть лишнее — чтобы случайное или намеренное действие не испортило данные. Способ настройки зависит от того, какая у вас конфигурация: в типовых решениях (Бухгалтерия, ЗУП, Управление торговлей) используется механизм профилей групп доступа, а в самописных и старых конфигурациях права назначаются напрямую через роли в конфигураторе.
Базовый принцип платформы 1С:Предприятие 8 прост: каждому пользователю назначаются роли, а роль — это набор прав на объекты метаданных (справочники, документы, регистры, отчёты). Итоговые права пользователя складываются как объединение прав всех его ролей. Поэтому «убрать» право можно только одним способом — исключить роль, которая его даёт, а не добавить «запрещающую» роль: таких в платформе нет.
Перед любыми изменениями убедитесь, что у вас есть полные права (роль «Полные права» или административный доступ), свежая резервная копия базы и возможность проверить результат под учётной записью того пользователя, чьи права меняете. Ошибка в настройке прав может заблокировать работу целого отдела или, наоборот, открыть доступ к зарплате и финансам посторонним.
Как устроены права в 1С 8: роли, профили и группы доступа
Роль — это элемент конфигурации, в котором разработчик заранее определил, какие действия разрешены: чтение, добавление, изменение, удаление конкретных объектов, а также использование отчётов и обработок. Пользователю назначается одна или несколько ролей, и платформа при каждом обращении к объекту проверяет, есть ли хотя бы у одной роли нужное право.
В типовых конфигурациях поверх ролей работает библиотека стандартных подсистем (БСП): администратор не трогает конфигуратор, а собирает «профили групп доступа». Профиль — это именованный набор ролей (например, «Менеджер по продажам», «Кассир»), а пользователь включается в группу доступа, которой назначен профиль. Это удобнее: одно изменение профиля сразу действует на всех его участников.
Дополнительно существует механизм RLS — ограничение доступа на уровне записей. Он позволяет, например, показывать менеджеру только документы его организации или склада, хотя право чтения документов у него есть в целом. RLS настраивается в типовых конфигурациях через группы доступа и значения доступа (организации, склады, контрагенты).
Изменение прав в типовой конфигурации через профили доступа
Откройте раздел «Администрирование» → «Настройки пользователей и прав». Убедитесь, что включён флажок «Группы доступа» — без него механизм профилей не активен. Далее перейдите к списку пользователей, выберите нужного сотрудника и посмотрите, в какие группы доступа он входит.
Если нужно дать пользователю стандартный набор прав, проще всего добавить его в существующую группу с подходящим профилем. Откройте «Профили групп доступа», найдите подходящий профиль (или создайте копию типового через «Скопировать») и на вкладке «Пользователи» или через группу доступа добавьте сотрудника. Изменения применяются после перезахода пользователя в программу либо после обновления его сеанса.
Если типовой профиль не подходит — например, менеджеру нужно запретить изменение цен, оставив остальные права, — создайте собственный профиль. Скопируйте ближайший типовой, откройте его и на закладке «Роли» снимите или установите флажки на нужных ролях. Названия ролей обычно говорящие: «Добавление изменение номенклатуры», «Чтение данных о ценах» и т. п. Сохраните профиль и назначьте его пользователю вместо типового.
- 1Откройте Администрирование → Настройки пользователей и прав и включите группы доступа
- 2Найдите пользователя и определите его текущие группы доступа и профили
- 3Скопируйте подходящий типовой профиль и скорректируйте состав ролей
- 4Назначьте новый профиль пользователю, исключив его из старой группы
- 5Попросите пользователя перезайти в программу и проверьте доступ к нужным и запрещённым объектам
Настройка прав через конфигуратор
В конфигурациях без БСП, а также для тонкой настройки права задаются напрямую. Откройте конфигуратор, перейдите в «Администрирование» → «Пользователи», выберите пользователя и откройте вкладку «Прочие» (или «Роли» — зависит от версии платформы). Здесь отображается список всех ролей конфигурации: установите или снимите флажки и сохраните.
Чтобы понять, какие права даёт конкретная роль, откройте её в дереве конфигурации (Общие → Роли) двойным щелчком. В редакторе роли слева — список объектов метаданных, справа — матрица прав: чтение, добавление, изменение, удаление, просмотр, интерактивное удаление и другие. Создавать собственную роль разумно, когда ни одна типовая не подходит по составу.
Изменение ролей в конфигураторе требует обновления конфигурации базы данных (F7). Для файловой базы это возможно только при отсутствии активных сеансов, для клиент-серверной — в монопольном режиме или в режиме динамического обновления, который подходит не для всех изменений. Планируйте такие работы на нерабочее время.
Ограничение доступа на уровне записей (RLS)
Роли отвечают на вопрос «можно ли работать с документами вообще», а RLS — «с какими именно документами». Типичный сценарий: в базе несколько организаций, и бухгалтер по одному юрлицу не должен видеть данные другого. В типовых конфигурациях это настраивается без программирования.
Перейдите в настройки групп доступа и включите ограничение по нужному виду доступа — например, «Организации» или «Склады». Затем в карточке пользователя или его группы доступа укажите разрешённые значения. После этого платформа будет автоматически дописывать условия к запросам, и пользователь увидит только «свои» записи в списках, отчётах и подборах.
Учтите: RLS замедляет выполнение запросов, особенно при большом числе видов доступа и сложных шаблонах ограничений. Включайте только те виды ограничений, которые действительно нужны, и проверяйте скорость открытия списков под учётной записью ограниченного пользователя.
Проверка результата и типичные ошибки
Единственный надёжный способ проверить права — войти в базу под учётной записью пользователя и пройти его рабочие сценарии: открыть журнал документов, провести документ, сформировать отчёт, попробовать открыть запрещённый раздел. В некоторых типовых конфигурациях есть отчёт «Права доступа» или возможность посмотреть права от имени пользователя — используйте её для первичной диагностики.
Частая ситуация: право убрали из профиля, а доступ остался. Причина почти всегда в том, что пользователь входит ещё в одну группу доступа или ему назначен второй профиль, где это право есть. Поскольку права суммируются, ищите все источники назначения, а не только тот, который меняли.
Как проверить результат
Открываются нужные разделы, документы проводятся
Ошибка 'Нарушение прав доступа' при штатной операции
Объект скрыт из интерфейса или доступ запрещён
Объект открывается и доступен для изменения
Открытие за привычное время
Резкое замедление после включения RLS
Настройки прав сохранились
Права сбросились к типовым — правили типовой объект
Когда нужны полные права и как выдать их безопасно
Полные права (роль «Полные права» или профиль «Администратор») снимают почти все ограничения, но не заменяют административные права на уровне платформы: для работы с конфигуратором, управления пользователями в некоторых сценариях и обновления конфигурации нужны именно административные права, которые назначаются в списке пользователей информационной базы.
Выдавайте полные права по принципу минимально необходимого: только тем, кто администрирует систему, и желательно под отдельной учётной записью, а не той, под которой человек ведёт ежедневный учёт. Это упрощает разбор инцидентов по журналу регистрации и снижает риск случайного повреждения данных.
Если сотруднику «не хватает прав» на одну операцию, не выдавайте полные права «на время» — найдите, какой именно роли не хватает, и добавьте её точечно. Практика временных полных прав почти всегда заканчивается тем, что они остаются навсегда.
Перед изменением прав зафиксируйте текущее состояние: сделайте скриншоты состава профилей и групп доступа пользователя или выгрузите настройки. Если новая схема не сработает, вы сможете быстро откатиться к исходной конфигурации, не восстанавливая всю базу из копии.
Частые вопросы
Почему пользователь не видит изменений в правах после настройки?
Чаще всего он продолжает работать в старом сеансе: права применяются при входе в базу. Попросите его полностью выйти и зайти заново. Если не помогло — проверьте, не входит ли он в другую группу доступа с более широким профилем.
Можно ли запретить пользователю только удаление, оставив изменение?
Да. В роли или профиле право «удаление» задаётся отдельно от «изменения». Уберите роли, дающие удаление (в том числе интерактивное), оставив роли на добавление и изменение. Проверьте также отмену проведения документов — это отдельное право.
Как узнать, какой роли не хватает для операции?
Включите технологический журнал или изучите текст ошибки «Нарушение прав доступа» — в нём указан объект и вид права. Далее в конфигураторе через поиск ролей, дающих это право на этот объект, найдите подходящую роль и добавьте её в профиль.
Чем отличаются права в файловой и клиент-серверной базе?
Сам механизм ролей и профилей одинаков. Различия в администрировании: в клиент-серверном варианте добавляются права на уровне СУБД и кластера серверов 1С, а обновление конфигурации и управление сеансами выполняется через консоль кластера.
Что делать, если прав в типовых профилях не хватает для нестандартной задачи?
Создайте собственную роль в расширении конфигурации, не меняя основную конфигурацию: так настройка сохранится при обновлениях. Затем добавьте эту роль в профиль доступа или назначьте пользователю напрямую.
Опасно ли давать бухгалтеру право на монопольный режим?
Само по себе право не опасно, но пользователь сможет блокировать работу остальных, запуская операции в монопольном режиме (например, удаление помеченных объектов). Выдавайте его только тем, кто понимает последствия, и согласуйте регламент таких операций.
Что важно запомнить
Права в 1С 8 складываются из ролей и только суммируются. В типовых конфигурациях работайте через копии профилей групп доступа, в остальных — через роли в конфигураторе. Изменения применяются после перезахода пользователя, а результат проверяется только под его учётной записью. Перед правками делайте резервную копию и фиксируйте исходные настройки.