Size: a a a

1С, БСП, DevOps и Архитектура

2020 April 20

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
Подскажите как делать *правильно* такое вот:
Мне нужно предоставлять роль на выполнение операции, напрмер "Право верифицировать договора" или "Право предоставлять макс. скидку",

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

И потом где это необходимо проверяю наличие у пользователя этой роли через "Роль доступна"

Но тут вот (в этой группе) проскакивало - что так делать типа "не кошерно"... за это некоторые готовы прям "убивать"

Поэтому и интересуюсь, какой метод "кошерный"?
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
с учетом того, что этот подход даже описан в ЖКК, не вижу в нем ничего плохого.
да, если в конфигурации есть механизм дополнительных настроек пользователя, то имеет смысл такое выносить в него. но если его нет, то использование ролей - готовый платформенный механизм, который позволяет это реализовать.
разве что вместо платформенной РольДоступна стоит использовать БСПшную, которая автоматом еще и ПолныеПрава проверит
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Василий Мазурок
Подскажите как делать *правильно* такое вот:
Мне нужно предоставлять роль на выполнение операции, напрмер "Право верифицировать договора" или "Право предоставлять макс. скидку",

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

И потом где это необходимо проверяю наличие у пользователя этой роли через "Роль доступна"

Но тут вот (в этой группе) проскакивало - что так делать типа "не кошерно"... за это некоторые готовы прям "убивать"

Поэтому и интересуюсь, какой метод "кошерный"?
Чем аргументируют те? И как предлагают?
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
с учетом того, что этот подход даже описан в ЖКК, не вижу в нем ничего плохого.
да, если в конфигурации есть механизм дополнительных настроек пользователя, то имеет смысл такое выносить в него. но если его нет, то использование ролей - готовый платформенный механизм, который позволяет это реализовать.
разве что вместо платформенной РольДоступна стоит использовать БСПшную, которая автоматом еще и ПолныеПрава проверит
Я о БСП-ной и говорю. (точнее я ее оттуда заимствовал, но как раз с целью проверять полные права)

В конфигурации есть механизм настроек.
Но я как раз хочу от него уйти. Т.к. получается что права есть и там и там.

Ранее в конфигруаци была всего одна роль "Полные права" - всем было все можно. А какие-то доступы и ограничения как раз через "ПВХ и РС" регулировались.

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

ВМ

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

IS

Ivan Smirnov in 1С, БСП, DevOps и Архитектура
Зло разве что в том, что появляется огромное количество ролей. Но если посмотреть на список ролей той же ERP2 то уже не так переживаешь за это)
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Василий Мазурок
Да в том то и дело, что я уловил сам факт что якобы "это зло"... а вот аргументации не заметил.
Поэтому и решил тему "актуализировать"...
Раз уж я "на пороге" изменений что бы потом не переделывать еще раз на "более-правильный" вариант
Ну если механизм настроек уже есть то зачем засирать атомарные роли ещё и правами на функциональность?
источник

BS

Basil Stepanov in 1С, БСП, DevOps и Архитектура
в УНФ, например, право редактирования цен в ТЧ для профиля Менеджер выведено в отдельную роль
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
John Doe
Ну если механизм настроек уже есть то зачем засирать атомарные роли ещё и правами на функциональность?
Потому что и одну то систему распределения прав админить - нелегкое дело.
А держать в актуальном состоянии две...

"Механизм настроек" находится в стадии перевода на атомарные роли.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Ну и также учитывай, что через роли никак не сделаешь применение настройки на лету, без необходимости перезапуска сеанса
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
John Doe
Ну и также учитывай, что через роли никак не сделаешь применение настройки на лету, без необходимости перезапуска сеанса
Долго над этим думал. И решил что я с этим смирюсь.
Перезапуск сеанса происходит не "ацки-долго".
И если уж кому-то изменили уровень доступа - то "заставить его перезайти" - дело не самое сложное.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Василий Мазурок
Потому что и одну то систему распределения прав админить - нелегкое дело.
А держать в актуальном состоянии две...

"Механизм настроек" находится в стадии перевода на атомарные роли.
А зачем вообще две, нельзя обойтись проверкой наличия атомарной роли на чтение / изменение при проверке функциональности?
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Ну и ещё учитывай, что добавление в атомарные роли ещё и ролей для функциональности влечет размножение профилей групп доступа и по сути ппрекидывание юзеров между ними будет твоим вторым местом алминистрирования, от которого ты хочешь уйти
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Если профили не используешь то пожалуйста - клепай роли на функциональность
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
John Doe
А зачем вообще две, нельзя обойтись проверкой наличия атомарной роли на чтение / изменение при проверке функциональности?
Ну вот пример.
"Право верифицировать договор" - пользователь с этим равом - читает договор, и говорит "ВСЕ НОРМ".
Для этого он открывает карточку договора. И ставит там "галку".

При этом "атомарная роль на запись есть у большинства", ...
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Василий Мазурок
Ну вот пример.
"Право верифицировать договор" - пользователь с этим равом - читает договор, и говорит "ВСЕ НОРМ".
Для этого он открывает карточку договора. И ставит там "галку".

При этом "атомарная роль на запись есть у большинства", ...
Ну вот тебе придётся два профиля делать
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
John Doe
Ну и ещё учитывай, что добавление в атомарные роли ещё и ролей для функциональности влечет размножение профилей групп доступа и по сути ппрекидывание юзеров между ними будет твоим вторым местом алминистрирования, от которого ты хочешь уйти
Профили - пока только в планах. Потому что уже сейчас ... это ацкий ад.. добавлять в ручную пользователям атомарные роли.

Поэтому буду брать что-то  БСП-ное. И как раз уходить от сложностей. За счет определения "Бизнес-ролей" которые будут назначатся пользователю.

И меня как администратора будет заботить только корркетность настройки роли.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Чтото ты сам себе притиворечишь. Выше пишешь что делаешь атомарные роли, а сейчас что уже функуиональными хочешь ограничиваться
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
John Doe
Ну вот тебе придётся два профиля делать
Да. У одно будет роль "Право верифицировать" а у другого нет.
Один "рядовой сторудник"
второй "Руководитель отдела".

Так я это себе вижу.
А насчет... "а добавь рядовому сотруднику - только одну фнукцию руководиеля " - такие пожелания будут отвергаться ))) Аргументированно.

Т.е. или "превращаем" рядового в руководителя - или он без нужных Вам ролей.

или (третий вариант) в оргструктуре рождаем еще одну роль. Рисуем под нее профиль и назначем ее "помощнику руководителя"
источник

ВМ

Василий Мазурок in 1С, БСП, DevOps и Архитектура
Возможно мы не понимаем друг друга?
Атомарные - это когда есть одна роль на один объект.
Функциональные - это что ?
источник