Добрый день

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

Нравится

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

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

В разделе есть поле IsExpertRecBadTurnoverNotify (логическое), которое должно быть доступно на чтение всем пользователям, и пользователям роли "ЗГД по маркетингу" на запись. Делаю настройку по инструкции:

Роль "ЗГД по маркетингу" организационная, впрочем, с функциональной ролью все так же.

Если я пытаюсь затем отредактировать это поле в странице раздела, система сообщает "Недостаточно прав для изменения значения колонки "IsExpertRecBadTurnoverNotify " объекта "Арендатор"".

То же сообщение отображается, если убрать строку All Employees, или обе строки из списка прав на колонку. Но если просто отключить "Использовать доступ по колонкам", система разрешает изменение данных.

В чем проблема, почему не работает доступ по колонкам?

Нравится

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

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

Юрий, попробуйте сначала просто выполнить действие «Актуализировать роли» в разделе «Пользователи».

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

Добрый день!

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

Спасибо!

Нравится

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

Здравствуйте! Через БП, воспользовавшись элементом раздать права. Создаёте БП со стартовым сигналом по объекту после добавления записи и раздаёт нужные права, это для новых пользователей, а для существующих через БП с простым стартом, используйте тот же элемент раздать права доступа и задаёте в нем объект о фильтры.

Здравствуйте! Через БП, воспользовавшись элементом раздать права. Создаёте БП со стартовым сигналом по объекту после добавления записи и раздаёт нужные права, это для новых пользователей, а для существующих через БП с простым стартом, используйте тот же элемент раздать права доступа и задаёте в нем объект о фильтры.

Нигрескул Алексей,

 

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

Потом еще как вариант - плокировка страницы

 

https://academy.terrasoft.ru/documents/technic-sdk/7-16/kak-polnostyu-z…

https://academy.terrasoft.ua/documents/technic-sdk/7-16/mehanizm-blokir…

 

Использую и вариант с БП и с блокировкой страницы, но если нужна более гарантирования возможность блокировки то второй вариант

Александр Тыра,

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

Александр Тыра пишет:
но есть минус у такого варианта, так как есть будет потом изменение правил доступа по умолчанию и произведена актуализация данных, то все доступы измененные бизнес-процессам будут перетерты правами доступа по умолчанию.

Насколько понимаю, нет, не перетрут. Пишут:

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

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

 

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

Александр Тыра пишет:
но есть минус у такого варианта, так как есть будет потом изменение правил доступа по умолчанию и произведена актуализация данных, то все доступы измененные бизнес-процессам будут перетерты правами доступа по умолчанию.

Мы просто запрещаем пользователям менять права вручную. И автоматизируем распределение прав полностью. 

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

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

 

Не могу найти информацию о том, как настроить права доступа на вкладки "Обращение". 

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

Нравится

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

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

 

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

 

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

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

Зачастую не требуется настолько секьюрного подхода.

Проблема в перегруженности интерфейса пользователя, поэтому хочется убрать лишние элементы, чтобы определённым исполнителям облегчить работу. 

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

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

При попытке изменить запись в детали с редактируемым реестром возникает ошибка

https://yadi.sk/d/5HXBicLNQI3h5Q

Роли пользователя:

https://yadi.sk/d/rjuN-gR2MMK3qA

Права настроены следующим образом:

https://yadi.sk/d/SFqa8x2djEVUTA

Причем при попытке изменить в консоле видно следующее:

https://yadi.sk/d/eYJZ5dd1Fb_Inw

т.е. как я понимаю, система считает изменяемую запись новой и не дает изменить так как нет прав на добавление. Если в консоле изменять флаг isNew на false, то запись изменяется нормально.

З.Ы. Причем записи получается редактировать через страницу редактирования, значит проблема в редактируемом реестре.

Собственно вопрос: это баг или я не верно настраиваю права?

 

Нравится

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

У вас не выдано пользователям прав создавать записи в этом разделе
http://prntscr.com/qc9uae

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

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

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

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

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

Добрый день!
Установлен bpm'online service enterprise v7.8. После обновления SQL Server 2014 до SP2 возникла проблема:
При редактировании записей пользователем supervisor выходит ошибка, например Недостаточно прав для изменения записи в объекте "Сервисные договоры".

Нравится

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

Добрый день, Ольга.

Данная ошибка говорит о том, что у пользователю не выданы лицензии. Рекомендуем проверить наличие лицензий у пользователей, в частности у Supervisor.

Если приведенное решение не исправит проблему, рекомендуем обратиться в Техническую поддержку.

Распределение прав по разделам проверили, все на месте, во вложении скрин конкретно раздела "Сервисный договор"

Ольга, наличие лицензий необходимо проверить в пункте меню Управление лицензиями пользователей (см. скрин). В менеджере лицензий необходимо проверить выданы ли лицензии необходимым пользователям, в вашем случае лицензия service enterprise.
Если все лицензии выданы корректно, но прав на создание записей в разделах нет, обратитесь в Техническую поддержку для более детального анализа проблемы.

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

Здравствуйте, Владимир!

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

Приятной работы!

Сюда же. Предлагаю делать недоступной кнопки Copy, Delete в реестре и в деталях, если у пользователя на это нет прав. А то слишком много кликов нужно сделать, чтобы понять, что не можешь это сделать

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

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

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

Добрый день!
Есть следующая задача: необходимо во время редактирования записи пользователем, не давать другим пользователем редактировать эту же запись или ее детали. Причем этот функционал должен быть универсальным, т.е. должна быть возможность включать его для любых разделов.
Есть идеи как это можно реализовать?
Версия 7.7.0.2107

Нравится

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

Иван, добрый день.
Функционал можно реализовать при помощи раздачи прав на пользователя/группу пользователей при изменении ответственного/группы ответственных в записи, используя элемент бизнес-процесса "Изменение прав доступа", т.е.:
1) Ловим сигнал изменения поля "Ответственный" в записи интересующего нас объекта;
2) Читаем данные о пользователе/группе пользователей в измененной записи;
3) Элементом "Изменение прав":
a. Удаляем все установленные права в измененной записи;
b. Добавляем права пользователю/группе пользователей, которые выбраны в поле "Ответственный"
Что-то вроде этого должно получиться. Если необходимы подробности для настройки элементов БП, то могу поделиться.

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

Иван,

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

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

Добрый день!
Подскажите пожалуйста, как сделать доступ на детали таким же как и на родительские записи?
Права раздаются на каждую род. запись процессом.
В тройке для этого были группы, а в нет.
BPM 7.6

Нравится

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

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

"Александр Зубков" написал:

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

Создал отдельную тему, но здесь тоже спрошу - как скопировать права из родительской записи скопировать в объект детали?

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

После включения администрирования по записям, в системе появится объект SysDetailObjectNameRights.
Права на записи раздела хранятся в таблице SysSectionObjectNameRights.

Задача: при изменении записи в разделе перенести права на записи детали.

Решение:
1) Определите Id записей деталей:

select Id from SysDetailObjectName where SectionObjectNameId = 'Id измененной записи'

2) Удалите права на эти записи:

delete from SysDetailObjectNameRights
where RecordId in
(select Id from SysDetailObjectName where SectionObjectNameId = 'Id измененной записи')

3) Теперь Вам необходимо скопировать записи из таблицы SysSectionObjectNameRights в таблицу SysDetailObjectNameRights, изменив RecordId на Id записи детали.

"Демьяник Алексей" написал:После включения администрирования по записям, в системе появится объект SysDetailObjectNameRights.
Права на записи раздела хранятся в таблице SysSectionObjectNameRights.

А кроме того в системе есть таблицы SysAccountRight и SysAccountAddressRight. Их не трогать?

SysAccountRight - таблица, которая хранит права на записи в объекте Account (Контрагент).
SysAccountAddressRight - таблица, которая хранит права на записи в объекте AccountAddress (Адреса контрагента).

При раздаче прав необходимо переносить права с SysAccountRight в SysAccountAddressRight.

ЗЫ. Прошу прощения - в предыдущем посте указал некорректное название таблиц.

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

Здравствуйте , есть несколько объектов Entity (родитель Базовый Объект) в которых есть каскадное \ связанное обновление реализованное на событиях. Скажите можно ли инициализировать изменения в одном из них, так чтобы для низ лежащих не проверялись права для того кто инициировал изменение в родителе.

Или вообще инициировать изменение или сохранение объекта Entity из под другого логина например?.

Права на объекты настроены на уровне записей.

Предметно:

Есть лист согласования который согласует заявление на отпуск, в котором должны поставить визы руководители и отдел кадров. У заявление на отпуск в детали есть записи указанных дней отпуска (Персональные дни), для каждого сотрудника (Контакт). В этих днях, есть кол-во использованных дней, которое по закрытие заявления рассчитываются. Права на изменение и добавление есть у отдела кадров, у сотрудника только на чтение, для того чтобы формировать заявление. Если лист согласование завизирван всеми участниками успешно то меняется заявление (изменяет состояние), и далее заявление на уровне объект (Entity) меняет те дни которые указанны в детали. И получается: чтобы всё прошло успешно - необходимо выдавать права на изменение на всё это хозяйство - всем кто должен подписать отпуск. Что не есть хорошо.

пример изменения по событие в entity

if (daysCount == daysUsed  &&  (daysUsed > 0)) {
   Entity.SetColumnValue("FreeDayStatusId", Terrasoft.Configuration.FreeDayStatusConst.used);
}

Я понимаю можно было написать update, или сделать на уровне SQL Server триггером, в первом случае придется воротить много одинаковых update со всех мест которые меняют объекты, во втором нагрузка на БД а не на IIS и условия изменения в данных не позволяют использовать триггер бд.

Нравится

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

Если вместо UserConnection использовать UserConnection.AppConnection.SystemUserConnection, то права будут игнорироваться.

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