Добрый день.

Может прав нет у УЗ под которой вы авторизованы?

Добрый день, Алёна

В нашей системе вы можете настраивать права доступа по объектам. В данном случае как объект мы рассматриваем раздел "Единое окно".

Если для данного объекта не используется ограничение доступа по записям, то все пользователи имеют полный доступ ко всем итогам в системе. Это значит, что кнопка [Настроить права доступа] в меню действий будет неактивной (серой).

Если ограничение по записям используется, то права доступа на отдельные панели итогов настраиваются по действию [Настроить права доступа] меню действий.

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

Sorotiuk Anna,

При настройке прав доступа к записям раздела "Контакт" во вкладке "Доступ к объекту" открыл пользователям с ролью "Консультант" доступ на чтение. Во вкладке "Доступ к записям по умолчанию: чтение" никаких настроек нет. Затем запустил БП, который дал консультанту право на чтение, изменение и удаление к 2 тестовым записям. В итоге в разделе консультант видит 238 записей. Вопрос: как можно проверить, по какой причине появились 236 записей? 

Мы в проекте делали разделение по отделам (в том числе определение 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. Потому что, доступность некоторых переходов зависит не только от ролей, но и от бизнес логики по обработке обращений. Ваше пожелание было зарегистрировано для ответственной команды разработки. Возможно, в следующих релизах появиться такая возможность.