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



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

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



Спасибо!

Нравится

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

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



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



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



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

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



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



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



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

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

Для некоторых сложных списков создали View и объекты на их основе. Но в этих списках необходимо так же распределить права на записи. Можно ли каким-то образом эти права определять так же в другом View? 

Нравится

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

Добрый день!

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

Sorotiuk Anna пишет:

Добрый день!

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

ЕщеСвернуть

Проблема в том, что View не хранит записи, а выбирает при каждом Select. Если включит права на объект, то нужно будет высчитывать и хранить эти права в таблице Sys....Rights. Но необходимо, чтобы система брала права не из таблицы, а из другого View

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

Реализовать настройку прав на View так, чтобы "определялись права в другом View" невозможно.

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

Добрый день, имеется развернутый локально Creatio. Хочу добавить лэндинг(чтобы можно было к примеру перейти на localhost/landing/index.aspx) с формой, у которой есть поле phone и данные введенные в поле будут попадать в контакты -> мобильный телефон уже к имеющемуся контакту.

Что уже сделал?

Сейчас контакт выглядит следующим образом

Изображение удалено.

Как описано в документации добавил лэндинг. Сжато он выглядит так:

Изображение удалено.

После чего в папке ../0/Nui/ создал папку Landing с файлом index.aspx в котором лежит следующий код:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <!--ШАГ 2-->
    <!--Эту часть необходимо скопировать из поля ШАГ 2 страницы редактирования лендинга-->
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
    <script src="https://webtracking-v01.bpmonline.com/JS/track-cookies.js"></script>
    <script src="https://webtracking-v01.bpmonline.com/JS/create-object.js"></script>
    <script>
 
    var config = {
        fields: {
            "Subject": "#subject-field",
            "Email": "#email-field",
            "Name": "#name-field",
            "MobilePhone": "#phone-field",
        },
        landingId: "54a57d16-e7b6-4c7d-9c38-237cfcf6512d",
        serviceUrl: "http://localhost/0/ServiceModel/GeneratedObjectWebFormService.svc/SaveWebFormObjectData",
        redirectUrl: "yandex.ru"
    };
 
    function createObject() {
        landing.createObjectFromLanding(config)
    }
    </script>
    <!--ШАГ 2-->
</head>
<body>
<h1>Landing web-page</h1>
<div>
    <h2>Case form</h2>
    <form action="localhost/0/ServiceModel/GeneratedObjectWebFormService.svc/SaveWebFormObjectData" method="POST" class="mainForm" name="landingForm" onSubmit="createObject(); return false">
        Subject:<br>
        <input type="text" name="subject" id="subject-field"><br>
        Email:<br>
        <input type="text" name="Email" id="email-field"><br>
        Name:<br>
        <input type="text" name="Name" id="name-field"><br>
        Phone:<br>
        <input type="text" name="Phone" id="phone-field"><br><br>
        <input type="submit" value="Submit">
        </font>
    </form>
</div>
</body>
</html>

Если я правильно понял для того чтобы POST запрос прошел корректно должен отработать файл GeneratedObjectWebFormService.svc. Нужно ли его создавать по документации или он является дефолтным? При попытки отправки запроса возникает 403 ошибка. Как сделать это рабочим и какие ошибки я совершил?

Изображение удалено.

Изображение удалено.

Нравится

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

А зачем вы пытаетесь добавить лендинг внутри того же сайта, где развёрнута система? Обычно он нужен для отдельного сайта, например, страницы регистрации на сайте компании. При таком размещении, как сделали Вы, может незалогиненного пользователя при попытке открыть эту страницу перебросить на страницу логина. А для залогиненных есть более подходящие способы, вроде БП с автогенерируемыми или преднастроенными страницами.

 

Как минимум, у Вас неправильный адрес стандартного веб-сервиса GeneratedWebFormService, к которому пытались обратиться со страницы. Поскольку он анонимный, там не нужен /0/. См. тут, как выглядит и где настраивается путь к нему.

 

Если нужно сделать отдельную страницу на сервере с этой формой, можно поднять в IIS ещё один сайт из одной HTML-страницы, где и настроить по инструкции связь с лендингом.

А зачем вы пытаетесь добавить лендинг внутри того же сайта, где развёрнута система? Обычно он нужен для отдельного сайта, например, страницы регистрации на сайте компании. При таком размещении, как сделали Вы, может незалогиненного пользователя при попытке открыть эту страницу перебросить на страницу логина. А для залогиненных есть более подходящие способы, вроде БП с автогенерируемыми или преднастроенными страницами.

 

Как минимум, у Вас неправильный адрес стандартного веб-сервиса GeneratedWebFormService, к которому пытались обратиться со страницы. Поскольку он анонимный, там не нужен /0/. См. тут, как выглядит и где настраивается путь к нему.

 

Если нужно сделать отдельную страницу на сервере с этой формой, можно поднять в IIS ещё один сайт из одной HTML-страницы, где и настроить по инструкции связь с лендингом.

Зверев Александр,

Добрый день, подскажите как разрешить службу? Так полагаю что это что-то связанное с настройками приватности функции или что-то вроде того.

Нет, дело не в этом. Посмотрите второй абзац прошлого ответа.

Зверев Александр,

исправил без /0/ теперь следующую проблему не могу побороть 

политика CORS дефолтная и выглядит так:

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

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

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

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

Если стандартными средствами невозможно реализовать данный функционал, что посоветуете, в какую сторону смотреть?

 

Заранее благодарен!

Нравится

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

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

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

Механизм открытия карточки из очереди реализуется в БП «Обработка обращений из очереди в Едином окне», недавно обсуждавшемся.

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

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

Если у пользователя права:

  1. [Доступ к объекту]: [Чтение] = ДА, [Добавление] = НЕТ, [Изменение] = НЕТ,  [Удаление] = НЕТ, либо
  2. [Доступ к записи]: [Чтение] = ДА, [Добавление] = НЕТ, [Изменение] = НЕТ,  [Удаление] = НЕТ

тогда почему при выделении записи в реестре у него есть кнопки [КОПИРОВАТЬ] и [ИЗМЕНИТЬ], а в карточке доступна кнопка [СОХРАНИТЬ]?

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

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

Так и в чём заключается идея? Убрать кнопки, добавить проверки?

Зверев Александр,

идея в том  чтобы не показывать возможность действия (в банальном случае кнопки), на которое все равно нет прав!

В таком случае права для каждой записи нужно будет проверять заранее. Или при выделении записи, или даже при открытии страницы реестра, в зависимости от реализации. Если второе, то это существенно увеличит нагрузку на базу при повседневной работе.

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

Добрый день! 



Подскажите, пожалуйста, как формируется набор прав доступа для входящих писем, пришедших на общий почтовый ящик?



Рассмотрели возможные варианты:

1. Default rights на Activity

2. Allow shared access в настройках почтового ящика

3. Access rights в настройках почтового ящика

Но всё равно в письме появляется не только владелец почтового ящика (что, наверное, логично), но и All employees, от которых надо избавиться





И второй вопрос - почему на исходящие письма с общего почтового ящика не действует такое же распределение прав? Там только автор права получает

Нравится

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

Владимир, нужно искать в скриптах то место, где при синхронизации создаётся запись. Видимо, там выдаются и права. Смотрите в сторону LoadExchangeEmailsProcess, из него ExchangeUtility, ExchangeEmailSyncProvider, ExchangeEmailMessage. Возможно, это тут (в последней):

public Activity GetActivityInstance(SyncContext context, LocalItem localItem, EntitySchema schema,
	Exchange.EmailMessage message, string subject) {
	var instance = (Activity)schema.CreateEntity(context.UserConnection);
	SyncEntity instanceSync = GetActivityInstanceSync(context, message, subject, instance);
	if (instanceSync.Action != SyncAction.Create &amp;&amp; !context.UserConnection.GetIsFeatureEnabled("MailboxRightsForEmail")) {
UpdateEmailRelations(context.UserConnection, instance);
	}
	localItem.AddOrReplace(schema.Name, instanceSync);
	return instance;
}

 

Краткое резюме - этих настроек оказалось достаточно. Просто, система не сразу реагировала на их изменение. И получая письма в течение нескольких минут после изменения, всё ещё действовали старые настройки.

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

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



Предлагаю создать такой признак, чтобы иметь возможность совмещать автоматическое и ручное распределение прав

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

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

Для решения вашей бизнес цели Вы можете использовать Журнал аудита

https://academy.terrasoft.ru/documents/sales-enterprise/7-11/razdel-zhu…

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

 

Так же я передал ваше пожелание в отдел разработки для анализа доработки данной потребности в будущих версиях bpm'online

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

Действительно, информация об автоматической раздаче прав будет полезна при разработке бизнес-логики и аудите раздачи прав.

Спасибо, мы учтем это при разработке.

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

Спасибо, Александр.

При разработке мы будем учитывать широкий круг бизнес-кейсов. 

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



Подскажите пожалуйста, как импортировать права доступа к объектам, которые администрируется по записям?

Есть кейс:

30 ролей, 40+ объектов у которых включено "Администрируется по записям". 

Нужно в каждом объекте прописать:

"Кто создает" роль1 "Кому дано право" роль1

"Кто создает" роль2 "Кому дано право" роль2

"Кто создает" роль3 "Кому дано право" роль3

и т.д.

Уровень доступа у всех одинаковый.

 

Нравится

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

что-то я не до конца понимаю вопроса... Вас интересует, как автоматизировать проставление дефолтных пермишнов по записям? или как применить пермишны к уже созданным записям?

Я так думаю надо перенести права, которые раздаются по-умолчанию при создании записи. В таком случае вам в таблицу SysEntitySchemaRecordDefRight. 

Максим Цынгаев, да интересует как автоматизировать проставление дефолтных пермишнов по записям?.



Грубо говоря: Пользователи с ролью "Москва" должны видеть только записи созданные пользователями с ролью "Москва",

А пользователи с ролью "Санакт-Петербург" . должны видеть только записи созданные пользователями с ролью "Санакт-петербург"

И таких ролей у меня 30 штук, а права нужно раздать на 40+ объектов (разделов).

Как пример: Раздел "Обращения" я раздаю на него права доступа "Администрируется по записям"

И 30 раз проставляю:

Кто создает "Москва" кому дано право "Москва"

Кто создает "Санакт-Петербург" кому дано право "Санакт-Петербург"

и т.д.

Хотелось бы как-то это автоматизировать.

 

Варфоломеев Данила,большое спасибо помогли, добавить записи получилось. то что нужно

INSERT ... SELECT, думаю, будет оптимальным решением

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

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

Каким образом можно решить подобную задачу по ограничению прав доступа - если у пользователя есть права на редактирование записи (например, контрагента), то ему доступны все поля (где нет ограничений по колонкам), если есть доступ на чтение, то эти же поля доступны только для чтения.
Но если на запись нужно дать ограниченный доступ на чтение, то доступен другой набор полей (например, Название, Код и Ответственный).

В каком VIEW ограничить набор колонок и каким признаком лучше выдавать "ограниченный" набор?

Спасибо!

Нравится

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

Здравствуйте!

Что вы имеете ввиду под "ограниченным" доступом?

"Мотков Илья" написал:Что вы имеете ввиду под "ограниченным" доступом?

Приведу пример. Я как ответственный менеджер за контрагента "X" могу видеть и редактировать его карточку (и все поля в ней). А в других контрагентах (где ответственный не я) я могу видеть только 3 поля - название, код и ответственного.

Стандартным функционалом (доступом по записям и колонкам) это не решить

Уже обсуждалось месяц назад, стандартного механизма нет. Только разработкой.
Возможно, в 7.10 можно будет нащёлкать мышкой такое бизнес-правило.

"Зверев Александр" написал:стандартного механизма нет.

Но существуют же VIEW, которые фильтруют доступ по записям? Если в этих VIEW уменьшить количество колонок при определенных условиях, то можно решить этот вопрос

Владимир, ну это же тоже будет доработка.:wink:

Кроме того, не представляю, как можно ограничить во view для каждого, а не одного конкретного пользователя. Это в 3.Х доступ по записям был сделан при помощи view с фильтрацией по SYSTEM_USER, а в 7.Х все пользователи системы работают с БД через одну учётку, прописанную в ConnectionStrings. Фильтры накладываются программно где-то внутри EntitySchemaQuery.

"Зверев Александр" написал:Владимир, ну это же тоже будет доработка

Да, всё тут доработка :D

"Зверев Александр" написал:Фильтры накладываются программно где-то внутри EntitySchemaQuery

Это уже сложнее, конечно.. Но, возможно, реализуемо. По крайней мере, это критично важно.

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

"Зверев Александр" написал:Нужно всего лишь наряду с механизмами в ядре по выдаче прав на объекты, на поля, на записи и на записи по умолчанию сделать ещё один.

Думаю, что в банковских проектах такое реализовывали. Осталось найти, кто :)

Думаю, нет. В ходе проекта такое реализуют скриптами под конкретное поле, согласно ТЗ.

Реализовывали программной доработкой. При этом советуем базовый механизмы не трогать. В основном реестре оставлять видимыми только те записи, где доступ полный. И делать отдельную вью с доступом на все записи. Обычно такое делают, если хотят избежать дублей для поиска. Ну вот по нажатию на кнопку "Поиск во всей базе" - открывать отдельную вью со всеми записями, но только тремя колонками. Но такое нельзя реализовать в самом разделе "Контрагенты"

 

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

Добрый день!

По-умолчанию в Террасофте настроены права доступа на таблицу Контактов таким образом, что редактировать контакт может либо ответственный, либо админ.

У нас возникла необходимость в таблицу Контакты добавить несколько полей, НО чтобы их могли редактировать все пользователи.

Т.е. на эти новые поля права для всех, а на все остальные - по-умолчанию.

Подскажите, пожалуйста, как лучше это реализовать?

Заранее спасибо!

Нравится

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

Спасибо за Ваше обращение. Мы зарегистрировали его в Службе технической поддержки и назначили специалиста, который сможет Вас компетентно проконсультировать по данному вопросу.

Добрый день!

Для настройки прав доступа к колонкам, Вам необходимо перейти в Админитсрирование: Доступ к объектам, найти объект "Контакт", и включить для него администрирование по колонкам. После чего найти необходимую Вам колонку и добавить для нее пользователей и уровни доступа для этих пользователей, как показано на скриншоте.

Александр, спасибо за ответ, но у меня не Online, у меня нет "Доступ к объектам".

Алексей, настроить права доступа таким образом невозможно, так как иерархически доступ к объекту "Контакт" находится выше чем к полю.

Понятно, спасибо!

Я сделал следующим образом:

  • добавил еще одну таблицу, в которой хранятся те самые несколько полей, которые должны быть общими для всех, связанными с таблицей контактов по ID контакта,
  • при открытии карточки контакта идет считывание в поля (поля обычные, не data),
  • при сохранении проверяется нет ли уже записи для этого контакта, и либо Edit(), либо Append()

единственный "косяк" в том, что пришлось сделать дополнительную кнопку для сохранения этих данных, т.к. кнопка "Ок" так же завязана на права.

Можете прокомментировать такое решение?
Спасибо!

Здравствуйте, Алексей.

Костыль. Но наверное, наименее трудозатратный. Реализовывать ограничения доступа на уровне карточки и деталей без участия стандартного механизма было бы сложнее.

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