Доброго дня, коллеги!

Есть раздел с несколькими страницами, соответственно кнопка [Добавить] с выпадающим списком.

Изображение удалено.Как пример, нужно разрешить одной группе пользователей создавать один тип, а другой группе - другие. 

Мини-карточка не подходит т.к. заказчик отказывается от нее.

Возможно ли это в Creatio сделать настройками или только кодом?

Нравится

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

Добрый день!



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

Единственный способ - реализация разработкой.



 

В свою очередь я создам пожелание для команды R&D. Мы будем собирать отзывы пользователей и возможно этот функционал реализуют в будущих версиях.



C уважением,

Богдан

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

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

Существует сервис, который программно создает заказы через прямые insert, таким образом событийная логика не отрабатывает. Необходимо программно назначить права на объект заказ, который настроены в правах доступа на объекты. Возможно существует встроенные методы, которые назначают права на объект?

Нравится

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

на ум приходит автозаполнение поля, по которому происходит переход заказа на стадию кейса и на стадии уже запускается процесс распределения прав

 

Можно вторым insert добавить права в SysOrderRights

Я бы перевёл сервис на работу с Entity, если не было каких-то очень серьёзных оснований реализовывать именно так. Потому что в дальнейшем это ещё больше проблем будет создавать.

Но вообще класс RightsHelper должен помочь

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

Подскажите сталкивался ли кто-то с тем, что в правах доступа на объект не удавалось выбрать операцию экспорта (http://joxi.ru/n2Y3DL1ckOyQ5r) список пустой (версия 7.18.5)?

Может кто-то нашел решение?

Нравится

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

Добрый день! Подскажите, пожалуйста, где сделать кнопку "Настроить права доступа" в панели итогов в разделе Единое окно активной? На одном проекте активна, а на другом нет. Не понимаю, где искатьИзображение удалено.

Нравится

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

Добрый день.

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

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



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



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

 

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

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

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

В ходе настройки БП появилась задача по настройке прав доступа к записям раздела сотрудникам-пользователям системы. Соответственно, добавил элемент "Изменить права доступа". Если вкратце о БП, то логика такая: находим 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#]\"}]"

            }

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

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

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

Нравится

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

Арнур Келгенбаев, здравствуйте!

Пример построения подобного процесса есть в документации.

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

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

Sorotiuk Anna,

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

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

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



Поставлена такая задача: 

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



Спасибо!

Нравится

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

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



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



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



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

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

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