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