Настройка дополнительных прав пользователей 1с 8.2. Бухучет инфо. Программная проверка прав доступа

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

Прежде всего хочется отметить основные аспекты данного вида настроек. Многие подходят к этому вопросу однобоко, рассматривая их сугубо как меру защиты от несанкционированного доступа к данным или неквалифицированной их модификации. При этом забывают о другой стороне медали: создания для пользователя простой и удобной рабочей среды. В тех случаях, когда рабочий интерфейс пользователя перегружен не нужными ему пунктами, смысл которых к тому же ему до конца не ясен, возникает ложное представление об излишней сложности программы и появляется боязнь допустить ошибку. Понятно, что это никак не способствует повышению производительности труда сотрудника.

В идеале каждый сотрудник, должен видеть только те элементы интерфейса, которые нужны ему для выполнения своих непосредственных обязанностей. Тогда и работать будет проще, и соблазнов полазить там, где не надо не возникнет. Причем выполнять подобные настройки есть смысл и тогда, когда какие-то подсистемы просто не используются или ограничение доступа к ним не требуется. Это сделает интерфейс более простым и понятным, а, следовательно, работать пользователю будет проще и комфортнее.

Если мы вернемся немного в прошлое, то можем вспомнить, что в обычных конфигурациях Роли и Интерфейсы были частью конфигурации и для их тонкой настройки требовалось включить возможность внесения изменений, а в базовых версиях было невозможным вообще.

Недостатки данного подхода очевидны: это и усложнение обслуживания информационных баз, и возможные конфликты при последующих обновлениях, когда измененные объекты конфигурации требуют изменения прав доступа.

В управляемом приложении настройки прав и интерфейсов были наконец вынесены в пользовательский режим и настраиваются непосредственно из интерфейса программы. Права пользователя назначаются на основе его членства в группах доступа. Перейдем в Администрирование - Настройки пользователей и прав - Группы доступа - Профили групп доступа , где мы увидим уже предустановленные профили для основных групп доступа.

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

А вот если мы попытаемся найти настройки интерфейсов, то нас постигнет фиаско. В управляемом приложении интерфейс рабочей области формируется автоматически, на основе прав доступа. Для примера сравним интерфейсы Панели разделов Администратора и Менеджера по продажам:

В общем - идея здравая, есть права доступа к объекту - показываем его в интерфейсе, нет - скрываем. Это гораздо лучше, чем выскакивающие в обычном приложении сообщения о нарушении прав доступа при несоответствии последних с назначенным интерфейсом. Если вы добавите группе доступа прав или, наоборот, уберете, то связанные с ними элементы интерфейса самостоятельно появятся или исчезнут. Удобно? Да.

Также пользователь может самостоятельно настраивать свое рабочее пространство в пределах имеющихся у него прав доступа. На первый взгляд все выглядит неплохо, но без ложки дегтя не обошлось. Механизма, позволяющего централизованно настроить и назначить пользователям интерфейс "по умолчанию" в управляемом приложении нет.

Если мы заглянем в Администрирование - Настройки пользователей и прав - Персональные настройки пользователей - Настройки пользователей то увидим там перечень всех объектов, настройки которых были изменены пользователем, однако никак не сможем их изменить.

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

Чтобы не быть голословными разберем практический пример. В рамках подготовки к переходу на онлайн-кассы было решено автоматизировать кассовые места небольшой сети стоматологических клиник. Основу автоматизации клиник составляло отраслевое ПО не на базе 1С и не предусматривающее возможность подключения фискального регистратора, поэтому было принято решение для автоматизации кассовых мест использовать конфигурацию Бухгалтерия предприятия 3.0, которая содержит все необходимые функции.

Здесь мы столкнулись с двумя сложностями, хотя если посмотреть повнимательнее, то обнаружится, что это две стороны одной и той же медали. Если коротко: персонал никогда до этого не работал с 1С и поэтому требовалось создать максимально простую в освоении рабочую среду, при этом оградив информационную базу от возможного неквалифицированного воздействия персонала. Управляемое приложение позволяет достаточно просто совместить приятное с полезным, сделав так, чтобы и пользователя ограничить, и в тоже время позволить ему комфортно работать, не замечая ограничений.

Начнем. Прежде всего необходимо создать профиль группы пользователей. Если мы откроем стандартные профили, то увидим, что возможность их изменять отсутствует. Это, на наш взгляд, правильно, история знает массу примеров, когда в приступе служебного рвения стандартные права были перелопачены до такого состояния, что их приходилось восстанавливать из эталонной конфигурации. Также это способно ввести в заблуждение иных пользователей или администраторов этой базы, которые под стандартными профилями ожидают увидеть стандартные наборы прав.

Поэтому найдем наиболее подходящий для наших задач профиль, в нашем случае это Менеджер по продажам, и сделаем его копию, которой дадим название Кассир. Теперь мы можем настраивать права по собственному усмотрению. Однако плоский список, предлагаемый по умолчанию, не совсем удобен для работы, если только вам не нужно быстро найти уже известную вам опцию, в большинстве случаев гораздо удобнее работать со списком включив группировку по подсистемам.

Мы не будем подобно останавливаться на этом вопросе, так как назначение прав зависит от конкретных задач, стоящих перед пользователем, можем только посоветовать проявлять благоразумие и не скатываться в крайности. Помните, что ваша задача - создание удобной и безопасной рабочей среды, а не тотальное запрещение всего чего только можно.

Создав профиль назначаем группу доступа нужным пользователям и запускаем программу под одним из них. В зависимости от назначенных прав вы увидите автоматически сформированный интерфейс.

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

Перейдем в Главное меню - Вид , где увидим целый ряд настроек, касающихся интерфейса.

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

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

Можно даже сравнить, как было и как стало:

И в заключение выполним настройку панелей. Так как разделов у нас немного, то панель разделов имеет смысл переместить вверх, а панель открытых вниз, тем самым расширив рабочее пространство по горизонтали, что актуально для мониторов с небольшой диагональю или формата 4:3.

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

Теперь снова войдем в программу под администратором и перейдем в Администрирование - Настройки пользователей и прав - Персональные настройки пользователей - Копирование настроек . Наша задача распространить сделанные нами изменения на оставшихся пользователей группы Кассиры. Сама операция достаточно проста: выбираем пользователя, настройки которого мы копируем, указываем кому и выбираем что именно.

Ну и напоследок можно запретить пользователю самостоятельно настраивать интерфейс, для этого снова вернитесь к профилю группы и снимите галочку с действия Сохранение данных пользователя .

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

• Теги:

Please enable JavaScript to view the

Для того чтобы разграничить права доступа, в 1С 8.3 существуют специальные объекты конфигурации – роли. В дальнейшем они могут назначаться конкретным пользователям, должностям и т. п. В них указывается, какие объекты конфигурации будут доступны. Так же есть возможность прописать условия предоставления доступа.

Роли настраиваются в конфигураторе. Так же их можно назначить конкретным пользователям, но для удобства в 1С реализован механизм групп доступа. В справочнике пользователей откройте («Администрирование — Настройка пользователей и прав — Пользователи») карточку любого сотрудника и нажмите на кнопку «Права доступа». В разных конфигурациях интерфейс может отличаться, но суть одна и та же.

Перед вами откроется список записей справочника «Профили групп доступа». Флажками отмечаются те, права которых пользователю будут доступны.

Справочник профилей групп доступа («Администрирование — Настройка пользователей и прав — Профили групп доступа») содержит в себе перечень ролей, который будет доступен пользователю при его назначении. Доступные роли профиля отмечаются флагами.

У пользователей часто встречаются одинаковые наборы ролей. Использование данного механизма позволяет значительно упростить настройку прав, выбирая не сами роли, а профили групп доступа.

Роли в конфигураторе (для программистов)

В ролях указывается, какие объекты и при каких условиях будут доступны пользователю, которому они доступны. Откройте любую роль, и вы увидите две вкладки: «Права» и «Шаблоны ограничений».

На первой вкладке отображается список объектов конфигурации и назначенные для данной роли права на них.

При разрешении совершения каких-либо действий с объектом, есть возможность указать ограничение доступа к данным. Данный механизм называется RLS и позволяет настроить права на уровне записей. Он достаточно интересный, но при активном его использовании может снизиться производительность.

В нижней части формы роли можно настроить автоматическую установку прав:

• для новых объектов (разрешающие права);
• на реквизиты и табличные части (права наследуются от объекта – владельца)
• на подчиненные объекты (права назначаются с учетом прав на родительские объекты).

Права можно назначить как на отбельные объекты, так и на всю конфигурацию в целом. В любой роли на вкладке «Права» выберите пункт с названием конфигурации. Справа отобразятся все возможные для нее роли. Здесь содержатся режимы запуска программы, «Все функции», административные и другие права. При нажатии на любое право, внизу отобразится его описание. Тут нет ничего сложного.

Настройки прав для остальных объектов конфигурации сходи между собой: чтение, добавление, удаления, проведение (для документов), управление итогами (для регистров накопления и бухгалтерии) и прочие. Здесь важно отметить право на «Интерактивное удаление». При его доступности пользователи смогут физически удалять данные из программы (shift + delete). Для важных объектов данное право назначать крайне нежелательно.

Программная проверка прав доступа

Для проверки доступности у пользователя какой-либо роли служит следующая функция:

• РольДоступна(«АдминистраторСистемы»)

В том случае, когда проверяемая роль назначена пользователю, функция вернет значение «Истина». В противном случае – «Ложь».

Для того чтобы выполнить какие-либо действия с объектом, к которому нет доступа, можно воспользоваться следующим методом:

• УстановитьПривилегированныйРежим(Истина)

После включения привилегированно режима никаких проверок прав не производится. По окончании действий над недоступными объектами необходимо снова вызвать данный метод с параметром «Ложь» для отключения данного режима. Помните, что в клиент — серверном варианте при выполнении на клиенте данный метод не выполняет никаких действий.

Для проверки того, установлен привилегированный режим служит функция (возвращает «Истина» или «Ложь»):

• ПривилегированныйРежим()

Пользовательский интерфейс при отсутствии прав доступа

При попытке пользователя совершить какое-либо действие в программе, но которое у него нет прав будет выдано соответствующее предупреждение.

Бывают случаи, когда в каком-либо поле отображается надпись формата «<Объект не найден>» с указанием GUID, возможно, у пользователя тоже не хватает прав на чтение содержащегося в нем значения. Для проверки этой теории достаточно просмотреть значение данного поля под полными правами. Если надпись не пропадает – есть вероятность битой ссылки.

Вопрос с правами доступа возникает в связи с необходимостью ограничить права пользователя в 1С (или группы пользователей), что подразумевает под собой запрет на совершение каких-либо действий с определенными объектами, например, их просмотр, запись, редактирование и т.д. Или, наоборот – из-за необходимости дать (расширить) права пользователей в 1С, что в реальности чаще всего следует за сообщением системы о нарушении прав доступа (например, недостаточно прав для просмотра) и обращением пользователя к администраторам с просьбой об этом.

Чтобы внести коррективы в правила доступа и изменить права на просмотр того или иного раздела или на любое другое действие, необходимо зайти в «Настройки пользователей и прав», что можно сделать при включенном пользовательском режиме на вкладке «Администрирование» (при условии, конечно, что имеются права на это).

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

Описание прав пользователей доступно на вкладке «Описание».

Роли просматриваются посредством элемента справочника «Пользователи», попасть в который можно по клику на конкретном пользователе.

Здесь же формируется отчет по правам доступа, где отображается статус доступа к конкретным объектам системы.

Крайняя правая колонка «Ограничения на уровне записей» – это дополнительные условия, ограничивающие действия с объектами базы данных. По сути это запрос, выполняющийся в момент работы и сообщающий, можно или нельзя работать с объектом.

На скриншоте видно, что документ «Ввод начальных остатков» доступен для пользователя, но доступ возможен только к определенным складам.

Таким образом, установить доступ или изменить права в 1С можно добавив пользователя в ту или иную группу в пользовательском режиме.

Саму группу также можно изменить, например, добавив значение в ограничение доступа.

Права администратора позволяют осуществлять управление правами в режиме конфигуратора, где уже заданы типовые роли. Например, роль с много объясняющим названием «Базовые права», как правило, дает возможность осуществить только чтение или только просмотр объекта.

Для управления правами, призванными изменять объекты, предусмотрены специальные роли добавления/изменения данных.

Если известно, на какой объект не хватает прав у пользователя, можно:

• От обратного: посмотреть вкладку «права» у конкретного объекта, при этом вверху мы увидим все роли, доступные в конфигурации, а в нижнем окне – права. Наличие тех или иных прав на объект отмечено «галочкой». Таким же образом задаются права для новых объектов.

• Открыть роль, назначенную пользователю, и, выбрав в левом окне конкретный объект, в правом окне увидеть список прав, то есть действия, которые пользователь с данной ролью может сделать с этим объектом – чтение, добавление, просмотр т.д.

Таким образом, все возможные права в системе предопределены. Чтение, добавление, изменение, просмотр, редактирование и другие права могут быть включены или выключены в любой роли для любого объекта. Назначить права отдельно, не используя при этом роли, невозможно. Для разграничения прав пользователя необходимо назначить соответствующую роль. Удобным инструментом для анализа прав и ролей становится таблица «Все роли», формируемая в конфигураторе.

На скриншоте видно, что роль «Полные права» обладает максимальным объемом прав. И если задачи ограничивать пользователей в правах не стоит вовсе – можно смело назначать эту роль всем пользователям, навсегда избавившись от вопросов пользователей.

На практике же, как правило, в большинстве случаев все-таки необходима «защита от дурака». Подстраховаться от нежелательного изменения данных нужно всем более-менее крупным компаниям. Здесь на помощь приходит встроенные в 1С роли. Разобраться в разнообразии ролей не просто, на это требует много времени. Поэтому создание собственной роли для решения практических задач, зачастую может быть единственным выходом. Рассмотрим этот момент подробнее. Добавить роль можно в дереве метаданных.

В новой роли разграничить права можно простым выставлением флажков напротив соответствующего права.

Флажки в низу окна говорят о том, что права будут автоматически назначаться для новых объектов метаданных/для реквизитов и табличных частей объекта, для которого назначаются права, а также – будут ли наследоваться права относительно родительского объекта.

Ограничения прав доступа задаются в правом нижнем окне новой роли. Это мощный инструмент, позволяющий ограничить права на уровне записей, т.е. предоставить доступ именно к необходимым данным. Если простое назначение прав может только «прямолинейно» дать или отнять права на действия с объектом, то механизм ограничений позволяет гибко настроить права доступа относительно данных. Например, ограничить чтение и просмотр данных только по одной организации.

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

Ограничение прав доступа описывается в виде языковых конструкций. Для облегчения их создания предусмотрено использование шаблонов ограничений. Надо заметить, что использование этого механизма напрямую сказывается на производительности, ведь системе, обращаясь к какому-либо объекту, необходимо прочитать и выполнить эти ограничения. Этот процесс отнимает ресурсы компьютера и тормозит работу.

В заключение хотелось бы отметить, что фирма 1С в качестве разработчика позаботилась о наличие широких возможностей для администраторов в части редактирования прав в своих программных решениях. И если на первый взгляд эти инструменты могут показаться сложными и избыточными, то в дальнейшем, особенно при попытке построить эффективную схему доступа в условиях многоуровневой, разветвленной структуры персонала на предприятии или в организации, становится ясно, что функционал программы вполне соответствует реальным потребностям.

1С имеет встроенную систему прав доступа (эта система называется — роли 1С). Эта система является статической – как администратор поставил права 1С, так и будет.

Дополнительно, действует динамическая система прав доступа (называется – RLS 1С). В ней права 1С динамически высчитываются в момент работы пользователя на основании заданных параметров.

Одной из самых распространенных настроек безопасности в различных программах является набор разрешений на чтение/запись для групп пользователей и далее – включение или исключение пользователя из групп. Например, подобная система используется в Windows AD (Active Directory).

Такая система безопасности в 1С называется – Роли 1С. Роли 1С – это , который находится в конфигурации в ветке Общие/Роли. Роли 1С выступают в качестве групп, для которых назначаются права 1С. Далее пользователь включается или исключается из этой группы.

Нажав два раза на название роли 1С — Вам откроется редактор прав для роли 1С. Слева – список объектов 1С. Выделите любой и справа отобразятся варианты прав доступа (как минимум: чтение, добавление, изменение, удаление).

Для верхней ветки (название текущей конфигурации) устанавливаются административные права 1С и доступ на запуск различных вариантов .

Все права 1С поделены на две группы – «просто» право и такое же право с добавлением «интерактивное». Что это значит?

Когда пользователь открывает какую-либо форму (например, обработку) и нажимает на ней кнопку – то программа на встроенном языке 1С выполняет определенные действия, например удаление документов. За разрешение этих действий (выполняемых программно) – отвечают «просто» права 1С.

Когда пользователь открывает журнал и начинает делать что-то с клавиатуры самостоятельно (например, вводить новые документы) – это «интерактивные» права 1С.

Пользователю может быть доступно несколько ролей, тогда разрешения складываются.

Разрез возможностей установки прав доступа с помощью ролей – объект 1С. То есть Вы можете или включить доступ к справочнику или отключить. Включить немножко нельзя.

Для этого существует расширение системы ролей 1С под названием 1С RLS. Это динамическая система прав доступа, которая позволяет ограничить доступ частично. Например, пользователь видит только документы по определенному складу и организации и не видит остальные.

Аккуратно! При использовании запутанной схемы RLS 1С у разных пользователей могут быть вопросы, когда они попытаются сверить один и тот же отчет, сформированный из под разных пользователей.

Вы берете определенный справочник (например, организации) и определенное право (например, чтение). Вы разрешаете чтение для роли 1С. В панели Ограничение доступа к данным Вы устанавливаете текст запроса, который возвращает ИСТИНА или ЛОЖЬ в зависимости от настроек. Настройки обычно хранятся в регистре сведений (например регистр сведений конфигурации Бухгалтерия НастройкиПравДоступаПользователей).

Данный запрос выполняется динамически (при попытке реализовать чтение), для каждой записи справочника. Таким образом, для тех записей, для которых запрос безопасности вернул ИСТИНА – пользователь увидит, а остальные – нет.
Права 1С, на которые установлены ограничения RLS 1С – подсвечены серым.

Копирование одних и тех же настроек RLS 1С делается с помощью шаблонов. Вы делаете шаблон, называете его (например) МойШаблон, в нем указываете запрос безопасности. Далее, в настройках права доступа 1С указываете имя шаблона вот так: «#МойШаблон».

При работе пользователя в режиме 1С Предприятие, при работе RLS 1С, у него может появляться сообщение об ошибке «Недостаточно прав» (например, на чтение справочника Ххх).

Это значит, что RLS 1С заблокировала чтение нескольких записей.

Для того, чтобы такого сообщения не появлялось, необходимо в тексте запроса на встроенном языке 1С использовать слово РАЗРЕШЕННЫЕ ().

Например:

Настройку доступа можно производить в нескольких местах программы, но рекомендуется выполнять её для профиля пользователя. Заходим в профиль администраторы и что мы видим?

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

Но настройки дополнительных прав можно выполнять не только для профиля, но и для группы и для конкретного пользователя.

Как же поведет себя система, если значения дополнительных прав у пользователя и его профиля не совпадают? Может сложиться впечатление, что система должна в этом случае использовать значение права, установленное пользователю, как более точное. Но это не так! Приоритет прав профиля выше, чем у группы пользователей и пользователя. Прочитав значение права у профиля, программа даже не будет смотреть, что там установлено для группы, поэтому и необходимо выполнять настройку в профиле.

Зачем же тогда сделана возможность заполнять права для группы и пользователя, если они все равно не используются? А использоваться они будут, если пользователю профиль не задан. Какое же из прав будет брать система в этом случае? Посмотрим в конфигураторе:

Функция ПрочитатьЗначениеПраваПользователя(Право, ЗначениеПоУмолчанию, Пользователь) ВозвращаемыеЗначения = Новый Массив ; Запрос = Новый Запрос; Запрос.УстановитьПараметр("Пользователь" , Пользователь); Запрос.УстановитьПараметр("ПравоПользователя" , Право); Запрос.Текст = "ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ | РегистрЗначениеПрав.Значение |ИЗ | РегистрСведений.ЗначенияДополнительныхПравПользователя КАК РегистрЗначениеПрав |ГДЕ | РегистрЗначениеПрав.Право = &ПравоПользователя | И РегистрЗначениеПрав.Пользователь В | (ВЫБРАТЬ | ПользователиГруппы.Ссылка КАК Ссылка | ИЗ | Справочник.ГруппыПользователей.ПользователиГруппы КАК ПользователиГруппы | ГДЕ | ПользователиГруппы.Пользователь = &Пользователь | | ОБЪЕДИНИТЬ ВСЕ | | ВЫБРАТЬ | ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи) | | ОБЪЕДИНИТЬ ВСЕ | | ВЫБРАТЬ | &Пользователь)" ; Выборка = Запрос. Выполнить(). Выбрать(); Если Выборка. Количество() = 0 Тогда ВозвращаемыеЗначения. Добавить(ЗначениеПоУмолчанию); Иначе Пока Выборка. Следующий() Цикл ВозвращаемыеЗначения. Добавить(Выборка.Значение); КонецЦикла; КонецЕсли; Возврат ВозвращаемыеЗначения; КонецФункции

Функция возвращает массив значений прав, заданных для пользователя, группы этого пользователя и группы "Все пользователи".

Функция ПравоЕстьУПользователя(Право, ЗначениеПоУмолчанию) МассивЗначенийПрава = ПолучитьЗначениеПраваПользователя(Право, ЗначениеПоУмолчанию); Возврат МассивЗначенийПрава.Найти(Истина) <> Неопределено; КонецФункции

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

Стоит так же добавить, что система не читает этот регистр каждый раз, а помещает данные в кэш после первого прочтения и в дальнейшем берет данные из него. Поэтому, значение установленное пользователю, вступит в силу только в следующем сеансе.

Итак, подведем итоги:

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