Добрый день.
Имеется конфигурация ERP и расширение конфигурации.
Подскажите решение проблемы. Если в расширении добавлена роль, то включить её можно только из конфигуратора в учётке пользователя. Остальные роли включаются автоматически в соответствии с группой доступа и профилем пользователя.
Причем, что самое неприятно, при определённых изменениях в ролях расширений все роли в учётке пользователя (которая в конфигураторе) выключаются.
Вопросы:
1) из-за чего это происходит
2) как быстро восстановить роли учётки
Имеется конфигурация ERP и расширение конфигурации.
Подскажите решение проблемы. Если в расширении добавлена роль, то включить её можно только из конфигуратора в учётке пользователя. Остальные роли включаются автоматически в соответствии с группой доступа и профилем пользователя.
Причем, что самое неприятно, при определённых изменениях в ролях расширений все роли в учётке пользователя (которая в конфигураторе) выключаются.
Вопросы:
1) из-за чего это происходит
2) как быстро восстановить роли учётки
По теме из базы знаний
- Анализ прав доступа и ролей 1С БСП 2+
- Подсистема прав доступа (анализ ролей, отладка RLS, английский код, обычные и управляемые формы)
- Подсистема прав доступа к объектам с гибкими отборами (расширение)
- Пример создания документа с движениями в ERP 2.5.7
- Переход с 1С:УПП на 1C:ERP. Переезд пользователей с сохранением прежних прав
Найденные решения
Разработчики в управляемых приложениях применили новый механизм настройки прав доступа, о которых и пойдет речь.
. Теперь: Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей. Создаем профили Бесправный(с ролью ДокументНетДоступа), Аудитор(с ролью ДокументТолькоЧтение), Бухгалтер(с ролью ДокументЧтениеИРедактирование).
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей). При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе. Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
РодительРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоНаименованию("Роли");//ничего страшного искать по наименованию,
//справочник - служебный и непосредственного редактрования в нем нет
ИдентификаторМоейРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоРеквизиту("Имя","МояРоль",РодительРоли);
Если ЗначениеЗаполнено(ИдентификаторМоейРоли) Тогда
НайденныйИдентификаторМоейРоли = МойПрофиль.Роли.Найти(ИдентификаторМоейРоли );
Если НайденныйИдентификаторМоейРоли= неопределено тогда
НовСтрока = МойПрофиль.Роли.Добавить();
НовСтрока.Роль = ИдентификаторМоейРоли;
КонецЕсли;
КонецЕсли;
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(ИСТИНА,ЛОЖЬ,ЛОЖЬ);//ЕстьИзменения, ЕстьУдаленные, ТолькоПроверка Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями. Отлично. Роль добавили, идентификаторы обновили. Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать? За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить ее значение: Константы.ПараметрыРаботыПользователей.СоздатьМенеджерЗначения().ОбновитьОбщиеПараметры(); Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
//МойПрофиль - профиль, который мы хотим добавить пользователю МойПользователь
Если МойПрофиль = Справочники.ПрофилиГруппДоступа.Администратор Тогда // если мы хотим пользователю дать роль Администратора,
//то нельзя создавать новую группу доступа, надо редактировать предопределенную Администраторы
ГруппаДоступаАдм = Справочники.ГруппыДоступа.Администраторы;
Если ГруппаДоступаАдм.Пользователи.Найти(МойПользователь) = неопределено Тогда
ГруппаДоступаАдмОб= ГруппаДоступаАдм.ПолучитьОбъект();
НовСтрока = ГруппаДоступаАдмОб.Пользователи.Добавить();
НовСтрока.Пользователь = МойПользователь;
ГруппаДоступаАдмОб.Записать();
КонецЕсли;
Иначе // все прочие профили, кроме Администратора
Запрос = новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
|ГруппыДоступа.Ссылка
|ИЗ
|Справочник.ГруппыДоступа КАК ГруппыДоступа
|ГДЕ
|ГруппыДоступа.Профиль = &Профиль
|И (ГруппыДоступа.Пользователь = &Пользователь
|ИЛИ ГруппыДоступа.Пользователи.Пользователь = &Пользователь)
|И НЕ ГруппыДоступа.ПометкаУдаления ";
Запрос.УстановитьПараметр("Профиль",МойПрофиль);
Запрос.УстановитьПараметр("Пользователь",МойПользователь);
Выборка = Запрос.Выполнить().Выбрать();
Если НЕ Выборка.Следующий() тогда //нет такого профиля, надо создать
МояГруппаДоступаОб = справочники.ГруппыДоступа.СоздатьЭлемент();
МояГруппаДоступаОб.Наименование = Строка(МойПрофиль);
МояГруппаДоступаОб.Пользователь = мойПользователь;
Нов = МояГруппаДоступаОб.Пользователи.Добавить();
Нов.Пользователь = МойПользователь;
МояГруппаДоступаОб.Профиль = МойПрофиль;
МояГруппаДоступаОб.Записать();
КонецЕсли; //Нет такого профиля
КонецЕсли;//профиль Администратор
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли. Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
ПользовательИБ.имя = "Иванов";
ПользовательИБ.ПолноеИмя = "Иванов Иван Иванович";
ПользовательИБ.АутентификацияСтандартная = ИСТИНА;
ПользовательИБ.Пароль = "";
ПользовательИБ.записать();
Пользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ",ПользовательИБ.УникальныйИдентификатор));
если Пользователь.Наименование = "" Тогда
//создаем пользователя
ПользовательОб = Справочники.Пользователи.СоздатьЭлемент();
ОписаниеПользователяИБ = Пользователи.НовоеОписаниеПользователяИБ();
ЗаполнитьЗначенияСвойств(ОписаниеПользователяИБ,ПользовательИБ);
ОписаниеПользователяИБ.УникальныйИдентификатор = ПользовательИБ.УникальныйИдентификатор;
ПользовательОб.Наименование = ОписаниеПользователяИБ.ПолноеИмя;
ОписаниеПользователяИБ.Вставить("Действие","Записать");
ПользовательОб.ДополнительныеСвойства.Вставить("ОписаниеПользователяИБ",ОписаниеПользователяИБ);
ПользовательОб.записать();
КонецЕсли;
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользователь ИБ у вас сам создатся. И если раньше, в обычном приложении, достаточно будет добавить пользователя в конфигураторе - и при заходе в Предприятие, этот пользователь сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователем ИБ, которого нет в справочнике Пользователи.
. Теперь: Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей. Создаем профили Бесправный(с ролью ДокументНетДоступа), Аудитор(с ролью ДокументТолькоЧтение), Бухгалтер(с ролью ДокументЧтениеИРедактирование).
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей). При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе. Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
РодительРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоНаименованию("Роли");//ничего страшного искать по наименованию,
//справочник - служебный и непосредственного редактрования в нем нет
ИдентификаторМоейРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоРеквизиту("Имя","МояРоль",РодительРоли);
Если ЗначениеЗаполнено(ИдентификаторМоейРоли) Тогда
НайденныйИдентификаторМоейРоли = МойПрофиль.Роли.Найти(ИдентификаторМоейРоли );
Если НайденныйИдентификаторМоейРоли= неопределено тогда
НовСтрока = МойПрофиль.Роли.Добавить();
НовСтрока.Роль = ИдентификаторМоейРоли;
КонецЕсли;
КонецЕсли;
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(ИСТИНА,ЛОЖЬ,ЛОЖЬ);//ЕстьИзменения, ЕстьУдаленные, ТолькоПроверка Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями. Отлично. Роль добавили, идентификаторы обновили. Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать? За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить ее значение: Константы.ПараметрыРаботыПользователей.СоздатьМенеджерЗначения().ОбновитьОбщиеПараметры(); Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
//МойПрофиль - профиль, который мы хотим добавить пользователю МойПользователь
Если МойПрофиль = Справочники.ПрофилиГруппДоступа.Администратор Тогда // если мы хотим пользователю дать роль Администратора,
//то нельзя создавать новую группу доступа, надо редактировать предопределенную Администраторы
ГруппаДоступаАдм = Справочники.ГруппыДоступа.Администраторы;
Если ГруппаДоступаАдм.Пользователи.Найти(МойПользователь) = неопределено Тогда
ГруппаДоступаАдмОб= ГруппаДоступаАдм.ПолучитьОбъект();
НовСтрока = ГруппаДоступаАдмОб.Пользователи.Добавить();
НовСтрока.Пользователь = МойПользователь;
ГруппаДоступаАдмОб.Записать();
КонецЕсли;
Иначе // все прочие профили, кроме Администратора
Запрос = новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
|ГруппыДоступа.Ссылка
|ИЗ
|Справочник.ГруппыДоступа КАК ГруппыДоступа
|ГДЕ
|ГруппыДоступа.Профиль = &Профиль
|И (ГруппыДоступа.Пользователь = &Пользователь
|ИЛИ ГруппыДоступа.Пользователи.Пользователь = &Пользователь)
|И НЕ ГруппыДоступа.ПометкаУдаления ";
Запрос.УстановитьПараметр("Профиль",МойПрофиль);
Запрос.УстановитьПараметр("Пользователь",МойПользователь);
Выборка = Запрос.Выполнить().Выбрать();
Если НЕ Выборка.Следующий() тогда //нет такого профиля, надо создать
МояГруппаДоступаОб = справочники.ГруппыДоступа.СоздатьЭлемент();
МояГруппаДоступаОб.Наименование = Строка(МойПрофиль);
МояГруппаДоступаОб.Пользователь = мойПользователь;
Нов = МояГруппаДоступаОб.Пользователи.Добавить();
Нов.Пользователь = МойПользователь;
МояГруппаДоступаОб.Профиль = МойПрофиль;
МояГруппаДоступаОб.Записать();
КонецЕсли; //Нет такого профиля
КонецЕсли;//профиль Администратор
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли. Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
ПользовательИБ.имя = "Иванов";
ПользовательИБ.ПолноеИмя = "Иванов Иван Иванович";
ПользовательИБ.АутентификацияСтандартная = ИСТИНА;
ПользовательИБ.Пароль = "";
ПользовательИБ.записать();
Пользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ",ПользовательИБ.УникальныйИдентификатор));
если Пользователь.Наименование = "" Тогда
//создаем пользователя
ПользовательОб = Справочники.Пользователи.СоздатьЭлемент();
ОписаниеПользователяИБ = Пользователи.НовоеОписаниеПользователяИБ();
ЗаполнитьЗначенияСвойств(ОписаниеПользователяИБ,ПользовательИБ);
ОписаниеПользователяИБ.УникальныйИдентификатор = ПользовательИБ.УникальныйИдентификатор;
ПользовательОб.Наименование = ОписаниеПользователяИБ.ПолноеИмя;
ОписаниеПользователяИБ.Вставить("Действие","Записать");
ПользовательОб.ДополнительныеСвойства.Вставить("ОписаниеПользователяИБ",ОписаниеПользователяИБ);
ПользовательОб.записать();
КонецЕсли;
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользователь ИБ у вас сам создатся. И если раньше, в обычном приложении, достаточно будет добавить пользователя в конфигураторе - и при заходе в Предприятие, этот пользователь сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователем ИБ, которого нет в справочнике Пользователи.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4) Роли нужны потому что в расширении добавлены как совершенно новые подсистемы, так и объекты и т.п.
Поэтому проще создать роль "Водитель" и дать права только на документ "Заявка на доставку" чем возиться с готовой ролью, в которой будет куча всего ненужного.
Поэтому проще создать роль "Водитель" и дать права только на документ "Заявка на доставку" чем возиться с готовой ролью, в которой будет куча всего ненужного.
(5) А можно конкретнее? Я понимаю что есть такой справочник типовой, понимаю зачем он. Мало того, знаю что есть и регистры сведений в этой подсистеме.
Но главный вопрос остаётся без ответа - как и в какой момент роли включаются/выключаются в учётной записи пользователя и почему не включаются добавленные в расширение роли?
Но главный вопрос остаётся без ответа - как и в какой момент роли включаются/выключаются в учётной записи пользователя и почему не включаются добавленные в расширение роли?
Попробую конкретизировать вопрос. В каком месте конфигурации и в какой момент происходит включение/выключение ролей в учётке пользователя (которая в конфигураторе) при включении/исключении пользователя (справочник Пользователи) в группу доступа, к которой привязан профиль доступа, в котором включены роли?
Разработчики в управляемых приложениях применили новый механизм настройки прав доступа, о которых и пойдет речь.
. Теперь: Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей. Создаем профили Бесправный(с ролью ДокументНетДоступа), Аудитор(с ролью ДокументТолькоЧтение), Бухгалтер(с ролью ДокументЧтениеИРедактирование).
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей). При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе. Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
РодительРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоНаименованию("Роли");//ничего страшного искать по наименованию,
//справочник - служебный и непосредственного редактрования в нем нет
ИдентификаторМоейРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоРеквизиту("Имя","МояРоль",РодительРоли);
Если ЗначениеЗаполнено(ИдентификаторМоейРоли) Тогда
НайденныйИдентификаторМоейРоли = МойПрофиль.Роли.Найти(ИдентификаторМоейРоли );
Если НайденныйИдентификаторМоейРоли= неопределено тогда
НовСтрока = МойПрофиль.Роли.Добавить();
НовСтрока.Роль = ИдентификаторМоейРоли;
КонецЕсли;
КонецЕсли;
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(ИСТИНА,ЛОЖЬ,ЛОЖЬ);//ЕстьИзменения, ЕстьУдаленные, ТолькоПроверка Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями. Отлично. Роль добавили, идентификаторы обновили. Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать? За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить ее значение: Константы.ПараметрыРаботыПользователей.СоздатьМенеджерЗначения().ОбновитьОбщиеПараметры(); Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
//МойПрофиль - профиль, который мы хотим добавить пользователю МойПользователь
Если МойПрофиль = Справочники.ПрофилиГруппДоступа.Администратор Тогда // если мы хотим пользователю дать роль Администратора,
//то нельзя создавать новую группу доступа, надо редактировать предопределенную Администраторы
ГруппаДоступаАдм = Справочники.ГруппыДоступа.Администраторы;
Если ГруппаДоступаАдм.Пользователи.Найти(МойПользователь) = неопределено Тогда
ГруппаДоступаАдмОб= ГруппаДоступаАдм.ПолучитьОбъект();
НовСтрока = ГруппаДоступаАдмОб.Пользователи.Добавить();
НовСтрока.Пользователь = МойПользователь;
ГруппаДоступаАдмОб.Записать();
КонецЕсли;
Иначе // все прочие профили, кроме Администратора
Запрос = новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
|ГруппыДоступа.Ссылка
|ИЗ
|Справочник.ГруппыДоступа КАК ГруппыДоступа
|ГДЕ
|ГруппыДоступа.Профиль = &Профиль
|И (ГруппыДоступа.Пользователь = &Пользователь
|ИЛИ ГруппыДоступа.Пользователи.Пользователь = &Пользователь)
|И НЕ ГруппыДоступа.ПометкаУдаления ";
Запрос.УстановитьПараметр("Профиль",МойПрофиль);
Запрос.УстановитьПараметр("Пользователь",МойПользователь);
Выборка = Запрос.Выполнить().Выбрать();
Если НЕ Выборка.Следующий() тогда //нет такого профиля, надо создать
МояГруппаДоступаОб = справочники.ГруппыДоступа.СоздатьЭлемент();
МояГруппаДоступаОб.Наименование = Строка(МойПрофиль);
МояГруппаДоступаОб.Пользователь = мойПользователь;
Нов = МояГруппаДоступаОб.Пользователи.Добавить();
Нов.Пользователь = МойПользователь;
МояГруппаДоступаОб.Профиль = МойПрофиль;
МояГруппаДоступаОб.Записать();
КонецЕсли; //Нет такого профиля
КонецЕсли;//профиль Администратор
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли. Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
ПользовательИБ.имя = "Иванов";
ПользовательИБ.ПолноеИмя = "Иванов Иван Иванович";
ПользовательИБ.АутентификацияСтандартная = ИСТИНА;
ПользовательИБ.Пароль = "";
ПользовательИБ.записать();
Пользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ",ПользовательИБ.УникальныйИдентификатор));
если Пользователь.Наименование = "" Тогда
//создаем пользователя
ПользовательОб = Справочники.Пользователи.СоздатьЭлемент();
ОписаниеПользователяИБ = Пользователи.НовоеОписаниеПользователяИБ();
ЗаполнитьЗначенияСвойств(ОписаниеПользователяИБ,ПользовательИБ);
ОписаниеПользователяИБ.УникальныйИдентификатор = ПользовательИБ.УникальныйИдентификатор;
ПользовательОб.Наименование = ОписаниеПользователяИБ.ПолноеИмя;
ОписаниеПользователяИБ.Вставить("Действие","Записать");
ПользовательОб.ДополнительныеСвойства.Вставить("ОписаниеПользователяИБ",ОписаниеПользователяИБ);
ПользовательОб.записать();
КонецЕсли;
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользователь ИБ у вас сам создатся. И если раньше, в обычном приложении, достаточно будет добавить пользователя в конфигураторе - и при заходе в Предприятие, этот пользователь сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователем ИБ, которого нет в справочнике Пользователи.
. Теперь: Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей. Создаем профили Бесправный(с ролью ДокументНетДоступа), Аудитор(с ролью ДокументТолькоЧтение), Бухгалтер(с ролью ДокументЧтениеИРедактирование).
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей). При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе. Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
РодительРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоНаименованию("Роли");//ничего страшного искать по наименованию,
//справочник - служебный и непосредственного редактрования в нем нет
ИдентификаторМоейРоли = Справочники.ИдентификаторыОбъектовМетаданных.НайтиПоРеквизиту("Имя","МояРоль",РодительРоли);
Если ЗначениеЗаполнено(ИдентификаторМоейРоли) Тогда
НайденныйИдентификаторМоейРоли = МойПрофиль.Роли.Найти(ИдентификаторМоейРоли );
Если НайденныйИдентификаторМоейРоли= неопределено тогда
НовСтрока = МойПрофиль.Роли.Добавить();
НовСтрока.Роль = ИдентификаторМоейРоли;
КонецЕсли;
КонецЕсли;
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(ИСТИНА,ЛОЖЬ,ЛОЖЬ);//ЕстьИзменения, ЕстьУдаленные, ТолькоПроверка Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями. Отлично. Роль добавили, идентификаторы обновили. Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать? За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить ее значение: Константы.ПараметрыРаботыПользователей.СоздатьМенеджерЗначения().ОбновитьОбщиеПараметры(); Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
//МойПрофиль - профиль, который мы хотим добавить пользователю МойПользователь
Если МойПрофиль = Справочники.ПрофилиГруппДоступа.Администратор Тогда // если мы хотим пользователю дать роль Администратора,
//то нельзя создавать новую группу доступа, надо редактировать предопределенную Администраторы
ГруппаДоступаАдм = Справочники.ГруппыДоступа.Администраторы;
Если ГруппаДоступаАдм.Пользователи.Найти(МойПользователь) = неопределено Тогда
ГруппаДоступаАдмОб= ГруппаДоступаАдм.ПолучитьОбъект();
НовСтрока = ГруппаДоступаАдмОб.Пользователи.Добавить();
НовСтрока.Пользователь = МойПользователь;
ГруппаДоступаАдмОб.Записать();
КонецЕсли;
Иначе // все прочие профили, кроме Администратора
Запрос = новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
|ГруппыДоступа.Ссылка
|ИЗ
|Справочник.ГруппыДоступа КАК ГруппыДоступа
|ГДЕ
|ГруппыДоступа.Профиль = &Профиль
|И (ГруппыДоступа.Пользователь = &Пользователь
|ИЛИ ГруппыДоступа.Пользователи.Пользователь = &Пользователь)
|И НЕ ГруппыДоступа.ПометкаУдаления ";
Запрос.УстановитьПараметр("Профиль",МойПрофиль);
Запрос.УстановитьПараметр("Пользователь",МойПользователь);
Выборка = Запрос.Выполнить().Выбрать();
Если НЕ Выборка.Следующий() тогда //нет такого профиля, надо создать
МояГруппаДоступаОб = справочники.ГруппыДоступа.СоздатьЭлемент();
МояГруппаДоступаОб.Наименование = Строка(МойПрофиль);
МояГруппаДоступаОб.Пользователь = мойПользователь;
Нов = МояГруппаДоступаОб.Пользователи.Добавить();
Нов.Пользователь = МойПользователь;
МояГруппаДоступаОб.Профиль = МойПрофиль;
МояГруппаДоступаОб.Записать();
КонецЕсли; //Нет такого профиля
КонецЕсли;//профиль Администратор
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли. Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
ПользовательИБ.имя = "Иванов";
ПользовательИБ.ПолноеИмя = "Иванов Иван Иванович";
ПользовательИБ.АутентификацияСтандартная = ИСТИНА;
ПользовательИБ.Пароль = "";
ПользовательИБ.записать();
Пользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ",ПользовательИБ.УникальныйИдентификатор));
если Пользователь.Наименование = "" Тогда
//создаем пользователя
ПользовательОб = Справочники.Пользователи.СоздатьЭлемент();
ОписаниеПользователяИБ = Пользователи.НовоеОписаниеПользователяИБ();
ЗаполнитьЗначенияСвойств(ОписаниеПользователяИБ,ПользовательИБ);
ОписаниеПользователяИБ.УникальныйИдентификатор = ПользовательИБ.УникальныйИдентификатор;
ПользовательОб.Наименование = ОписаниеПользователяИБ.ПолноеИмя;
ОписаниеПользователяИБ.Вставить("Действие","Записать");
ПользовательОб.ДополнительныеСвойства.Вставить("ОписаниеПользователяИБ",ОписаниеПользователяИБ);
ПользовательОб.записать();
КонецЕсли;
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользователь ИБ у вас сам создатся. И если раньше, в обычном приложении, достаточно будет добавить пользователя в конфигураторе - и при заходе в Предприятие, этот пользователь сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователем ИБ, которого нет в справочнике Пользователи.
1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
Например, в УП(ERP) это роль ПартнерСамообслуживание.
1.2. Роль ПолныеПрава (англ. FullAccess) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы) не должна давать право на интерактивное удаление ссылочных объектов.
после создания нового объекта нужно зайти в роль ПолныеПрава и отключить право интерактивного удаления у ссылочных объектов.
1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы, создавать отдельные роли в этом случае не требуется.
1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
Исключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом, которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.
1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование, ТонкийКлиент и т.п.).
при создании новой роли нужно следить, чтобы эти права были выключены.
1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке - для ссылочных данных), а следует включать эти права в роли БазовыеПрава<ИмяБиблиотеки> (англ. BasicAccess<LibraryName>) и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (англ. BasicAccessExternalUser<LibraryName>) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
Чтение<ИмяФункции> (англ. Read<FeatureName>);
ДобавлениеИзменение<ИмяФункции> (англ. InsertUpdate<FeatureName>) (или Изменение<ИмяФункции> (англ. Update<FeatureName>), если добавление выполняется автоматически, либо только администратором).
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
Чтение<ИмяФункции> содержит права:
Чтение, Просмотр, Ввод по строке.
Изменение<ИмяФункции> содержит те же права, что и роль Чтение<ИмяФункции>, а также:
Изменение, Редактирование;
Проведение, Отмена проведения, Интерактивное проведение, Интерактивная отмена проведения, Интерактивное изменение проведенных (для документов);
Управление итогами (для регистров).
ДобавлениеИзменение<ИмяФункции> содержит те же права, что и роль Изменение<ИмяФункции>, а также:
Добавление, Интерактивное добавление;
Интерактивная пометка удаления, Интерактивное снятие пометки удаления.
3.2. Необходимо помнить, что для регистров, подчиненных регистратору, обычно не требуется назначать права на изменение (см. п. 1.7).
4. Журналы документов
4.1. Если все документы, входящие в журнал, отнесены к одной элементарной функции, то права на чтение и просмотр журнала нужно включить во все роли этой функции.
4.2. Платформа 1С:Предприятие имеет следующую особенность: если у пользователя нет прав на чтение любого документа, входящего в журнал документов, то платформа не дает доступ ко всем графам журнала, в котором отражается этот документ, для всех документов, входящих в журнал. Поэтому нет никакого практического смысла создавать отдельную роль для доступа к журналу: журнал может входить в элементарную функцию, или может быть доступен только пользователю с полными правами.
5. Константы
5.1. Если предполагается, что константа должна изменяться только администратором системы, то права на изменение и редактирование должны быть только у одной из ролей: ПолныеПрава или АдминистраторСистемы. Эти роли должны включать также и права на чтение и просмотр констант.
5.2. Если предполагается, что константу может менять пользователь, то нужно включить права на чтение, просмотр, изменение и редактирование в уже имеющуюся «настроечную» роль или создать отдельную роль Изменение<ИмяКонстанты> (англ. Update<ConstantName>), дающую права на чтение, просмотр, изменение и редактирование этой константы.
5.3. В подавляющем большинстве случаев константа используется для хранения неконфиденциальной информации, поэтому права на чтение и просмотр константы нужно назначать роли БазовыеПрава<ИмяБиблиотеки> и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки>. Это позволяет избежать неоправданной установки привилегированного режима при чтении значения константы из кода.
5.4. В редких случаях, когда константа используется для хранения конфиденциальной информации, необходимо создать роль Чтение<ИмяКонстанты> (англ. Read<ConstantName>). При этом, если значение должно быть доступно только администратору, создавать отдельную роль на чтение не требуется.
Например, для константы ПараметрыАдминистрированияИБ создавать отдельную роль на чтение не требуется – достаточно включения прав на чтение и просмотр в роль АдминистраторСистемы.
6. Подсистемы, отображаемые в главном командном интерфейсе
6.1. Для каждой подсистемы верхнего уровня должна быть создана роль Подсистема<ИмяПодсистемы> (англ. Subsystem<SubsystemName>), дающая право на просмотр
6.2. Если интерфейс подсистемы организован так, что часть настроек и справочников отображаются в отдельной форме, то роль, дающая право на подсистему, должна включать права на просмотр этой формы (например, в УП(ERP) часть справочников в разделах командного интерфейса не вынесены и отображаются в форме, вызываемой командой «Настройки и справочники»).
7. Отчеты
7.1. Если отчет строится на основе данных, входящих в одну элементарную функцию (п. 2.1), то в общем случае права на доступ к такому отчету можно включить в роли, созданные по этой элементарной функции.
Пример:
Отчет по исполнению заказов клиентов полностью строится на основе данных регистр накопления ЗаказыКлиентов, поэтому права на отчет нужно включить в роль, дающую право на чтение регистра.
7.2. Если на внедрении могут возникнуть задачи отдельной настройки прав к отчету, который строится на основе данных, входящих в одну элементарную функцию, то для доступа к такому отчету необходимо создать отдельную роль ПросмотрОтчета<ИмяОтчета> (англ. ViewReport<ReportName>), дающую права использования и просмотра.
Пример:
Хотя отчет по контактной информации отображает данные входящие в элементарную функцию информации о клиентах, но на внедрении может потребоваться ограничить доступ к отчету, который позволяет вывести информацию по всем клиентам сразу.
7.3. Если отчет строится на основе данных, входящих в несколько элементарных функций, необходимо создать роль ПросмотрОтчета<ИмяОтчета>, дающую права использования и просмотра.
Пример:
Отчет по выполнению плана продаж строится на основе данных о планах и данных о продажах. Права чтение этих данных дают роли, относящиеся к разным элементарным функциям. Для реализации доступа к отчету нужно создать отдельную роль.
7.4. Однотипные отчеты при проектировании прав доступа можно объединить в элементарные функции при соблюдении следующих условий:
отчеты не входят в другие элементарные функции (см. п. 7.1);
на внедрении не может возникнуть задачи различной настройки прав доступа к этим отчетам.
8. Обработки и общие формы
8.1. Для каждой обработки, представляющей из себя рабочее место, т.е. в ГКИ есть отдельная команда для открытия этой обработки, должна быть создана роль ИспользованиеОбработки<ИмяОбработки> (англ. Use DataProcessor<DataProcessorName>), дающая права на просмотр и использование.
При этом не допускается объединять права доступа к разным обработкам-рабочим местам в одной роли.
8.2. Права ко всем другим типам обработок, например
вспомогательные обработки, которые нельзя вызвать из глобального командного интерфейса, а можно открыть только из других объектов, например, подбор товаров;
обработки, в которых расположен общий код, например, код формирования печатных форм;
должны быть назначены в роли БазовыеПрава<ИмяБиблиотеки>.
8.3. Права к обработкам, предназначенным исключительно для администратора программы, нужно назначать только роли ПолныеПрава, не создавая отдельных ролей для таких обработок.
8.4. Все эти правила равным образом применяются для общих форм. Название роли для общей формы, описанной в п. 8.1. – ИспользованиеОбщейФормы<ИмяОбщейФормы> (англ. UseCommonForm<CommonFormName>).
8.5 Исключения из этих правил описаны в п. 6.2
Пример:
В УТ 11 права к обработкам ПодборТоваров и ПоискОбъектовПоШтрихкоду назначены роли БазовыеПраваУТ.
9. Команды
9.1. Если команда не предполагает изменение данных, то в общем случае право на просмотр должно быть назначено той роли, которая дает право на просмотр объекта.
т.к. роль, дающая право на изменение объекта дает также права на чтение объекта, нужно не забывать проставлять права на команду и в роли с правом на чтение, и в роли с правом на изменение;
права на команды печати, которые расположены в обработках (это печатные формы, которые печатаются из нескольких объектов) нужно назначать роли БазовыеПрава<ИмяБиблиотеки>
9.2. Если команда связана с изменением данных, то право на просмотр нужно назначить роли, которая дает права на изменение объектов.
10. Права, не связанные с доступом к объектам
10.1. В случае если возникает необходимость давать пользователям какие-то дополнительные права, не связанные с доступом к объектам, нужно создавать роль <НаименованиеПрава>, не дающую доступ ни к одному объекту. При этом в наименовании не нужно использовать слово «Право».
Пример:
Правильно ОтклонениеОтУсловийЗакупок
Неправильно ПравоСозданияВыпускПродукцииБезЗаказа
10.2. В коде конфигурации нужно проверять наличие у пользователя этой роли. Пользователь с ролью ПолныеПрава должен проходить проверку без необходимости включения в его профиль этой роли. Для проверки следует использовать функцию БСП Пользователи.РолиДоступны.
10.3. Использование других механизмов, кроме проверки наличия роли (или какого-то права) при реализации дополнительных прав пользователя, не допускается.
11. Права для внешних пользователей
Роли, предназначенные исключительно для предоставления прав доступа внешним пользователям (представленным в программе одним из объектов, например, элементами справочников Сотрудники, Партнеры, Физические лица и др.), следует называть с определенным префиксом.
Например, префикс Самообслуживание для доступа к рабочему месту по самообслуживанию клиентов в торговом решении:
СамообслуживаниеОформлениеПретензий, синоним Самообслуживание: оформление претензий
СамообслуживаниеПросмотрОтчетаСостояниеВыполненияЗаказа, синоним Самообслуживание: просмотр отчета «Состояние выполнения заказа»
СамообслуживаниеДобавлениеИзменениеКонтрагентов, синоним Самообслуживание: добавление и изменение контрагентов
12. Права к устаревшим объектам
Устаревшие объекты метаданных с префиксом Удалить должны быть исключены из всех ролей, кроме ролей ПолныеПрава или АдминистраторСистемы.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
Например, в УП(ERP) это роль ПартнерСамообслуживание.
1.2. Роль ПолныеПрава (англ. FullAccess) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы) не должна давать право на интерактивное удаление ссылочных объектов.
после создания нового объекта нужно зайти в роль ПолныеПрава и отключить право интерактивного удаления у ссылочных объектов.
1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы, создавать отдельные роли в этом случае не требуется.
1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
Исключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом, которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.
1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование, ТонкийКлиент и т.п.).
при создании новой роли нужно следить, чтобы эти права были выключены.
1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке - для ссылочных данных), а следует включать эти права в роли БазовыеПрава<ИмяБиблиотеки> (англ. BasicAccess<LibraryName>) и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (англ. BasicAccessExternalUser<LibraryName>) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
Чтение<ИмяФункции> (англ. Read<FeatureName>);
ДобавлениеИзменение<ИмяФункции> (англ. InsertUpdate<FeatureName>) (или Изменение<ИмяФункции> (англ. Update<FeatureName>), если добавление выполняется автоматически, либо только администратором).
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
Чтение<ИмяФункции> содержит права:
Чтение, Просмотр, Ввод по строке.
Изменение<ИмяФункции> содержит те же права, что и роль Чтение<ИмяФункции>, а также:
Изменение, Редактирование;
Проведение, Отмена проведения, Интерактивное проведение, Интерактивная отмена проведения, Интерактивное изменение проведенных (для документов);
Управление итогами (для регистров).
ДобавлениеИзменение<ИмяФункции> содержит те же права, что и роль Изменение<ИмяФункции>, а также:
Добавление, Интерактивное добавление;
Интерактивная пометка удаления, Интерактивное снятие пометки удаления.
3.2. Необходимо помнить, что для регистров, подчиненных регистратору, обычно не требуется назначать права на изменение (см. п. 1.7).
4. Журналы документов
4.1. Если все документы, входящие в журнал, отнесены к одной элементарной функции, то права на чтение и просмотр журнала нужно включить во все роли этой функции.
4.2. Платформа 1С:Предприятие имеет следующую особенность: если у пользователя нет прав на чтение любого документа, входящего в журнал документов, то платформа не дает доступ ко всем графам журнала, в котором отражается этот документ, для всех документов, входящих в журнал. Поэтому нет никакого практического смысла создавать отдельную роль для доступа к журналу: журнал может входить в элементарную функцию, или может быть доступен только пользователю с полными правами.
5. Константы
5.1. Если предполагается, что константа должна изменяться только администратором системы, то права на изменение и редактирование должны быть только у одной из ролей: ПолныеПрава или АдминистраторСистемы. Эти роли должны включать также и права на чтение и просмотр констант.
5.2. Если предполагается, что константу может менять пользователь, то нужно включить права на чтение, просмотр, изменение и редактирование в уже имеющуюся «настроечную» роль или создать отдельную роль Изменение<ИмяКонстанты> (англ. Update<ConstantName>), дающую права на чтение, просмотр, изменение и редактирование этой константы.
5.3. В подавляющем большинстве случаев константа используется для хранения неконфиденциальной информации, поэтому права на чтение и просмотр константы нужно назначать роли БазовыеПрава<ИмяБиблиотеки> и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки>. Это позволяет избежать неоправданной установки привилегированного режима при чтении значения константы из кода.
5.4. В редких случаях, когда константа используется для хранения конфиденциальной информации, необходимо создать роль Чтение<ИмяКонстанты> (англ. Read<ConstantName>). При этом, если значение должно быть доступно только администратору, создавать отдельную роль на чтение не требуется.
Например, для константы ПараметрыАдминистрированияИБ создавать отдельную роль на чтение не требуется – достаточно включения прав на чтение и просмотр в роль АдминистраторСистемы.
6. Подсистемы, отображаемые в главном командном интерфейсе
6.1. Для каждой подсистемы верхнего уровня должна быть создана роль Подсистема<ИмяПодсистемы> (англ. Subsystem<SubsystemName>), дающая право на просмотр
6.2. Если интерфейс подсистемы организован так, что часть настроек и справочников отображаются в отдельной форме, то роль, дающая право на подсистему, должна включать права на просмотр этой формы (например, в УП(ERP) часть справочников в разделах командного интерфейса не вынесены и отображаются в форме, вызываемой командой «Настройки и справочники»).
7. Отчеты
7.1. Если отчет строится на основе данных, входящих в одну элементарную функцию (п. 2.1), то в общем случае права на доступ к такому отчету можно включить в роли, созданные по этой элементарной функции.
Пример:
Отчет по исполнению заказов клиентов полностью строится на основе данных регистр накопления ЗаказыКлиентов, поэтому права на отчет нужно включить в роль, дающую право на чтение регистра.
7.2. Если на внедрении могут возникнуть задачи отдельной настройки прав к отчету, который строится на основе данных, входящих в одну элементарную функцию, то для доступа к такому отчету необходимо создать отдельную роль ПросмотрОтчета<ИмяОтчета> (англ. ViewReport<ReportName>), дающую права использования и просмотра.
Пример:
Хотя отчет по контактной информации отображает данные входящие в элементарную функцию информации о клиентах, но на внедрении может потребоваться ограничить доступ к отчету, который позволяет вывести информацию по всем клиентам сразу.
7.3. Если отчет строится на основе данных, входящих в несколько элементарных функций, необходимо создать роль ПросмотрОтчета<ИмяОтчета>, дающую права использования и просмотра.
Пример:
Отчет по выполнению плана продаж строится на основе данных о планах и данных о продажах. Права чтение этих данных дают роли, относящиеся к разным элементарным функциям. Для реализации доступа к отчету нужно создать отдельную роль.
7.4. Однотипные отчеты при проектировании прав доступа можно объединить в элементарные функции при соблюдении следующих условий:
отчеты не входят в другие элементарные функции (см. п. 7.1);
на внедрении не может возникнуть задачи различной настройки прав доступа к этим отчетам.
8. Обработки и общие формы
8.1. Для каждой обработки, представляющей из себя рабочее место, т.е. в ГКИ есть отдельная команда для открытия этой обработки, должна быть создана роль ИспользованиеОбработки<ИмяОбработки> (англ. Use DataProcessor<DataProcessorName>), дающая права на просмотр и использование.
При этом не допускается объединять права доступа к разным обработкам-рабочим местам в одной роли.
8.2. Права ко всем другим типам обработок, например
вспомогательные обработки, которые нельзя вызвать из глобального командного интерфейса, а можно открыть только из других объектов, например, подбор товаров;
обработки, в которых расположен общий код, например, код формирования печатных форм;
должны быть назначены в роли БазовыеПрава<ИмяБиблиотеки>.
8.3. Права к обработкам, предназначенным исключительно для администратора программы, нужно назначать только роли ПолныеПрава, не создавая отдельных ролей для таких обработок.
8.4. Все эти правила равным образом применяются для общих форм. Название роли для общей формы, описанной в п. 8.1. – ИспользованиеОбщейФормы<ИмяОбщейФормы> (англ. UseCommonForm<CommonFormName>).
8.5 Исключения из этих правил описаны в п. 6.2
Пример:
В УТ 11 права к обработкам ПодборТоваров и ПоискОбъектовПоШтрихкоду назначены роли БазовыеПраваУТ.
9. Команды
9.1. Если команда не предполагает изменение данных, то в общем случае право на просмотр должно быть назначено той роли, которая дает право на просмотр объекта.
т.к. роль, дающая право на изменение объекта дает также права на чтение объекта, нужно не забывать проставлять права на команду и в роли с правом на чтение, и в роли с правом на изменение;
права на команды печати, которые расположены в обработках (это печатные формы, которые печатаются из нескольких объектов) нужно назначать роли БазовыеПрава<ИмяБиблиотеки>
9.2. Если команда связана с изменением данных, то право на просмотр нужно назначить роли, которая дает права на изменение объектов.
10. Права, не связанные с доступом к объектам
10.1. В случае если возникает необходимость давать пользователям какие-то дополнительные права, не связанные с доступом к объектам, нужно создавать роль <НаименованиеПрава>, не дающую доступ ни к одному объекту. При этом в наименовании не нужно использовать слово «Право».
Пример:
Правильно ОтклонениеОтУсловийЗакупок
Неправильно ПравоСозданияВыпускПродукцииБезЗаказа
10.2. В коде конфигурации нужно проверять наличие у пользователя этой роли. Пользователь с ролью ПолныеПрава должен проходить проверку без необходимости включения в его профиль этой роли. Для проверки следует использовать функцию БСП Пользователи.РолиДоступны.
10.3. Использование других механизмов, кроме проверки наличия роли (или какого-то права) при реализации дополнительных прав пользователя, не допускается.
11. Права для внешних пользователей
Роли, предназначенные исключительно для предоставления прав доступа внешним пользователям (представленным в программе одним из объектов, например, элементами справочников Сотрудники, Партнеры, Физические лица и др.), следует называть с определенным префиксом.
Например, префикс Самообслуживание для доступа к рабочему месту по самообслуживанию клиентов в торговом решении:
СамообслуживаниеОформлениеПретензий, синоним Самообслуживание: оформление претензий
СамообслуживаниеПросмотрОтчетаСостояниеВыполненияЗаказа, синоним Самообслуживание: просмотр отчета «Состояние выполнения заказа»
СамообслуживаниеДобавлениеИзменениеКонтрагентов, синоним Самообслуживание: добавление и изменение контрагентов
12. Права к устаревшим объектам
Устаревшие объекты метаданных с префиксом Удалить должны быть исключены из всех ролей, кроме ролей ПолныеПрава или АдминистраторСистемы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот