Разделение прав пользователей в любой информационной системе — это краеугольный камень обеспечения безопасности, целостности данных и эффективности бизнес-процессов. В системе 1С, особенно в конфигурациях на основе Библиотеки стандартных подсистем (БСП), таких как 1С:Управление нашей фирмой (1С:УНФ), проблема "полных прав" для большого количества пользователей стоит особенно остро. Когда половина пользователей обладает полными правами, возникают ситуации, когда программные ограничения и проверки, направленные на корректность ввода данных, просто игнорируются. Давайте разберем эту проблему подробнее и рассмотрим, как можно культурно и технически ее решить.
Наш клиент столкнулся с ситуацией, когда 50% пользователей работают с полными правами в 1С:УНФ 1.6. При этом были внедрены программные ограничения, например, запрет на проведение некорректно заполненных документов (как в случае с Заказом на производство, который нельзя провести без наличия сдельного наряда). Однако, поскольку у многих пользователей есть полные права, эти ограничения обходятся, что приводит к некорректному учету и нарушению бизнес-логики.
Мы выясним причину, почему полные права обходят программные проверки. Дело в том, что обладатель полных прав по умолчанию имеет доступ ко всем объектам и функциям системы, игнорируя большинство установленных ограничений, в том числе те, которые направлены на контроль заполнения реквизитов или логики проведения документов. Наша задача — не просто установить проверки, а убедиться, что они будут работать для всех, кому это необходимо.
Наиболее верным, безопасным и масштабируемым решением является полный отказ от использования роли "Полные права" для подавляющего большинства пользователей. Этот подход требует организационных усилий, но в долгосрочной перспективе он окупается повышением надежности системы, управляемости данными и снижением рисков ошибок.
Шаг 1: Исключите "Полные права" для большинства.
Оставьте роль "Полные права" только тем, кто действительно в ней нуждается: администраторам системы, разработчикам, или крайне ограниченному кругу ответственных лиц, которые полностью осознают риски и имеют соответствующую квалификацию. Для большинства пользователей, включая руководителей филиалов или сотрудников, работающих с документами, полные права являются избыточными и вредными.
На форуме справедливо отмечают, что оставлять полные права 50% пользователей – это уже "из пушки по воробьям", и что "бюджет клиента лопнет, когда начнут устранять последствия кривых костылин". Для 10 пользователей, упомянутых в обсуждении, такой подход является абсолютно оправданным и не требует огромных затрат.
Шаг 2: Используйте ролевую модель БСП.
1С, особенно конфигурации на БСП, предоставляет мощный и гибкий механизм ролевого доступа, который позволяет настроить права пользователей с необходимой степенью детализации. Этот подход не только позволяет контролировать доступ к данным, но и к выполнению определенных действий.
Создавайте Профили групп доступа.
Профиль группы доступа — это совокупность ролей, агрегированных по смыслу. Например, можно создать профили "Менеджер по продажам", "Бухгалтер", "Кладовщик". Каждый профиль будет включать только те роли, которые необходимы для выполнения соответствующих должностных обязанностей. Начинать можно с копирования типовых профилей и их доработки под специфические нужды предприятия, или же создавать новые профили с нуля, обязательно включив базовые роли, такие как Запуск тонкого клиента и Базовые права.
Формируйте Группы доступа.
Группы доступа объединяют пользователей, которым назначаются определённые профили. Это позволяет гибко управлять правами доступа сразу для большого числа пользователей. Например, создаем группу "Менеджеры" и привязываем к ней профиль "Менеджер по продажам". Все сотрудники, входящие в эту группу, автоматически получают необходимые права.
Создавайте "атомарные" роли.
Мы рекомендуем создавать "атомарные" роли, которые дают права на доступ к элементарным функциям программы или отдельным объектам (чтение, запись, просмотр, удаление). Из таких ролей уже формируются профили пользователей. Такой подход делает систему прав более прозрачной и управляемой.
Используйте Ограничение на уровне записей (RLS).
Для более тонкой настройки доступа можно использовать механизм RLS (Row Level Security), который позволяет ограничивать доступ к данным на уровне отдельных записей, например, по организациям, складам или подразделениям. Это особенно актуально для крупных компаний с разветвленной структурой.
Аргументы в пользу этого подхода: это встроенный функционал, доступный в типовой конфигурации 1С. Пользователь может сам создавать необходимые профили или выбирать существующие для сотрудников. Такой подход обеспечивает:
Как справедливо заметил один из участников форума, "надо делать так, что если у юзвера есть право изменять документ, то он должен это делать по общему шаблону, как и все остальные". То есть, если мы предоставляем право на редактирование документа, то правила его заполнения должны быть едиными для всех, кто имеет такое право.
В некоторых случаях, несмотря на все аргументы, полностью лишить часть пользователей полных прав может быть невозможно (например, из-за политических причин или специфики работы). В такой ситуации возникает другая проблема, поднятая автором: "Дело в том, что просто роль добавить полным правам почему-то нельзя, у них только одна роль ПолныеПрава".
Проблема: БСП игнорирует дополнительные роли для пользователей с "Полными правами".
Действительно, в конфигурациях на БСП существует особенность: если у пользователя есть роль "Полные права", то другие, дополнительно назначенные роли (даже через профили групп доступа), могут игнорироваться или "сбрасываться" при обновлении ролей. Это происходит потому, что конфигурации на основе БСП в процедуре ОбновитьРолиПользователей очищают все установленные роли, кроме "АдминистраторСистемы", "Полные права" и, если включено, "Интерактивное открытие внешних отчетов и обработок". Это сделано для того, чтобы гарантировать администратору полный доступ, не обременяя его множеством других ролей.
Как это работает (технически):
Система проверяет наличие роли ПолныеПрава. Если она есть, то все остальные роли (которые обычно назначаются через профили групп доступа) фактически игнорируются при определении реальных прав пользователя, а метод РольДоступна() может не возвращать ожидаемый результат для этих "неосновных" ролей.
Доработка: Изменение процедуры ОбновитьРолиПользователей.
Если нам критически необходимо, чтобы дополнительные роли все же работали для пользователя с полными правами (например, для программной проверки наличия специфических "флагов" или разрешений через РольДоступна()), необходимо внести изменения в конфигурацию. Мы можем явно добавить желаемую роль в список ДополнительныеРолиАдминистратора в процедуре ОбновитьРолиПользователей в общем модуле УправлениеДоступомСлужебный (или аналогичном модуле, отвечающем за управление доступом).
Рассмотрим пример кода, который может быть использован для такой доработки:
// В общем модуле УправлениеДоступомСлужебный (или аналогичном)
// В процедуре ОбновитьРолиПользователей(....) Экспорт
ОбязательныеРолиАдминистратора = Новый Соответствие;
ОбязательныеРолиАдминистратора.Вставить("ПолныеПрава", Истина);
Если Не РазделениеВключено Тогда
ОбязательныеРолиАдминистратора.Вставить("АдминистраторСистемы", Истина);
КонецЕсли;
ДополнительныеРолиАдминистратора = Новый Соответствие;
ДополнительныеРолиАдминистратора.Вставить("ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок", Истина);
// + Доработка: Добавляем нашу пользовательскую роль для администраторов
ДополнительныеРолиАдминистратора.Вставить("МОЯКРУТАЯРОЛЬ", Истина);
// - Доработка
// ... далее идет основной код процедуры
Важное предупреждение: Это является доработкой типовой конфигурации. Такие изменения требуют особой осторожности, так как могут вызвать проблемы при обновлении конфигурации или привести к нежелательным побочным эффектам. Всегда делайте резервные копии и тестируйте изменения в тестовой базе перед внедрением в продуктивную среду.
Если нет возможности или бюджета на полноценное разграничение прав, а также не подходит модификация БСП, можно прибегнуть к "костыльным" решениям. Это менее надежный и более трудоемкий в поддержке подход, но иногда он является единственно возможным в условиях жестких ограничений.
Суть: Проверять пользователя в коде.
Мы можем в коде, который отвечает за валидацию документа (например, при его записи или проведении), проверять текущего пользователя и, если это "особый" пользователь, разрешать ему обходить проверки.
Пример такой проверки:
// В обработчике ПередЗаписью или ПриПроведении документа
Если НЕ ПараметрыСеанса.ТекущийПользователь().Наименование = "Вася" Тогда
// Здесь располагаются стандартные проверки корректности заполнения документа
Если НЕ ЭтотОбъект.ЗаполненКорректно() Тогда
Отказ = Истина;
Сообщить("Документ заполнен некорректно, проведение запрещено!");
КонецЕсли;
КонецЕсли;
Или, как предложил автор, создать специальную "галочку" в свойствах пользователя или в отдельном регистре:
// Предположим, есть регистр сведений "НастройкиПользователей" с ресурсом "ИмеетСуперПрава" (Булево)
Если НЕ РегистрыСведений.НастройкиПользователей.Получить(ПараметрыСеанса.ТекущийПользователь()).ИмеетСуперПрава Тогда
// Здесь располагаются стандартные проверки корректности заполнения документа
Если НЕ ЭтотОбъект.ЗаполненКорректно() Тогда
Отказ = Истина;
Сообщить("Документ заполнен некорректно, проведение запрещено!");
КонецЕсли;
КонецЕсли;
Недостатки таких решений:
Несмотря на недостатки, это решение может быть рассмотрено как временная мера, когда нет другого выхода. Однако стремиться нужно к полноценной ролевой модели.
Какой бы подход к разграничению прав мы ни выбрали, крайне важно, чтобы контроль заполнения документов был максимально унифицированным и надежным. Основная идея заключается в том, что если у пользователя есть право изменять документ, он должен делать это по общим правилам. Проверка заполнения реквизитов должна происходить при записи документа.
Для предотвращения ошибок и несанкционированных изменений уже проверенных документов, мы можем использовать следующие типовые механизмы 1С:
Даты запрета изменения.
Эта опция позволяет установить временные ограничения на редактирование документов в заданном периоде. Запрет может быть установлен для всей программы, индивидуально для каждого пользователя или конкретных организаций. Например, мы можем запретить изменения документов прошлых отчетных периодов после их закрытия.
Статусы проверки документов.
В некоторых конфигурациях (например, 1С:Комплексная автоматизация или 1С:ERP Управление предприятием) существует функционал "Проверка документов". Он позволяет после проверки ответственным лицом установить запрет на изменение полей документа, отмену проведения или удаление. Пользователь, которому назначена роль Право изменения статусов проверки документов, может устанавливать или снимать этот запрет.
Блокировка документов по статусу.
Мы можем настроить систему таким образом, чтобы проведенные документы нельзя было редактировать. Изменять можно было бы только непроведенные документы или документы, находящиеся в определенном статусе ("Черновик", "На согласовании" и т.п.). Это дополнительно защищает данные от случайных или преднамеренных изменений после того, как документ уже "ушел" в учет.
Объединяя эти подходы, мы создаем многоуровневую систему контроля, которая обеспечивает надежность данных и управляемость бизнес-процессов.
Проблема культурного разделения полных прав в 1С:УНФ, особенно когда 50% пользователей обладают ими, является серьезным вызовом для целостности данных и эффективности бизнес-процессов. Мы рассмотрели несколько решений: от идеального, но требующего организационных изменений (полный отказ от полных прав и переход к ролевой модели БСП), до технических компромиссов (модификация БСП или "костыльные" программные проверки). Выбор конкретного подхода всегда зависит от контекста: размера компании, бюджета, готовности к изменениям и квалификации персонала.
Важно помнить, что даже для небольшого количества пользователей (10, как в данном случае) полноценное разграничение прав с использованием профилей и групп доступа является наиболее выгодным в долгосрочной перспективе. Оно обеспечивает стабильность, безопасность и управляемость системы, минимизируя риски и затраты на исправление ошибок в будущем.