Добрый день.



Описанную логику можно реализовать с помощью ScripTask элемента в бизнес процессе.

Подробнее про элемент процесса [Задание-сценарий]:

https://academy.terrasoft.ua/docs/7-17/user/biznes_processy/spravka_po_…



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

https://academy.terrasoft.ua/docs/7-17/developer/back_end_razrabotka/bi…



Также рекомендую ознакомиться с другим постом, в нем подробно рассматривалась логика добавления пользователя:

https://community.terrasoft.ua/questions/zapusk-processa-po-sozdaniyu-p…

Варианта два:

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

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

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

Ответы на ваши вопросы вы можете найти в статьях на Академии: 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

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

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

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

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

Илья,

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

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

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

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

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

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

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

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

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

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

{
"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. Остается только в методе инициализации страницы поправить в зависимости от нужной логики какие действия будут доступны пользователю с определенной ролью.