Сейчас в системе можно администрировать полномочия только от объектов.

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

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

1 комментарий

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

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

Спасибо, что делаете наши продукты лучше!

Показать все комментарии

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

Но привязка к пакету данных всех ролей / пользователей критически важен для ряда задач / БП.

Прошу включить данную задачу в ближайший релиз.

5 комментариев

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

 

Здравствуйте, Игорь!

Передали данное пожелание команде разработки для анализа возможности внедрения такой возможности в будущих версиях продукта.

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

Мотков Илья,

Можно подробнее?

 

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

Всё ещё очень ждём реализации этой идеи. Так как управление пакетами с ролями находится в руках клиента, то это очень остро ими ощущается

Показать все комментарии

А подскажите кто-нибудь сведущий по ситуации.

У меня есть такая структура

Изображение удалено.

Имею проблему. Руководители групп Москва-1 и др. могут закрывать задачи на которых права розданы только руководителям Отдела продаж.

Изображение удалено.

Мне кажется так не должно быть. Или я что-то неправильно понимаю?

Нравится

2 комментария
Лучший ответ

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

Попробуйте определить что это за пользователь.

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

И ещё даже, если у пользователя нет прав, то кнопки доступны, но при нажатии на них должно выдаваться сообщение о недостаточности прав.

Проверьте, действительно, ли пользователи могут вносить изменения или это только визуально кнопка доступна.

Руководитель отдела продаж (или какой-то Supervisor) случайно не входит в группу Москва 2?

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

Попробуйте определить что это за пользователь.

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

И ещё даже, если у пользователя нет прав, то кнопки доступны, но при нажатии на них должно выдаваться сообщение о недостаточности прав.

Проверьте, действительно, ли пользователи могут вносить изменения или это только визуально кнопка доступна.

Показать все комментарии

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

Подскажите это нормально? Можно ли изменить матрицу без создания замещающих объектов?

И еще вопрос - как можно матрицу ролей зашить в пакет и выгрузить?

Нравится

8 комментариев
Лучший ответ

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

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

Добрый день! Матрицу ролей можно прописать sql скриптом

Добрый день,

Не замечал такого поведения при изменении ролей. А что за объект у вас создается в кастоме?

 

Тёскин Дмитрий Валерьевич,

Создается объект тот в для которого меняются права (к примеру если меняем доступы для "Контакты" то создается объект "Contact" унаследованный)

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

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

Александр Тыра,

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

Трефилов Павел Сергеевич,

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

Тёскин Дмитрий Валерьевич,

вяше описал поведение если сделать на Dev и перенести на prod пакет то система ругается что не может изменить пакет в итоге только остается пакет Custom. Неужели матрица только так запоминает изменения?

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

Показать все комментарии

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

Чтобы, например, видеть, что пользователь отдела продаж входит в коммерческий департамент.

Нравится

4 комментария

См. обсуждение тут.

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

Там есть пример select-а.

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

Показать все комментарии

За двоение функциональных ролей.
При создании функциональной роли "Менеджер Х". Была добавлена одна запись.

Но при раздаче прав на "Доступ к операциям" их оказалось 2.

Почему так?
Уже не первый раз.
Что надо делать чтобы такого не было?
Спасибо.

Нравится

3 комментария

Разработчик бизнес решений
и
Разрабочики бизнес решений
отличаются наличием буквы "и" и отсутствием буквы "т" во второй роли :smile:

Ок.
Т.е. в этом списке выводиться как функциональная так и орган-е роли ?
А еще момент почему нет иконки пользователи системы?

Н

"ЮМРавильевич" написал:
Т.е. в этом списке выводиться как функциональная так и орган-е роли ?


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

Показать все комментарии