Доброго времени суток!

В ходе настройки БП появилась задача по настройке прав доступа к записям раздела сотрудникам-пользователям системы. Соответственно, добавил элемент "Изменить права доступа". Если вкратце о БП, то логика такая: находим Guid сотрудника-консультанта, затем передаем строковое значение этого Guid в переменную ConsultantIdString БП, затем начинаем новую выборку по контактам, чьим консультантом является пользователь с ConsultantId = ConsultantIdString, затем начинаем цикл, в котором забираем права доступа (чтение, редактирование, удаление) у консультанта ко всем записям, которые не соответствуют условию ConsultantId = ConsultantIdString. Дальше даем доступ (чтение, редактирование, удаление) ко всем записям которые соответствуют условию ConsultantId = ConsultantIdString. Когда просматриваю данные трассировки, то выходит следующее: 

"Параметр": "Список прав на удаление",
            "Значение": {
                "Перед выполнением": "[{Id:\"a6bca657-858b-404c-9f74-fed573d2bee4\",ParameterName:\"Employee1\",Name:\"Консультант\",CanRead:true,CanEdit:true,CanDelete:true,Source:\"3\",Grantee:\"Employee\",Value:\"[#Lookup.16be3651-8fe2-4159-8dd0-a803d4683dd3.5b40e682-84ae-45d8-9d24-75f46fa557b9#]\"}]",
                "После выполнения": "[{Id:\"a6bca657-858b-404c-9f74-fed573d2bee4\",ParameterName:\"Employee1\",Name:\"Консультант\",CanRead:true,CanEdit:true,CanDelete:true,Source:\"3\",Grantee:\"Employee\",Value:\"[#Lookup.16be3651-8fe2-4159-8dd0-a803d4683dd3.5b40e682-84ae-45d8-9d24-75f46fa557b9#]\"}]"
            }

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

Также прикрепил скрин самого БП и элемента по удалению прав доступа для консультантов.

Прикрепленные файлы

Нравится

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

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

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

Здравствуйте коллеги,

Поставлена такая задача: 
Есть список операторов. У каждого оператора настроен 1 почтовый ящик с которого он видит письма в Creatio. Обращения создаются со всех писем. Так вот, как дать возможность оператору видить только те обращения которые были созданы на почве письма к которому у оператора есть доступ (1 оператор - 1 ящик)

Спасибо!

Нравится

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

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

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

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

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

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

Добрый день, коллеги.

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

После переноса пакета не тест, все прекрасно кроме одного. Сотрудник в этой функциональной роли не видит обращения, хотя если зайти в права раздела обращений то у этой роли есть  по операциям на чтение. а среди прав на запись есть права на записи от всех пользователей на чтение.

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

И  все становится прекрасно.

Почему при переносе не работает актуализация? 

И можно ли запустить процесс на актуализацию прав к записям через SQL  скрипт?

 

Нравится

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

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

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

Добрый день,

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

версия 

7.16.2.1600

Нравится

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

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

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

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

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

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

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

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

Для некоторых сложных списков и отчётов приходится создавать View и объекты на их основе. Однако необходимо и учитывать права доступа на записи в этих объектах. 

Для этого предлагаю:

1. В свойстве "Режим использования" колонок объекта добавить значение (например, "Системные"). Колонка с таким свойством будет доступна в отчётах, фильтрации esq, в бизнес-процессах. Но будет недоступна в аналитике, настройке колонок в реестрах и деталях, в фильтрах в реестре. (Таким образом ещё облегчим пользователю интерфейс, убрав из фильтров и аналитики служебные колонки).
2. Добавить аналогичное свойство "Режим использования" для объектов. Кроме ограничения доступа, опять же облегчаем интерфейс пользователю, легко скрыв неиспользуемые объекты вообще
3. Позволить использовать VIEW (наряду с таблицами) для определения прав доступа на записи. Это позволит гибко настраивать права как для объектов на базе реальных таблиц (например, в зависимости от значений записи), так и позволит быстро и гибко (даже в зависимости от текущего времени, дня недели и температуры за бортом :) ) назначать права на записи объектов на основе VIEW

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

Добрый день, Владимир!

 

Благодарю за детальное описание идеи.

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

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

Добрый день

Если у пользователя нет прав на редактирование карточки объекта (Счета), можно ли через программный код дать право на редактирование одного поля в данном объекте? Реализация через код кажется оптимальной , т.к. настройка прав через доступ по колонкам в данном сценарии требуется все таки дать пользователю права на редактирование счета, но прописать в блоке "Доступ по колонкам", что на все поля, кроме одного у данного пользователя право только на просмотр.

Нравится

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

Добрый день.

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

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

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

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

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

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

 

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

 

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

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

Добрый день.

Изменять права можно при помощи класса 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. Со стороны сервера вы можете раздавать права и отбирать права на конкретную запись, но не на поле.

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

Добрый день,

Мне необходимо ограничить пользователю права доступа: может редактировать в записях раздела только одно поле.  В голову приходит только костыльный вариант - дать право доступа Редактирование на данную колонку в доступах на объекты, а по всем остальным колонкам (а их очень много) Чтение. Но тут есть риск покалечить права доступа других пользователей, а их задевать нельзя.

Может, предусмотрен какой-то более удобный способ? 

Нравится

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

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

 

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

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

Дмитрий,

 

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

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

Добрый день, 

 

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

 

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

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

Доброго времени суток.

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

Нравится

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

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

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

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

Для всех новых таблиц созданных в своем пакете, не кастом у портальных юзеров не выбираются данные, на тех же детальках, и не добавляются тоже.
Ошибка при добавлении в таблицу с правами в консоли на скрине. 

  Права все выданы как и на операции так и по записям - 100%.
*Компилировал, генерировал схемы, чистил редис.
**Что интересно, для все старых схем права работают.

 

Нравится

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

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

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

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

Spasibo!

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

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

 

Удалось успешно привязать к данных

  • Доступ к объектам - SysEntitySchemaOperationRight
  • Операции - SysAdminOperation
  • Права на операции - SysAdminOperationGrantee

 

Однако

  • настройку прав на колонки SysEntitySchemaColumnRight
  • и настройку прав по умолчанию SysEntitySchemaRecordDefRight

добавить в пакет не получается - просто не даёт выбрать такие объекты.

Как лучше поступить для решения?

Нравится

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

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

Подобные темы уже обсуждались на 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, они должны быть стабильными.

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

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