Вопрос

Добрый день! 

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

Рассмотрели возможные варианты:
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 && !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()

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

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

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

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

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

Добрый день!
Стоит задача реализовать универсальный функционал для всех разделов системы, который позволит поставив галочку на карточке записи ("Запретить редактирование"), оставить всем пользователям и группам, кроме нескольких, доступ только на чтение этой записи и всех деталей, относящихся к ней. При этом необходимо в гриде раздела видеть закрытые на доступ записи, т.е. поле - закрыт доступ или нет.
Подскажите пож-ста как лучше всего осуществить эту возможность!
Заранее благодарен.
XRM 3.4.0

У меня такой же вопрос

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

Мне кажется, это можно сделать в функции EnableOKButtonByRights в скрипте scr_BaseDBEditUtils.

А конкретнее? Необходимо редактировать табличку Rights таблицы раздела? Как это сделать? И будут ли права на основную табличку наследоваться таблицами деталей?

Здравствуйте, Иван!

Первое, что остается несколько неясным в Вашей постановке: Каким образом должны определяться те пользователи и группы, у которых есть доступ? Могу предположить, что Вами планируется разрешать доступ только системным администраторам.

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

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

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

Может поможет http://www.community.terrasoft.ua/blogs/4880, очень хорошая штука сам пользуюсь

Войдите или зарегистрируйтесь, чтобы комментировать

Доброе утро.
Как можно открыть права доступа для пользователя, не являющимся администратором, на бизнес-процессы других пользователей в Terrasoft XRM 3.4?

У меня такой же вопрос

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

Добрый день, Анастасия.
Для реализации задачи нужно в приложении Terrasoft Administrator открыть сервис Workflow\General\Main Grid\tbl_Workflow и включить для него Администрирование по записям.

Войдите или зарегистрируйтесь, чтобы комментировать
Публикация

В системе BPMonline после добавления нового поля в карточку, например [Контакт], большое значение имее корректное распределение прав доступа.

Если соответствующая таблица администрируется по колонкам, необходимо раздать права доступа на новосозданное поле. В противном случае при создании новой записи или редактировании существующей, система выдает сообщение об ошибке по типу "У Вас недостаточно прав на добавление/изменение записи".

Для того, чтобы корректно раздать права доступа, нужно перейти в раздел [Администрирование] ->[Доступ к объектам], далее выбрать нужную таблицу и на детали [Доступ к колонкам] раздать права доступа пользователям, как показано на прикрепленном скриншоте.

Поделиться

0 комментариев
Войдите или зарегистрируйтесь, чтобы комментировать