Модуль "Событийные права"

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

После видео стало непонятно зачем :)
Если отдел продаж услуг не видел этого клиента до момента продажи, то событийные права не помогут

Можно привести пример?

Я не совсем понял ситуацию... Попробую на примере, есть вот такая постановка:
- есть группы пользователей "Отдел продаж" и "Отдел производства". Первая группа имеет права по умолчанию на чтение в разделе Контрагенты (и соответственно видит всех контрагентов). Вторая группа по умолчанию контрагентов не видит;
- новую продажу регистрируют пользователи Отдела продаж, указывая клиента;
- при переводе Продажи в состояние "В работе" необходимо выдать права на чтение Продажи и на чтение записи о Клиенте группе "Отдел производства";
- при переводе "Продажи" в состояние "Выполнено" необходимо отобрать права у "Отдел производства" как на продажу, так и на клиента.
.
Такой сценарий реализуем в рамках модуля. Можем рассмотреть другой пример, если интересно :)
--------------------------------------------
Лабитек
Центр разработки приложений

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

Часть работы выполняет процедура на сервере (с правами владельца базы).
--------------------------------------------
Лабитек
Центр разработки приложений

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

Собственно секрета нет, так как нет "дыры" в безопасности :).
Коротко схема выглядит так:
- по правилам, которые вводит администратор Террасофт, к таблице создается триггер, содержащий логику назначения прав в зависимости от значения полей записи (я ошибочно написал, что используется хранимая процедура);
- так как пользователь может запустить эту логику, только сохраняя запись, и при этом сработают только правила, определенные администратором, то пользователь не может намеренно "навредить" в базе.
.
Кстати, я погорячился, написав ранее, что данный модуль может работать только с MSSQL 2005 и выше, или Oracle. Сейчас нет ограничения на используемую СУБД.

--------------------------------------------
Лабитек
Центр разработки приложений

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

Вы не думали над реализацией такой функциональности, как раздача прав доступа на связанные объекты, где связь идет один ко многим (например, раздавать доступ на все счета по продаже при определенных изменениях продажи)?

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

"Виталий Гдуля" написал:Вы не думали над реализацией такой функциональности, как раздача прав доступа на связанные объекты, где связь идет один ко многим (например, раздавать доступ на все счета по продаже при определенных изменениях продажи)?

Да, такую функциональность мы реализуем в следующих версиях - она прямо напрашивается :)

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

Похожую функциональность сейчас выполняет действие модуля "Установить права по умолчанию" - AdminUnitID пользователя определяется по полю, которое указано в действии, ему даются права, указанные флажками в действии, и плюс создаются права по умолчанию. Если я правильно понял Вашу задачу, надо убрать последнюю часть (права по умолчанию). Я думаю, мы реализуем в ближайшее время (как новый тип действия, конечно).
--------------------------------------------
Лабитек
Центр разработки приложений

Валерий, появился еще один вопрос. При генерации триггеров с условиями, аналогичными указанным в правиле, учитываете ли вы сложные фильтры для работы с датами, такие как "Дата" = "Сегодня" или "Дата" = "Текущая неделя"?

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

Вы правы, ситуаций именно для событийной раздачи прав не было. Часто встречаются ситуации, когда нужно массово отнять/раздать права доступа при наступлении определенной даты. Например, через неделю после завершения работы закрывать к ней доступ, кроме чтения. Но это уже задача для другого модуля.

Расширили возможности модуля в плане работы со связанными записями, а также добавили новые виды действий.
http://community.terrasoft.ua/catalog/4879

Добрый день! Этот модуль уже доступен на Terrasoft XRM Bank?

Модуль доступен под все версии Террасофт, но только при использовании СУБД MSSQL

Спасибо, но у нас Oracle

"Валерий Андрусик" написал:Модуль доступен под все версии Террасофт, но только при использовании СУБД MSSQL

Я так понимаю, под Firebird тоже модуля нет?
Озадачился тем, что под Firebird не находится аналога 'EXECUTE AS User' из SQL2005+ и не удается красиво обойти те самые ограничения прав простых пользователей через ХП

Нет, пока только под MSSQL