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

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

Добрый день,

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

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

Нравится

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

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

 

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

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

Дмитрий,

 

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

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

Добрый день, 

 

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

 

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

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

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

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

Нравится

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

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

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

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