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

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

Нравится

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

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

with tempRecursive(Id, Name, ParentRoleId, level) as (
    select Id, Name, ParentRoleId, 0 as level
    from SysAdminUnit
    where id = '5905BE45-DFF1-4756-AF7C-92C6182F4602'
    Union All
    Select SysAdminUnit.Id, SysAdminUnit.Name, SysAdminUnit.ParentRoleId, (level+1) as level
    from tempRecursive join SysAdminUnit on tempRecursive.ParentRoleId = SysAdminUnit.Id
)

select * from tempRecursive
order by level

Варианта два:
1. Просканировать в системе все его роли. Вариантов не так много, Вы их все перечислили - фукциональная роль, орг. роль, руководитель + он может входить в роль системных администраторов явно или через подчиненного.
2. Проверить в БД таблицы SysAdminUnitInRole и SysUserInRole.

В 5.Х была C#-функция UserConnection.DBSecurityEngine.GetUserAdminUnitCollection. Возможно, и в 7.Х есть такая же. В качестве параметра — Id пользователя или без параметров для текущего.

Антон Малий пишет:

Таким образом он показывает только 1-е и прямое вхождение пользователя в роль. И никакие унаследованные роли так не видны.

Очевидно, нужно писать рекурсивный Select с разными проверками. Но я подозреваю, что уже такой функционал существует

Владимир Соколов,

К сожалению, готового скрипта нет. Можно воспользоваться функцией, предложенной Александром.

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

with tempRecursive(Id, Name, ParentRoleId, level) as (
    select Id, Name, ParentRoleId, 0 as level
    from SysAdminUnit
    where id = '5905BE45-DFF1-4756-AF7C-92C6182F4602'
    Union All
    Select SysAdminUnit.Id, SysAdminUnit.Name, SysAdminUnit.ParentRoleId, (level+1) as level
    from tempRecursive join SysAdminUnit on tempRecursive.ParentRoleId = SysAdminUnit.Id
)

select * from tempRecursive
order by level

Действительно, в итоге оказалось, что все права можно найти в SysAdminUnitInRole

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

В системе введено 2 сущности: элементы организационной структуры "Орг.юниты" и "Функциональные роли", в каждую из них по отдельности можно включать пользователей, и друг друга.
Причем включение одной сущности в другую создает реверс-тождественную связь (Добавление Функ.роли в Орг.Юнит равнозначно добавлению Орг.Юнита в Функ.Роль, эти связи вне зависимости от направления даже описываются в одной таблице).
Так вот, логично было бы предположить что данное разделение для обеспечения многопользовательского режима в приложении имеет смысл на уровне предоставления прав доступа, но эксперимент показывает весьма непредсказуемое поведение:
Пользователь А включен в Функц.Роль B которая в свою очередь включена в Орг.Юнит C.
В настройках прав доступа, например на объект "Контакты", установлено запрещающее правило на "Чтение", что фактически скрывает раздел для Орг.Юнита C.
Логическая цепочка: Пользователю A, раздел контакты станет недоступен, т.к. он входит в Функ.Роль B которая в свою очередь входит в Орг.юнит С, которому запрещено чтение по объекту "Контакты".
Фактически: Пользователю A - остается доступен раздел "Контакты", и ограничение он получает только если будет непосредственно включен в Орг.Юнит C
т.е. ограничения распостраняются только на пользователей непосредственно включенных в соответствующую Функ.роль или Орг.Юнит, через включение их друг в друга пользователям не наследуются никакие разрешения целевой группы, так же как и пользователям целевой что либо от включаемой.

А теперь самый главный вопрос: Зачем ?!
Какой смысл в 2-х сущностях, и в возможности их связи друг с другом, если это ни коим образом не связано с наследованием предоставленных разрешений ?!
И зачем вообще тогда нужны Функциональные роли...
В чем вообще "соль" обособленности Орг.Юнитов и Функ.Ролей ?

Нравится

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

Здравствуйте, Илья.

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

Ответы на ваши вопросы вы можете найти в статьях на Академии: https://academy.terrasoft.ru/documents/sales-team/7-9/razdel-upravleniy…
https://academy.terrasoft.ru/documents/sales-team/7-9/stranica-organiza…
https://academy.terrasoft.ru/documents/sales-team/7-9/stranica-funkcion…

Также, рекомендуем вам просмотреть видео:
https://www.youtube.com/watch?v=mSWfz61NKFI
https://www.youtube.com/watch?v=x5C6VcOhKj4

В них поясняются все особенности работы с Организационными и Функциональными ролями и описаны примеры настройки прав доступа для Функциональных и Организационных ролей.

Ну с членством в другой функ.роли которой явно разрешено и разрешающее правило расположено выше - понятно.

а вот тут, прошу пару слов пояснения:

"Мария Ватулина" написал:входить в дргую функциональную роль, которой доступ к данному разделу не запрещен

Т.е. включая пользователя в Орг.юнит или Функ.роль которой явно что-то не запрещено, все связанные явно заданные запрещающие правила всех других включений для пользователя - не применяются ?

Илья,

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

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

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

Добрый день!

Имеется несколько типов контрагентов, для каждого из которых создана страница со своей логикой.
Естественно, что не все пользователи имеют право создавать Поставщиков, Агентов и уж тем более Нашу компанию.
Скорее всего, необходимо создать функциональные роли: Agent manager, Vendor manager и т.п.

Но как в зависимости от функциональных ролей скрывать или показывать пункты меню Add?
Add Account

Нравится

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

В данной ситуации вижу 2 выхода:
1. Попробовать назначить права на объект "Тип контрагента". Как вариант ESQ не будет возвращать тип КА без разрешения на него и он не будет отображаться в кнопке.
2. Изменить логику в странице реестра контрагентов. Проверять к какой роли относится текущий пользователь и добавлять доступные для роли типы КА.

"Царьков Сергей Вячеславович" написал:1. Попробовать назначить права на объект "Тип контрагента". Как вариант ESQ не будет возвращать тип КА без разрешения на него и он не будет отображаться в кнопке.
2. Изменить логику в странице реестра контрагентов. Проверять к какой роли относится текущий пользователь и добавлять доступные для роли типы КА.

1-й вариант не подойдёт, так как пользователь должен видеть другие типы, но не создавать их.

А в какой схеме прописывается эта логика реестра контрагентов?

Изменить логику в странице реестра контрагентов. Проверять к какой роли относится текущий пользователь и добавлять доступные для роли типы КА.

Мне кажется, лучше не привязвавться к конкретной роли, а создать новую операцию (в «Права доступа на операции», таблица SysAdminOperation), выдать пользователю или роли права на эту операцию, и в коде страницы уже запрограммировать проверку на наличие права.

Логику, скорее всего, менять на странице AccountSectionV2, но надо смотреть.

"Владимир Соколов" написал:

А в какой схеме прописывается эта логика реестра контрагентов?


Логика действительно меняется на странице AccountSectionV2. Но копнуть нужно глубже - на странице BaseSectionV2 в diff есть объявление кнопки

{
"operation": "insert",
"name": "SeparateModeAddRecordButton",
"parentName": "SeparateModeActionButtonsLeftContainer",
"propertyName": "items",
"values": {
	"itemType": Terrasoft.ViewItemType.BUTTON,
	"style": Terrasoft.controls.ButtonEnums.style.GREEN,
	"caption": {"bindTo": "AddRecordButtonCaption"},
	"click": {"bindTo": "addRecord"},
	"classes": {
		"textClass": ["actions-button-margin-right"],
		"wrapperClass": ["actions-button-margin-right"]
	},
	"controlConfig": {
		"menu": {
	        	"items": {
				"bindTo": "EditPages",
				"bindConfig": {
					"converter": function(editPages) {
					if (editPages.getCount() > 1) {
					return editPages;
					} else {
					return null;
					}
				}
			}
		}
	}
}
}
},

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

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

Продолжаем выпускать видеоуроки по настройке системы. В данном видеоуроке вы узнаете о назначении организационных и функциональных ролей, а также о том, как выполнить их настройку в bpm'online.

Видео доступно по ссылке: Формирование организационной структуры и функциональных ролей

Больше видеоуроков для старта работы с bpm'online доступно на академии Terrasoft.

Нравится

Поделиться

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