атомарные роли 1с что это
Генератор ролей
С помощью этой обработки можно сгенерировать набор ролей для каждого объекта метаданных (Справочник, Документ, Отчет, Обработка, Рег. сведений).
Для каждой роли можно указать набор прав (Просмотр, Изменение и тд)
1. Выгрузить конфигурацию в файлы xml
2. Открыть обработку в режиме предприятия, добавить Роли и указать Права для каждой роли
3. Созданные настройки ролей можно сохранить в файл
Роли можно создать на все метаданные, либо на выбранный раздел (Справочник, Документы и т.д.), наименование созданных ролей будет сформировано по шаблону
4. После создание ролей, файлы конфигурации можно загрузить в пустую базу.
В итоге должно получиться примерно так:
Исходный код открыт. Пользуйтесь на здоровье, дорабатывайте под себя. Мы в своей поделке создали роли, а в режиме предприятия в БСП создали профили с указанием конкретных ролей
Разрабатывал и тестировал на релизе 1С:Предприятие 8.3 (8.3.18.1334).
Скачать файлы
Специальные предложения
Добрый день!
воспользовался обработкой, но пришлось существенно переписать:
1. не прописаны права для многих метаданных, флажки не ставились автоматически (массово)
2. у меня при попытке выполнить в принципе не работало
3. требовалась кастомизация, в частности не предусмотрена потребность в использовании RLS
в результате примерно 8 часов потратил на создание 150 атомарных ролей с RLS по подразделениям и организациям, считаю это хорошим результатом
(5) 1. не понел для чего не создавались права и автоматические галки не делал
2. текст ошибки?
3. у каждой базы свои уникальные бизнес потребности, всегда нужна кастомизация
а в остальном КРАСАВА ))
(6) мне надо было сделать много ролей в соответствии со стандартами, описанными на 1С:ИТС,
причем там роли повторялись, и было четко понятно, по каким объектам они нужны (поиск по префиксу).
Правила жёлтого напильника. Часть 2
Написал вторую часть правил внесения изменений (первая была тут). Как упоминал в первой публикации, это не хухры-мухры, а методическое пособие, по которому мои программисты учатся и сдают потом экзамен. Поэтому, если заметите критическую ошибку – пишите, не стесняйтесь, если сойдемся во мнениях – исправлю.
В каждом пункте я постарался не просто изложить правила, но и объяснить, почему они именно такие. Мне важно, чтобы человек не просто их запомнил, но и мог объяснить суть правил, их происхождение, отличия во внесении изменений в разных конфигурациях и версиях платформы. Так что не обессудьте на большое количество текста.
И чем дальше пишу, тем больше понимаю, что правил намного больше, чем я представлял себе изначально.
Добавление новых подписок на события
Добавление новых подписок на события – самый, пожалуй, безопасный способ доработки типовых объектов, особенно ссылочных. Странно при этом, что лишь недавно подписки на события стали поддерживаться в расширениях конфигурации.
Первое, что стоит отметить – имя подписки. Оно должно отражать имя события и примерный состав объектов, включенных в ней. Если вы делаете универсальную подписку-шлюз для обработки события «ПриЗаписи» у документов, то нормально будет дать ей имя «ПриЗаписиДокумента». В этом случае человек, ищущий подписки на определенные события, без труда её найдёт. Равно как и человек, который хочет найти все подписки на документы.
Типичная ошибка новичков – считать важным механизмом свою доработку конкретного объекта, вроде стирания комментария при копировании заказа покупателя. Новичок в таком случае создает подписку вроде «ПриКопированииЗаказаПокупателяСтираниеКомментарияСережаПридумал», которая обрабатывает объекты одного типа – просто стирает комментарий.
Для таких мелких доработок лучше использовать подписки-шлюзы, или подписки-кейсы (case, оператор выбора во многих языках программирования). Суть проста – делаете подписку вроде «ПередЗаписьюДокумента», а в обработчике пишете разветвление выполняемого кода в зависимости от типа объекта. Процедуры для обработки объектов конкретных типов лучше оформлять отдельно, не создавая дикий код в обработчике подписки – пусть он остаётся шлюзом, роль которого – перенаправление выполнения кода. Сначала там будет один объект и один кусок кода, потом придёт следующий разработчик (или вы, со следующей задачей), расширит тип объектов подписки, добавит свою процедуру.
Еще одна мелочь: если создали ветку обработки объектов определенного типа, не добавляйте безусловный Возврат – дальше по коду может быть обработка объектов того же типа, но с другой целью.
Изменение типовых подписок
В общем случае – идея так себе. Как правило, меняют состав объектов подписки. Тут многое зависит от платформы – старые её версии не показывали нормально изменения в составе подписки. Но даже в новых версиях, при наличии встречных изменений в составе, головной боли обновлятору вы добавите.
Если вам нужно добавить какой-то объект в состав типовой подписки, есть простой способ – создать новую подписку, и указать в качестве обработчика ту же процедуру, что и в типовой подписке. Понятно, что перед этим надо глянуть код обработчика – там может быть фильтр по типу объекта, в этом случае без доработки не обойтись. Но вроде разработчики фильтрацией по типу не страдают.
Изменение кода обработчика типовой подписки стоит делать, только если вы прям уверены в себе. Правила тут примерно такие же, как в доработке любой другой процедуры или функции типового общего модуля, просто в качестве аргументов всегда используются объекты, а не ссылки, таблицы или еще черт знает что.
Как устроены типовые роли
Вынесу краткую справку по устройству типовых ролей в отдельный пункт, чтобы потом не возвращаться к этому вопросу.
В старых конфигурациях, вроде УПП или УТ 10.3, когда еще не было профилей полномочий, их функцию выполняли роли. Роль содержала в себе практически всё, что нужно для работы человека на определенной должности. Например, были роли МенеджерПоЗакупкам, ЗаведующийУчетом, Кладовщик, Расчетчик и т.д.
Позже, с развитием и применением ограничений на уровне записей (RLS), появились роли-двойники, типа менеджера по продажам с ограничением прав – всё то же самое, что и в исходной роли, только с прописанными запросами для ограничения прав. Сейчас эти роли-двойники убрали, но у некоторых клиентов они еще встречаются, если люди не любят обновляться.
Прелесть такого подхода в том, что ролей очень мало – буквально пара десятков. Недостаток вытекает из преимущества – ролей слишком мало. На реальном внедрении типовые роли в 99% случаях не позволяют настроить права человека так, как это требуется. Поэтому, в 99% случаев роли приходится дорабатывать.
Когда придумали профили (справочник, содержащий перечень ролей, и назначаемый пользователю или группе), то всё стало совсем странно. У нас есть роли вроде МенеджерПоПродажам, и появляется профиль МенеджерПоПродажам, который содержит одну якорную роль, и несколько мелких вспомогательных, вроде права на использование ЭДО или электронной почты. Вроде как профиль в профиле.
Система ролей в современных конфигурациях строилась уже с учетом накопленного опыта. Стало понятно, что в качестве контейнера, содержащего права для конкретной должности или пользователя, надо использовать профили (справочник), а не роли. Поэтому роли начали делать по другому принципу – они теперь дают право на выполнение конкретных, весьма узких операций.
Например, используются роли вроде ДобавлениеИзменениеЗонДоставки, ДобавлениеИзменениеОжидаемыхПоступленийДенежныхСредств, ДобавлениеИзменениеПриказовНаДоплату и даже ИспользованиеОбработкиФормированиеЗаказовНаПередачуВПроизводствоПоПлану. Как видите, каждая роль даёт право использования очень ограниченного перечня объектов, вплоть до одной обработки.
По сравнению со старым подходом, количество ролей увеличилось в десятки раз. Например, знаете, сколько ролей в ERP 2.4.8.82? 1316. Количество ролей как бы говорит: не лезь ко мне, развлекайся в другом месте.
Составить из таких ролей профиль для пользователя – задача не из простых. Поэтому разработчики типовых конфигураций идут навстречу, и делают предопределенные профили и группы доступа, чтобы хоть как-то облегчить нам эту непосильную задачу.
Собственно, вот и вся разница. Раньше было мало ролей с мощным содержанием, сейчас делают сотни атомарных ролей.
Доработка старых ролей
В принципе, сейчас уже нет ничего страшного в том, чтобы дорабатывать типовые роли в старых конфигурациях. Принципиально в них уже ничего не меняется. Если добавляется новая функциональность, то только прицепом, вроде маркировки. Изменения вроде повышения ставки НДС встречаются редко. Для новых объектов роли делают по-новому – добавляют атомарные. Точнее, тащат их… Откуда-то там.
В старые времена, когда УПП и УТ 10.3 еще обновлялись, подход был такой. Если хочешь кастомизировать роль менеджера по продажам под конкретное предприятие – копируй типовую и исправляй, а типовую не трожь. Потом, правда, уже никак нормально не разберешься, что изменилось в типовой роли при обновлении, но хоть замочки целы. Где что перестало работать – там и ищи разницу.
Потом, с появлением профилей, подход к доработке поменялся – кастомизаторы начали создавать собственные атомарные роли, и включать их в профили. Так сильно, конечно, не мельчили, как сейчас в ERP, но суть подхода была такой же.
Поэтому, если вам нужно доработать права доступа в старой конфигурации, думать особо не надо.
Если вы добавили новую, отдельностояющую функциональность, вроде заявок на заправку картриджей – создавайте новые роли для обслуживания прав доступа на неё.
Если вам нужно расширить права типовой роли, то добавляйте новую роль, типа ДопПраваМенеджераПоПродажам, и расширяйте права там. Убедитесь только, что скопированной роли еще нет – наверняка кто-то до вас этим озаботился.
Если же вам нужно сузить права типовой роли, то либо дорабатывайте её, либо копируйте, уменьшайте права там, и заменяйте типовую роль на свою в профилях.
Доработка ролей в современных конфигурациях
Всё очень просто – не трогайте типовые роли в современных конфигурациях. Если вы добавили в конфигурацию новую функциональность – создавайте собственные атомарные роли, которые будут регулировать права на неё.
Если же вам надо изменить права существующей типовой роли, используйте расширения.
Доработка ролей через расширения
Я к расширениям отношусь прохладно, но одну вещь там сделали так, что не стыдно пацанам показывать, а именно – доработку ролей. Если не сталкивались, то сейчас со стула упадёте – расширением можно переопределять значения конкретных прав на объект внутри роли. Я когда увидел, не мог поверить, пошел создавать пустую конфигурацию, чтобы убедиться – не может быть, чтобы 1С что-то сделала так офигенно.
Например, хотите вы доработать роль менеджера по продажам, дав ему право на новый или какой-то типовой отчет – нет ничего проще. Добавляете роль и объекты в расширение, ставите галку на нужный отчет, и вуаля – роль типовая, всем назначена, а отчет виден.
Настоящие же чудеса начинаются, когда вам надо изменить значение конкретного права. Например, забрать право на добавление элементов справочника, оставив только изменение. Нет ничего проще – тащите роль в расширение вместе с объектом, и просто снимайте галку (добавление или интерактивное добавление, что правильнее под задачу).
Главная фишка – все остальные права останутся на месте. В расширении они будут помечены затененными флажками – это типа наследование. Только вдумайтесь: наследование в 1С. И не чего-то там, а прав в ролях.
Так что, в современных типовых конфигурациях доработка ролей – одно сплошное удовольствие, без особого риска. Конечно, может выйти обновление, в котором ваше расширение по ролям вдруг станет неактуальным, но вероятность краха намного ниже, чем при ручной доработке типовых ролей.
Да, если используете расширения (а их в современных конфигурациях используют почти все), то и новые роли логично добавлять именно в расширениях.
Настройка ролей и прав доступа
Область применения: управляемое приложение, обычное приложение.
Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.
1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
1.2. Роль ПолныеПрава (англ. FullAccess ) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator ) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы ) не должна давать право на интерактивное удаление ссылочных объектов.
1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
Настройка права доступа 1С 8
В этой статье речь пойдет о настройке прав доступа пользователей к объектам системы 1С.
В 1С 8для управления доступа пользователей используется отдельный объект метаданных, который называется Роли.
Далее мы рассмотрим, как использовать и настраивать роли в 1С предприятие 8.3.
Обратите внимание! Эта статья написана в помощь программистам. Настройка прав в пользовательском режиме на примере 1С Бухгалтерия рассмотрена в данной статье.
Роль определяет набор прав пользователя, которые он имеет. Механизм ролей очень похож на механизмы прав Windows Active Directory. Для каждого из объектов (справочники, документы) разработчик устанавливает свой набор прав — чтение/запись/добавление/изменение/…
Набор доступных прав — совокупность всех разрешений в ролях пользователя.
Ниже мы рассмотрим подробно каждый атрибут метаданных при настройке роли пользователя 1С 8.3.
Общие настройки роли 1С
Если открыть объект метаданных Роль, мы можем увидеть следующую картину:
У объекта есть две закладки — Права и Шаблоны ограничений. Права — основная закладка, Шаблоны — вкладка для настройки прав на уровне записи в 1С (RLS). Это очень важная тема, её я постараюсь описать в будущих статьях.
Будем рассматривать только вкладку Права.
Следует обратить внимание на галочки в нижней части:
Настройки прав на всю конфигурацию
Если открыть Роль и кликнуть на корень конфигурации, мы увидим следующие настройки:
Подробнее о каждом из прав на всю конфигурацию:
Настройка прав 1С на другие объекты метаданных
Для остальных основных объектов (справочники, константы, документы, регистры…), набор прав у роли достаточно стандартен:
Права только для документов:
Только для регистров накопления и бухгалтерии
Только для обработок и отчетов:
Привилегированный режим 1С
Если Вы не хотите давать роли права на какие-либо действия, но эти метаданные нужно использовать в какой-то момент, можно воспользоваться методом «УстановитьПривилегированныйРежим()» (или использовать привилегированный режим общего модуля).
Все, что внутри, будет выполняться без проверки прав пользователя.
Доступна ли роль 1С пользователю?
Чтобы узнать, нужно выполнить функцию РольДоступна(), передав туда название роли строкой.
Например:
Нарушение прав доступа
Такую ошибку можно увидеть, если недостаточно прав на чтение/редактирование/удаление данных. Система выдаёт вот такую ошибку:
Чтобы исправить «нарушение прав доступа», необходимо понять, на какой объект пользователю не хватает прав, и добавить ему либо новую роль, либо в существующую роль добавить больше прав.
Объект не найден…
Ошибка, когда в полях отображается некое ( … ):
Как правило, специалисты думают, что это просто так называемая «битая ссылка». Но это не всегда так. Такая ошибка бывает и при неправильно настроенном механизме прав RLS. Это связано с тем, что у пользователя не хватает прав, чтобы получить представление ссылки.
Для того чтобы понять, битая ссылка или нет, просто зайдите в базу под пользователем с полными правами.
Для массового поиска таких ошибок подойдет статья как найти битые ссылки в базе 1С.
P.S. Если у Вас все же не получилось разобраться в ролях пользователей, Вы можете заказать услуги 1С программиста.
Видео с примером настройки прав в 1С бухгалтерии 3.0:
Другие статьи по 1С:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Особенность при создании своих ролей в конфигурациях на управляемых формах
Столкнулся с небольшой проблемкой при создании «своих» ролей в конфигураторе и добавлении их пользователям. Гуглил много, ответа толкового не нашёл, поэтому пришлось разбираться самому и как результат, решил поделиться опытом. Возможно кому-то пригодится.
Итак, проблема заключалась в следующем:
В какой-либо конфигурации на управляемых формах создаём свою роль (или несколько ролей, как в примере) (см. рис.1), обновляем конфигурацию. В режиме предприятия создаём профиль групп доступа с нашей новой ролью (см. рис.2), добавляем пользователю этот профиль (см. рис.3) и. ничего не происходит, как-будто у этого пользователя не добавлена наша роль. Заходим в конфигуратор, администрирование, пользователи, заходим в пользователя, смотрим «доступные роли» и видим, что у нашего пользователя не выбрана наша роль (см. рис.4).
Почему так происходит? Всё очень просто, разработчики сделали так, что если пользователь «администратор», то есть у него полные права, то собственно говоря, зачем же ему ещё какие-то роли? Ведь у него же и так полные права!
В целом вполне логично и кстати если пользователь не администратор, то всё работает корректно (см. рис.5 и рис.6). Сложности возникают только в том случае, если мы хотим добавить нашу роль/роли пользователю с полными правами. Можно конечно просто в конфигураторе выбрать у пользователя нашу роль/роли, но всё будет работать ровно до тех пор, пока кто-нибудь не решит перезаписать в режиме предприятия права доступа у этого пользователя, после этого «галочка» у добавленной роли «слетит».
Что же делать и где это происходит?
«НовыеРоли» это Таблица значений, в которой выбраны все роли пользователя, которые мы ему назначили в режиме предприятия (включая «наши» роли). Как видно далее по коду, эта таблица очищается, в неё добавляются «ОбязательныеРолиАдминистратора» (Администратор системы, Полные права) и если выбрано, «ДополнительныеРолиАдминистратора» (Интерактивное открытие внешних отчетов и обработок).
Как мне показалось, самый простой и очевидный вариант, это добавить «наши» роли в таблицу «НовыеРоли». Для этого нам надо как-то отделить эти роли от всех остальных, поэтому у всех добавленных нами в конфигураторе ролей, делаем префикс «Доп_». Те «наши» роли, которые мы выбрали для пользователя, собираем в массив «ВыбранныеДополнительныеРоли» и далее из этого массива добавляем роли в таблицу значений «НовыеРоли». Ниже представлен код:
В заключение добавлю, процедура «ОбновитьРолиПользователей» абсолютна одинакова у многих конфигураций (благодаря «унификации» 1С), смотрел в УНФ 1.6, Бухгалтерия предприятия 3.0, Управление торговлей 11.4 (все конфигурации в нескольких версиях), поэтому сделал расширение, которое по идее должно работать на многих конфигурациях на управляемых формах. Можете скачать и добавить его себе, но предварительно не забудьте, что все добавленные роли должны иметь префикс «Доп_«. Расширение написано на версии платформы: 8.3.12.1685. В расширение добавлен один общий модуль «УправлениеДоступомСлужебный», в котором только одна процедура «ОбновитьРолиПользователей» (&Вместо) с добавленным, по описанию выше, кодом. При добавлении расширения, не забываем снять галочки «безопасный режим» и «защита от опасных действий».