Роли, профили и группы доступа: что править администратору 1С 8.3
Содержание
Права пользователя в типовых конфигурациях 1С 8.3 (Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11) меняют в режиме Предприятие: Администрирование → Настройки пользователей и прав → Группы доступа. Пользователя включают в нужную группу или исключают из неё, а состав прав группы задаёт её профиль. Изменения вступают в силу, когда пользователь заново войдёт в программу.
Частое заблуждение — что изменить права пользователя в 1С можно галочками ролей в Конфигураторе. В типовых базах это не работает : программа сама пересчитывает роли по группам доступа и затирает ручные отметки. Конфигуратор нужен для другого — создавать новые роли и править ограничения на уровне записей.
Как устроены права: пользователь, роль, профиль, группа доступа
В 1С 8.3 права собраны в несколько слоёв. Если понимать, какой слой за что отвечает, менять доступ становится просто.
| Объект | Где живёт | За что отвечает |
|---|---|---|
| 🔑 Роль | Конфигуратор, ветка Общие → Роли | Набор прав на объекты: чтение, добавление, изменение, проведение, удаление |
| 📦 Профиль группы доступа | Режим Предприятие | Набор ролей под должность: «Бухгалтер», «Кадровик», «Менеджер по продажам» |
| 👥 Группа доступа | Режим Предприятие | Профиль + список участников + ограничения (например, по организациям) |
| 👤 Пользователь | Справочник «Пользователи» | Получает сумму прав всех групп, в которые входит |
Права в 1С только складываются. Если пользователь состоит в двух группах, он получает всё, что разрешает каждая из них. Запретить что-то одной группой, когда другая это разрешает, нельзя.
Отсюда простое правило. Чтобы забрать право, ищите, какая группа его даёт, и убирайте пользователя из неё. Добавлять «запрещающую» группу бесполезно.
Роль «Полные права» перекрывает любые ограничения. Пока пользователь входит в группу «Администраторы», остальные настройки на него не действуют.
Права пользователя в режиме Предприятие: группы и профили
Это основной способ, и в 9 случаях из 10 его достаточно. Работать нужно под пользователем с полными правами.
Шаг 1. Откройте пользователя
- Перейдите в
Администрирование → Настройки пользователей и прав. - Откройте список
Пользователии найдите сотрудника. - В карточке нажмите ссылку
Права доступа.
Откроется список групп доступа с флажками. Флажок стоит у тех групп, в которые сотрудник уже входит.
Шаг 2. Добавьте или уберите группу
- ✅ Чтобы расширить права, отметьте нужную группу: «Бухгалтер», «Кадровик» и т.д.
- ❌ Чтобы урезать права, снимите флажок с лишней группы.
- 💾 Нажмите
Записать и закрыть.
То же самое можно сделать с другой стороны: открыть группу в списке Группы доступа и добавить сотрудника на вкладке участников. Результат одинаковый.
Шаг 3. Если готовых профилей не хватает — создайте свой
Поставляемые профили («Бухгалтер», «Главный бухгалтер» и другие) менять нельзя: при обновлении конфигурации их состав восстанавливается. Поэтому свой профиль делают копией:
- Откройте
Профили групп доступа. - Выделите похожий поставляемый профиль и скопируйте его клавишей
F9. - Задайте понятное имя, например «Бухгалтер без зарплаты».
- На вкладке ролей снимите лишние роли и добавьте недостающие.
- Запишите профиль и создайте по нему новую группу доступа.
Не снимайте у профиля базовые роли вроде «Базовые права». Без них пользователь не сможет даже запустить программу.
Особенность Бухгалтерии 3.0
В БП 3.0 часто включён упрощённый режим настройки прав. Тогда в карточке пользователя по ссылке Права доступа вы увидите не группы, а сразу список профилей с флажками. Логика та же: отметили профиль — сотрудник получил его роли.
Когда сотрудников много: группы пользователей
Если права меняют сразу десятку менеджеров, добавлять каждого в группу доступа по одному долго. В УТ 11 и ЗУП 3.1 есть справочник групп пользователей (в БП 3.0 его включают в настройках пользователей и прав). Участником группы доступа можно сделать не человека, а целую группу пользователей.
Схема получается такая:
- Создайте группу пользователей «Отдел продаж» и включите туда менеджеров.
- В группе доступа «Менеджеры по продажам» добавьте участником эту группу.
- Новый менеджер получает права сразу, как только его добавили в «Отдел продаж».
Когда сотрудник переходит в другой отдел, его просто переносят между группами пользователей. Группы доступа при этом не трогают.
Шаг 4. Попросите пользователя перезайти
Роли пользователя считываются в момент входа. Пока сотрудник не закрыл программу, он работает со старыми правами. Это самая частая причина жалобы «права поменяли, а ничего не изменилось».
Изменение ролей в Конфигураторе
В Конфигуратор идут в двух случаях: база нетиповая, без групп доступа, или нужна роль, которой нет ни в одном профиле.
Назначение ролей пользователю
- Откройте базу в Конфигураторе.
- Перейдите в
Администрирование → Пользователи. - Откройте пользователя, вкладка
Прочие. - Отметьте роли и нажмите
ОК.
В самописных конфигурациях этого достаточно. В типовых на основе Библиотеки стандартных подсистем такие отметки исчезнут при ближайшем пересчёте прав. Для типовых используйте способ из предыдущего раздела.
Создание своей роли без снятия с поддержки
Править типовые роли напрямую — плохая идея. Конфигурацию придётся снять с поддержки, и каждое обновление превратится в ручное сравнение.
Правильный путь — расширение конфигурации :
- В Конфигураторе откройте
Конфигурация → Расширения конфигурациии создайте расширение. - В дереве расширения добавьте новую роль в ветку
Роли. - Отметьте в ней только нужные права, например чтение и просмотр конкретного отчёта.
- Обновите расширение в базе.
- В режиме Предприятие откройте свой (скопированный) профиль и добавьте туда новую роль.
Флажки в редакторе роли
В редакторе роли внизу есть три флажка, о которых часто забывают:
| Флажок | Что делает |
|---|---|
| Устанавливать права для новых объектов | Новые объекты метаданных сразу получают права в этой роли |
| Устанавливать права для реквизитов и табличных частей по умолчанию | Реквизиты наследуют права объекта |
| Независимые права подчинённых объектов | Права на реквизиты задаются отдельно от объекта |
Для узкой роли первый флажок лучше снять. Иначе при доработке конфигурации роль незаметно «разрастётся».
Ограничение доступа к данным на уровне записей (RLS)
Роль отвечает на вопрос «можно ли работать с документами реализации». Ограничение на уровне записей уточняет: «с какими именно» — например, только по своей организации или своему складу.
Включение в типовой конфигурации
- В
Администрирование → Настройки пользователей и праввключите флажокОграничивать доступ на уровне записей. - Откройте нужную группу доступа.
- На вкладке ограничений выберите вид доступа, например «Организации».
- Укажите режим: разрешены только перечисленные значения или все, кроме перечисленных.
- Добавьте значения и запишите группу.
Пример. В базе три организации: ООО «Север», ООО «Юг» и ИП Петров. Бухгалтеру группы «Бухгалтер Юг» оставляем только ООО «Юг». Он увидит документы этой организации, а документы двух других из списков исчезнут.
После включения ограничений первый пересчёт доступа на большой базе может идти долго и нагружает сервер. Включайте флажок вечером или в выходной, когда пользователей в базе мало.
Какие виды доступа доступны, зависит от конфигурации. В БП 3.0 это прежде всего организации. В УТ 11 и ЗУП 3.1 список шире: склады, партнёры, подразделения, физические лица.
Как это выглядит внутри
В Конфигураторе ограничение задаётся в роли, в колонке ограничения доступа к данным для права «Чтение» или «Изменение». Это текст на языке запросов, например:
ГДЕ Организация = &ТекущаяОрганизация
В типовых конфигурациях руками этот текст не пишут: используются шаблоны ограничений, которые подставляет Библиотека стандартных подсистем. Свой RLS в самописной базе пишите, только если хорошо знаете язык запросов. Ошибка в условии либо откроет лишнее, либо спрячет нужные записи у всех пользователей роли.
Как проверить права пользователя и найти, чего не хватает
После изменения прав стоит убедиться, что получилось именно то, что задумано.
Отчёт по правам
В карточке пользователя по ссылке Права доступа есть отчёт о правах: он показывает, к каким объектам у сотрудника есть доступ и через какие группы. В УТ 11, ЗУП 3.1 и свежих релизах БП 3.0 в разделе администрирования есть также отчёт «Анализ прав доступа» — в нём удобно сравнивать права нескольких пользователей.
Сообщение об ошибке
Если сотрудник видит Нарушение прав доступа! или Недостаточно прав для просмотра, попросите его развернуть подробности ошибки. Там обычно указан объект: справочник, документ или регистр. По имени объекта проще понять, какую роль добавить.
Вход под пользователем
Самая честная проверка — зайти под учётной записью сотрудника. Если пароля вы не знаете, не сбрасывайте его без согласования. Создайте тестового пользователя, включите в те же группы и проверьте под ним.
Фактические роли в Конфигураторе
Группы доступа — это настройка, а реальные роли хранятся у пользователя информационной базы. Чтобы убедиться, что программа их пересчитала, откройте Конфигуратор, Администрирование → Пользователи, карточку сотрудника и вкладку Прочие. Там отмечены роли, с которыми он войдёт в следующий раз. Ничего не меняйте в этом окне — только смотрите. Если нужной роли там нет, хотя профиль её содержит, проверьте, записана ли группа доступа и не снят ли у сотрудника флажок входа в программу.
Журнал регистрации
Кто и когда менял права, видно в журнале регистрации (Администрирование → Обслуживание → Журнал регистрации). Отберите события по пользователям и группам доступа — изменения состава групп там фиксируются.
Как закрыть доступ к базе, не удаляя пользователя
Иногда права нужно не изменить, а забрать целиком: сотрудник уволился или ушёл в долгий отпуск. Удалять его из справочника не стоит. На пользователя ссылаются документы, комментарии, история изменений, и удаление ломает эти связи.
Порядок такой:
- Откройте карточку пользователя в
Администрирование → Настройки пользователей и прав → Пользователи. - Снимите флажок
Вход в программу разрешен. - Запишите карточку.
Учётная запись остаётся в базе, все ссылки на неё целы, но войти под ней нельзя. Если сотрудник вернётся, флажок ставят обратно — права и группы доступа восстанавливать не придётся.
Если сотрудник в этот момент работает в базе, его текущий сеанс сам не закроется. Завершите сеанс через список активных пользователей, но предупредите сотрудника: несохранённые данные в открытых формах пропадут.
Частые ошибки при изменении прав
- 🚫 Галочки ролей в Конфигураторе в типовой базе. Через какое-то время они исчезают, потому что роли пересчитываются по группам доступа.
- 🚫 Правка поставляемого профиля или типовой роли. Профиль восстановится при обновлении, а правка роли снимает конфигурацию с поддержки.
- 🚫 Попытка «запретить» через вторую группу. Права суммируются, запрет не сработает.
- 🚫 Пользователь остался в группе «Администраторы». Любые ограничения на него не действуют.
- 🚫 Удалён последний администратор. Если ни у кого не осталось полных прав, менять права станет некому. Перед правкой группы «Администраторы» убедитесь, что в ней остаётся хотя бы одна рабочая учётная запись с известным паролем.
- 🚫 Включение RLS днём. Пересчёт доступа тормозит работу всех пользователей базы.
Перед изменением ролей в Конфигураторе и включением ограничений на уровне записей сделайте резервную копию базы. Остальные действия из этой инструкции обратимы: группу можно вернуть одним флажком.