Арнур Келгенбаев, здравствуйте!
Пример построения подобного процесса есть в документации.
То есть, у Вас должно быть включено администрирование прав по записям на объект. 
Далее Вы можете вычитать коллекцию записей, где пользователь консультант (если это поддержано Вашей версией приложения) и передать ее на обработку в подпроцесс, где элементом "Изменить права доступа" необходимо забрать права у всех ролей и пользователей и назначить нужные права пользователю-консультанту.

Мы в проекте делали разделение по отделам (в том числе определение SLA и прав доступа) на основании почтового ящика. 

Если кратко, то в справочнике почтового ящика для регистрации обращений добавили признак (отдел поддержки) и далее настроили процессы для определения SLA (сигнал - создание обращения). На основании SLA перераспределяли права доступа. 

Схема получилась непростая, но рабочая. 

Если вам SLA не надо пересчитывать, то у обращения есть поле - ParentActivity, из него уже можете узнать, на какой ящик оно пришло, и перераспределить права доступа.

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

Настраивать права, которые должны быть на стадии. И при переходе на стадию удалять старые права и добавлять все нужные.
Таким образом после перехода на финальную стадию права на редактирования не будет ни у кого (за некоторым исключением, например)

Отключить галочку у стартового элемента "Выполнять в фоновом режиме"

Алексей-Карягин,

спасибо, попробую!

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

спасибо, буду пробовать

Можно дать доступ по колонкам в доступах на объекты

https://community.terrasoft.ru/questions/programmnoe-blokirovanie-poley…

Добрый день.

Изменять права можно при помощи класса DBSecurityEngine. Пример раздачи прав на колонку:

UserConnection.DBSecurityEngine.SetEntitySchemaColumnRightLevel(adminUnitId, schemaName, columnName, Core.Configuration.EntitySchemaColumnRightLevel.CanEdit);

adminUnitId - Guid пользователя либо группы которой выдаются права.

schemaName - название объекта на который выдаются права.

columnName - название колонки.

EntitySchemaColumnRightLevel - Enum с уровнями прав.

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

Если же имеется ввиду изменение прав через JavaScript то это невозможно в целях безопасности, однако выше кидали ссылку как можно блокировать поля на стороне UI через код js.

n.isaev,
schemaName - название объекта на который выдаются права.

указывать название объектfаили схемы?
 

вот мой код 
 

Guid adminUnitId = new Guid("c3a4d114-c704-4e1c-ba4c-3f2a9fded1b3");
string schemaName = "Opportunity";
string columnName = "Title";
UserConnection.DBSecurityEngine.SetEntitySchemaColumnRightLevel(adminUnitId, schemaName, columnName, Core.Configuration.EntitySchemaColumnRightLevel.CanEdit);
return true;

по трейсу он какбудто не может получить id схемы
System.NullReferenceException: Object reference not set to an instance of an object.
   at Terrasoft.Core.DB.DBSecurityEngine.GetEntitySchemaName(Guid schemaUId)
   at Terrasoft.Core.DB.DBSecurityEngine.SetEntitySchemaColumnRightLevel(Guid adminUnitId, Guid schemaUId, Guid columnUId, EntitySchemaColumnRightLevel rightLevel, Nullable`1 position)
   at Terrasoft.Core.DB.DBSecurityEngine.SetEntitySchemaColumnRightLevel(Guid adminUnitId, String schemaName, String columnName, EntitySchemaColumnRightLevel rightLevel)

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

я включил в объекте администрирование по колонкам, но это не особо помогло(

Dima Avdoshin,

Да, действительно, этот метод нерабочий.

В этом случае блокировать/разблокировать поля динамически можно только на стороне UI при помощи кода JS. Со стороны сервера вы можете раздавать права и отбирать права на конкретную запись, но не на поле.

Добрый день! Вы имеете ввиду редактировать поле на странице? Через бизнес-правила вроде так можно это сделать.

Дмитрий,
Через бизнес-правило "if текущий пользователь = справочник.Пользователь then поле редактируемое"  права на другие колонки же не ограничатся. Плюс, я так понимаю, это правило не позволит другим пользователям редактировать это поле, т.к. будет проходить проверка на текущего пользователя.
Нужно наложить ограничение только на одного п-ля, не затронув остальных.

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

Дмитрий,

Мне как раз нужно, чтобы пользователь не мог редактировать ни одно другое поле кроме выбранного.

Если ставить правила на запрет изменения всех остальных полей через "пользователь!=" , то помимо того, что их будет порядка 30-40, и некоторые из них работать не будут (т.к. creatio воспринимает только 1 правило, завязанное на 1 поле, а другие игнорирует), но ещё такие правила перетрут права доступа, настроенные через Доступ на объекты. =(

Добрый день, 

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

Из неочевидного, руководители роли "Может редактировать одну колонку" также унаследуют эти права. 

Игорь, добрый день.

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

Посмотрите, есть ли ваши объекты в справочнике "список объектов, доступных пользователю портала"

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

Spasibo!

Добрый вечер.

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

Алла Савельева,

Есть даже пример таких скриптов для переноса этих настроек?

Или, может, Terrasoft сделает возможным перенос стандартными средствами? 

Владимир, пока этой функциональности нет в базовой версии, рекомендуем выполнять перенос скриптами. 

Реализовать перенос настроек организационной структуры и прав доступа из одного стенда на другой можно с помощью SQL-скриптов. Для этого на эталонной среде необходимо сформировать insert-запросы на основании записей со следующих таблиц:

• SysAdminUnit (Объект администрирования: пользователи и роли)
• SysUserInRole (Непосредственные вхождения пользователей в роли)
• SysFuncRoleInOrgRole (Вхождение функциональной роли в организационную)
• SysAdminOperation (Системные операции, если необходимо)
• SysAdminOperationGrantee (Доступ к системным операциям, если необходимо)
• SysEntitySchemaOperationRight (Доступ к объектам)
• SysEntitySchemaRecordDefRight (Доступ к записям по умолчанию)
• SysEntitySchemaColumnRight (Доступ к колонкам объекта)
• SysAdminUnitGrantedRight (Делегирование)

Для формирования запросов можно воспользоваться Microsoft SQL Server Database Publishing Wizard и подобными инструментами. Полученный SQL-скрипт необходимо прикрепить к пакету (вкладка - «SQL-сценарии»).

Если перенос происходит на продуктивную среду, то мы рекомендуем предварительно сделать резервное копирование данных, и, в первую очередь, заливать пакет на тестовую среду, чтобы проверить результат выполнения скрипта. Эти работы необходимо выполнять не в бизнес-время.

Ещё очень интересное поведение заметили.

Записи SysEntitySchemaColumnRight были перенесены полностью идентично на рабочую среду (проверили после переноса). А через некоторое время на рабочей среде оказались те же записи, но с совершенно другими Id. 

Какие процессы могут полностью сменить Id в этой таблице? И на что это может повлиять?

Может, компилировали объект? Актуализацию прав запускали?

Зверев Александр пишет:

Может, компилировали объект? Актуализацию прав запускали?

Да, компиляция же происходит после каждой установки новых пакетов (с того же Marketplace), насколько я понимаю.

И актуализация прав запускается после изменений в пользователях/ролях.

1. Но как это влияет на настройки доступа по колонкам?

2. И как переносить последующие изменения в настройках доступа по колонкам, если по Id уже не понять, это те же настройки или уже другие?

Владимир, логика перераздачи прав не предусматривает сохранения Id записей. Вы можете предусмотреть в своих скриптах привязку не к Id, а к SysAdminUnitId, SubjectColumnUId и SubjectSchemaUId, они должны быть стабильными.

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