Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS

11.10.17

Администрирование - Роли и права

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

1. Права доступа
2. Роли - механизм предоставления прав доступа
3. "Логика разрешений" как правило пересечения ролей
4. Косвенное управление доступом
- 4.1. Функциональные опции
- 4.2. RLS (Record Level Security)
- 4.3. Разделение данных
- 4.4. Программный код
- 4.5. Сравнение вариантов
5. Итоги

1. Права доступа.

На самом деле все очень просто. В 1С по умолчанию запрещено всё, что не разрешено. Есть только одна сущность, отвечающая за доступ пользователя к какой-либо функциональности или данным. Эта сущность называется "Право доступа". Она является единственным элементом, отвечающим за доступ к конкретному режиму работы, справочнику, реквизиту.... 

Количество видов прав доступа предопределено платформой. Всего платформе есть две основные группы прав доступа. Общие для всей системы права доступа к механизмам платформы, отвечающие за доступ к определенным режимам работы платформы (Администрирование, Монопольный режим, Тонкий клиент,Интерактивное открытие внешних отчетов.... ). И объектные права доступа, позволяющие работать с различными объектами конфигурации. Их количество зависит от типа объекта конфигурации. Например, у справочника есть 16 различных видов доступа (Чтение, Добавление, Изменение, Удаление....). Для регистра сведений видов доступа всего пять. Все эти права можно установить только на уровне справочника целиком. Также можно ограничить доступ на уровне реквизитов. Но в этом случае доступна лишь часть видов прав (для справочников это права Просмотр и Редактирование).

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

Права доступа к справочникуРассмотрим права доступа к справочнику. На данной схеме видно, что большинство прав является уточнением более общих прав. Если Право1 полностью расположено на схеме внутри прямоугольника другого Права2, то Право1 не может быть выдано без выдачи Права2. Самым общим правом является право "Чтение". Если право "Чтение" отсутствует, то недоступны и все остальные права. Если недоступно право "Добавление", то нельзя установить право "Интерактивное добавление". Однако, систему прав нельзя назвать полноценной иерархией. Например, право "Редактирование" можно дать лишь при наличии прав "Просмотр" и "Изменение". Но можно дать "Просмотр" без "Изменение" или "Изменение" без "Просмотр".

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

2. Роли - механизм предоставления прав доступа

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

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

С технической точки зрения данная система выдачи прав реализовывается с участием двух стандартных подсистем. Подсистема "Управление доступом" используется для настройки связи групп доступа с предопределенными в конфигурации ролями. Подсистема "Пользователи" используется для настройки связей пользователей ИБ с группами доступа конфигурации. 

3. "Логика разрешений" как правило пересечения ролей.

Пересечение ролейВажно понимать, что в 1С общая логика управления доступом это логика разрешений. В платформе 1С вообще нет никаких механизмов запрета доступа. Есть только механизмы выдачи доступа. По умолчанию доступ ко всем данным запрещен, и настройка доступа заключается в выдаче каждому пользователю нужных ему прав. Это означает, что если какой-то ролью пользователю дано право на просмотр документов "Реализация товаров", то никакими способами нельзя это право отнять другими ролями или любыми другими механизмами платформы и конфигурации. Можно изначально выдать не полный доступ к справочнику, а отфильтровать с помощью RLS данные, на которые мы даем доступ. Но если доступ уже выдан, то забрать его другими ролями уже нельзя.

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

В платформе есть возможность дать пользователю дополнительные права на время выполнения отдельной операции. Эта возможность называется "Привилегированный режим". Он позволяет пользователю выполнять действия над данными, которые ему не доступны. Однако, в платформе нет возможности даже временно уменьшить имеющиеся у пользователя права.

4. Косвенное управление доступом.

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

4.1. Функциональные опции.

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

Подробнее о работе с функциональными опциями можно почитать на ИТС

4.2. RLS (Record Level Security)

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

Для настройки такого разрешения есть дополнительный механизм  RLS (Record Level Security). Как и следует из названия, этот механизм контроля доступа на уровне конкретных записей таблиц. Если права доступа дают доступ к таблицам вцелом (справочникам) или колонкам таблиц (реквизитам), то RLS определяет конкретные строки таблиц (записи), с которыми разрешено работать пользователю. Он позволяет определить данные, которые пользователю доступны.

При разборе данного механизма стоит всегда помнить, что RLS не является механизмом запрета доступа. Он является механизмом фильтрации выдачи доступа. Т.е. RLS  не влияет на имеющиеся у пользователя права, он является фильтром, ограничивающим выдачу прав. RLS влияет только на ту конкретную связь "Роль" - "Право доступа", в которой он прописан. И не влияет на права доступа, выданные с помощью других ролей.   Например, если одной ролью будет разрешен доступ к документам только по Организации1, а другой ролью доступ к документам по Складу1, то в итоге пользователь получит доступ ко всем документам, в которых указана Организация1 ИЛИ Склад1. Поэтому если пользователю выдается несколько ролей, то фильтр с помощью RLS нужно ставить в каждой роли по обоим полям  (по организации и складу). В типовых решениях эта задача обычна решается созданием одной роли, в которой прописываются все возможные фильтры RLS. Данная роль потом назначается всем пользователям, работающим с данными справочниками. Также контролируется, чтобы у пользователя не были доступны другие роли, содержащие право доступа к ограниченным документам. 

Так же стоит обратить внимание что фильтры RLS можно наложить не на все возможные виды доступа к данным, а лишь на виды доступа верхнего уровня. Например, для справочников из имеющихся шестнадцати видов доступа фильтры RLS можно наложить лишь на четыре основных: Чтение, Изменение, Добавление и Удаление. Это означает, что мы не можем, например, дать пользователю одновременно право "Изменение" без фильтра для возможности работать программно с любыми документами и право "Редактирование" с фильтром RLS по организации для интерактивной работы. Если нам нужно, чтобы пользователь мог редактировать документы с фильтром RLS , мы обязаны наложить общий фильтр на верхнем уровне "Изменение" или "Чтение".

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

4.3. Разделение данных.

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

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

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

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

Подробнее о разделении данных можно почитать на ИТС, а также в блоге http://howknow1c.ru.

4.4. Программный код.

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

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

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

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

4.5. Сравнение вариантов.

Попробуем кратко сравнить рассмотренные варианты дополнительного ограничения данных.

Как включить

Что при этом произойдет

Функциональные опции - интерфейсный механизм скрытия функционала

1. Добавить место хранения функциональной опции: константа, реквизит справочника или ресурс регистра сведений. 
2. Добавить в конфигурацию функциональную опцию и указать в ней созданное ранее место хранения.
3. Указать в свойствах функциональной опции ее состав, отметить все объекты конфигурации, которые будут от нее зависеть.
4. Включить использование функциональной опции в режиме предприятия.

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

RLS (Record Level Security) - дополнительные фильтры на разрешаемые роле права

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

Примечание: В режиме предприятия никаких действий выполнять не нужно. Фильтры применятся автоматически.

1. Настроенный фильтр будет добавляться к каждому запросу к ИБ. 
2. Данные, не подходящие под фильтр RLS нельзя будет получить никакими средствами: они не будут отображаться в формах, отчетах; не будут отбираться никакими запросами. 

Разделение данных - ведение в одной физической базе нескольких независимых

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

2. Добавит два параметра сеанса: для признака использования и текущего значения разделения данных.

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

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

  • Добавится поле "Разделитель", в котором будет храниться значение разделителя.  
  • Перестроятся все индексы по таблицам. В них перевым полем добавится поле разделителя.

2. После включения разделения.

  • В абсолютно все запросы к ИБ будет добавляться фильтр по значению разделителя.
  • При записи любых данных будет автоматически заполняться значение разделителя по значению параметра сеанса.
Программный код - любые дополнительные точечные ограничения
1. Добавить код наложения нужных ограничений в конфигурацию.

1. Сделает именно то, что написано.

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

5. Итоги.

У каждого способа настройки ограничений свои плюсы и минуса. С точки зрения технологии наиболее правильный способ это грамотное разбиение на роли. Для фильтрации доступных данных надежнее всего использование RLS. Именно для этой задачи механизм предназначен. Точечные ограничения проще всего выполнять с помощью программного кода. Функциональные опции и разделение данных достаточно специфичные механизмы, не предназначенные для ограничения доступа. Хоть в некоторых случаях и могут для этого использоваться.

Управление доступом права доступа Роли RLS функциональные опции группы доступа Профили доступа

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    135677    750    391    

779

Инструменты администратора БД Роли и права Системный администратор Программист Пользователь 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

14400 руб.

06.12.2023    5150    22    1    

50

Инструменты администратора БД Инструментарий разработчика Роли и права Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 руб.

10.11.2023    6655    18    2    

44

Зарплата Роли и права Системный администратор Бухгалтер Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Молдова Россия Казахстан Бухгалтерский учет Платные (руб)

Расширение позволяет максимально полно ограничить доступ пользователей к данным по заработной плате, а именно закрывает доступ к документам начисления и выплаты заработной платы, не позволяет просматривать бухгалтерские отчеты по счету учета зарплаты а также убирает зарплатные проводки из журнала проводок. Расширение запрещает просматривать платежные документы на выплату зарплаты, так же не доступны регламентные отчеты в ПФР и ИФНС. Расширение предлагает готовые настроенные профили "Бухгалтер без зарплаты", "Только просмотр без зарплаты".

5700 руб.

27.05.2021    34202    215    89    

173

Роли и права Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

Данная система разработана как альтернатива стандартной системе напоминаний. Но имеет ряд существенных преимуществ: отображение в базе или с отправкой по почте, свое расписание, возможность фильтрации по ролям и пользователям, формирование своих запросов и макетов, шаблоны писем, работа в фоне. А также может блокировать работу пользователей при заданных условиях. Может работать в составе любой конфигурации. Имеется справка с описанием возможностей. (Обновление от 20.02.2024, версия 2.2, расширение)

19200 руб.

29.11.2019    25094    14    8    

35

Ценообразование, анализ цен Роли и права Системный администратор Платформа 1С v8.3 Управление правами 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Платные (руб)

Расширение возможностей программы УНФ. Функционал расширения - разграничение всевозможных прав пользователей и контроль при совершении различных действий.

3000 руб.

23.02.2018    56623    152    261    

144

Логистика, склад и ТМЦ Роли и права Программист Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Расширение, которое позволяет использовать отдельные роли для доступа к складским документам, для доступа к документам раздела "Производство" и для доступа к документам раздела "Покупки".

2520 руб.

21.05.2019    1693421    557    193    

136
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. PerlAmutor 129 12.10.17 13:11 Сейчас в теме
Особняком нужно отметить функцию ПривилегированныйРежим, если для объекта нет ни одной роли с разрешением Просмотра, то даже при включенном режиме пользователь не увидит ничего. Отчеты будут пусты, но работа с данными будет возможна на программном уровне.
criptid; sapervodichka; jif; tormozit; ekaruk; +5 Ответить
2. BlizD 1031 12.10.17 13:48 Сейчас в теме
Добрый день, Евгения.

Спасибо за статью.
Как, Вы, считаете можно ли разделение данных (Общий реквизит) рассматривать как один из вариантов реализации доступа к данным?
Если да, можно ли и его включить в статью с описанием плюсов и минусов этого подхода.
sapervodichka; ekaruk; +2 Ответить
3. ekaruk 4933 12.10.17 14:03 Сейчас в теме
(2) Да, согласна. Разделение данных тоже можно отнести к механизмам управления доступом. Как-то позабыла о нем.
Спасибо. Дополню чуть позже статью.
(1) Добавлю уточнение.
4. mrXoxot 2912 15.10.17 10:08 Сейчас в теме
Отличная статья! Спасибо за труд.
Думаю, для ролей можно добавить еще и описание профилей.
Хотя это механизм БСП, а не платформы.
5. ekaruk 4933 15.10.17 15:20 Сейчас в теме
(4) Кратко механизм профилей я упомянула. В идеале нужно описывать в комплексе внутренних и внешних пользователей, Профили, Группы доступа и механизма настройки в БСП фильтров по RLS. А это уже сильно за рамками статьи.
6. Alex Gor 18.10.17 11:28 Сейчас в теме
Отличная статья! Особенно здорово оформлена визуализация.
7. serferian 26 19.10.17 12:18 Сейчас в теме
у RLS есть один Огроменный минус...

все индексы практически убиваются этими доп.подзапросами... и с какого-то момента работа просто останавливается на любом щелчке: (открытие формы, открытие формы выбора и т.п.)
8. ekaruk 4933 20.10.17 07:36 Сейчас в теме
(7) На самом деле это не проблема RLS.
Вернее не только RLS.
Это плата за универсальность, которую дают типовые механизмы настройки RLS в БСП.
Именно средствами RLS можно написать достаточно оптимальные ограничения. Конечно, они все равно будут замедлять работу. Но не так сильно, как типовые.
9. mitia.mackarevich 74 23.10.17 17:32 Сейчас в теме
Интересно.
было бы неплохо также отметить по RLS, что при наличии пользователя в двух и более группах доступа со своими профилями, если в нескольких профилях будут встречаться роли на одни и те же объекты (и у них будет прописан RLS) то это приведет к замедлению работы пользователя, как будет выполняться запрос (фильтр) каждой роли и поэтому рекомендуют, чтобы при организации RLS в профиле была только одна роль на объект с RLS, чтобы они не накладывались.
13. kalyaka 1082 14.05.18 12:33 Сейчас в теме
(9) Уточнение: если есть несколько повторяющихся условий RLS, то платформа использует только одно - поэтому важно использовать одинаковые шаблоны RLS и тогда замедлений не будет.
10. independ 1539 24.10.17 15:27 Сейчас в теме
Хорошая статья, основное я уяснил, что установка ролей/прав/групп ведет к открытию/разрешению доступа, а режим запрета стоит по умолчанию
11. b-dm 171 07.12.17 18:11 Сейчас в теме
Крутая статья про права доступа и роли.
12. LexSeIch 211 17.12.17 13:50 Сейчас в теме
Спасибо за очередную интересную статью!
14. SagittariusA 28.06.18 11:31 Сейчас в теме
Спасибо Вам за труд! Интересно и познавательно.
15. PLAstic 295 01.10.20 12:01 Сейчас в теме
Если я правильно понимаю, сведения в 4.1 и 4.2 устарели, т.к. ФО могут использоваться в запросах RLS и т.о. влияют не только на отображение данных интерфейсно, но и на предоставление доступа к ним.
16. loginovvn 18.11.20 06:44 Сейчас в теме
вот сразу видно грамотный подход. лаконично и по делу... но и все механизмы влияющие на предостовление доступа (права) осветили в такой короткой, но очень грамотной статье.
17. ssn5810 80 26.10.21 10:42 Сейчас в теме
Подскажите как во Внешних пользователях в Профилях групп доступа подставить в Назначение Контрагенты
При выборе Контрагенты, все время при сохранении подставляются ( Пользователи Пользователи )
Прикрепленные файлы:
18. Serg243 29.07.22 11:04 Сейчас в теме
У меня один пользователь может изменить вариант навигации на форме обработки подбора товаров в заказ клиента, а другой не может и права одинаковые. Как мне узнать какая из 100500 ролей мешает? Вот бы был способ указать на элемент формы и получить список связанных с ним прав. Эта статья хорошая, но не помогла мне с этим разобраться(((
19. Anirina 8 26.08.22 09:19 Сейчас в теме
(18) Аналогичная проблема, только ещё более "выкрутасней". Если пользователю добавить профиль с правами на доработки, то перестает формироваться оборотка по некоторым счетам. RLS не используется. Так что утверждение "... если какой-то ролью пользователю дано право на просмотр,... никакими способами нельзя это право отнять другими ролями или любыми другими механизмами платформы и конфигурации" по факту неверно.
20. VKuser208890122 20.01.23 13:03 Сейчас в теме
В чем отличие ограничение/разрешение я укажу в профиле или в группе?
В чем разница?
21. kns77 101 13.06.24 13:29 Сейчас в теме
Права доступа в 1С сделано препоганейшим образом, я хуже не видел ни в одной самой примитивной системе. Там где в других системах можно просто галочками выставить нужные права, в 1С нужно городить огород c RLS.

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

Почему нельзя было взять принцип как в NTFS.

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

В общем идиотская идеология привела к идиотским правам.

(Сейчас наверное опять бан получу, но накипело уже)
Оставьте свое сообщение