Доступ к содержимому маршрута (Route) на время его работы

[Wireless_Fidelity]

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

Представим ситуацию, в которой по маршруту (стандартный Route из Live Collaboration'а) отправляется в качестве содержимого бизнес-объект. Для того, чтобы участники маршрута при просмотре задачи видели этот объект, у них должен быть соответствующий доступ. Для каждого пользователя возможны два варианта:
1) Первоначально доступ к объекту есть в соответствии с его политикой.
2) Доступа к объекту не было, при создании (или старте) маршрута мы должны его предоставить с помощью гранта.

Начинаются неприятности. Пока маршрут активен, возникает необходимость резко ограничить доступ к объекту для всех пользователей. Меняется его политика И ОДНОВРЕМЕННО С ЭТИМ снимаются все гранты. Участники маршрута перестают видеть содержимое задачи. А хочется, чтобы они продолжали его видеть до момента завершения маршрута.

Как выйти из положения?

[Геройчиковый]

А зачем политику-то менять?
Это вообще самый крайний шаг и я бы советовал его никогда не применять.
Есть более удобный и гибкие механизмы разграничения прав, но не политику же менять полностью.
Почему бы не спрятать просто кнопку "Edit" для этого объекта в зависимоти от Роли пользователя/состояния объекта/состояния Роута и т.п.?
Или как-то по другому ограничить доступ ко объекту, но не сменяя политику.
Как говорится: жизнь, лёгка штука, а если тебе сложно, значит ты что-то делаешь не так.

[Wireless_Fidelity]

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

[Геройчиковый]

Гранты - это самый "жёсткий" механизм ограничения прав. Есть грант - можешь что-то делать, нету - не можешь.
По этому, "когда грант снимается, доступ к объекту пропадает" - это нормальное поведение и "хочется, чтобы он оставался до конца маршрутов" - никак не может быть выполненно, ибо нету если нету гранта - всё остальное уже не важно. И триггерами назначать гранты и убирать их - тоже не вариант.
Я бы посоветовал делать так: есть группы и роли, и они привязаны к состояниям в политике и как бы по умолчанию дают номральный доступ, даже с излишками.
Потом, когда что-то меняется, и мы, допустим, не хотим, чтобы объект , привязанный к роуту могли редактировать люди с ролью Designer. Тогда просто на кнопку Edit в тулбаре этого объекта вешаем параметр Access function, который будет проверять, кому показывать эту кнопку а кому нет. И, например, в состоянии "Approved" для пользователя с ролью "Designer" эта кнопка не будет доступна. Таким образом, человек как бы в принципе может редактировать объект, но механизмов для этого у него нету, и поэтому он никак его не отредактирует.
Тоже самое можно сдеать и с категориями в дереве типа и вообще со всем, что хотите.
Мы как бы только так и делаем.

[Wireless_Fidelity]

А нам как раз нужно "жесткое" ограничение. Кнопочки это хорошо, но если уж управлять доступом, то на уровне системы. Грубо говоря, чтобы даже через поиск нельзя было найти и просмотреть.
Почему Вы говорите, что давать/забирать гранты в триггерах это "не вариант"? Текущая реализация доступа у нас как раз основана на таком механизме. Может быть, в этом есть что-то плохое, с чем мы пока еще не столкнулись?

UPD
И еще один важный момент состоит в том, что Access Function настраивает доступ не к отдельным объектам, а к целому классу. Конечно, можно в методе в явном виде написать, для каких объектов должна отображаться кнопочка, задав этот список файлом, таблицей в базе и т.п., но уж очень это некрасиво и неправильно.

[Геройчиковый]

"можно в методе в явном виде написать, для каких объектов должна отображаться кнопочка, задав этот список файлом, таблицей в базе и т.п." - естественно так делать ни в коем случае нельзя. Система должна жить сама, без вмешательства, а задавая такие вот списки - мало того, что этому противоречит, так ещё и превращает поддержку системы в ужос. В общем, вы это и так знаете.
А я имел в виду не это.
Я имел в виду, что именно ограничения по классу, как вы их называете, и должны быть теми условиями, когда объект виден/редактируем/и т.п., а когда нет.
Привожу пример:
когда объект в состоянии Approved имеет незавершённый роут в котором проверяющий Иванов И.И. (начальник отдела) - тогда этот объект не должен быть виден всем людям его отдела за исключением Петрова П.П. (создатель объекта, подчинённый Иванова).
Так вот такую вещь можно решить триггерами и грантами,а можно, все эти перечисленные мною условия, с лёгкостью засунуть в Access Function, только Иванова заменяя на роль Head Department а Петрова на originator. И это будет справедливо для этого объекта, для аналогичных, а также для подобных объектов но для других отделов.
В общем я хочу сказать, что все условия видимочти/невидимочти объекта можно сформулировать применительно к классу. И нет необходимости делать это персонально для каждого объекта. Прсото надо посидеть и подумать, как поточнее эти условия выявить.
А в триггеры забить не вариант, потомучто это почти что как "в методе в явном виде написать, для каких объектов должна отображаться кнопочка, задав этот список файлом, таблицей в базе и т.п." только в другой плоскости. Да и потом этих триггеров наплодиться столько, что сами запутаетесь. И замучаетесь потом выяснять почему кто-то имеет доступ, а кто-то нет.
Используйте Роли и Группы более гибко. И уже на их основе выделяйте условия, которые применимы к классу. Чтобы вся системы автоматически всё делала.

[Wireless_Fidelity]

Полностью с Вами согласен. Для доступа к содержимому возможности Access Function должны быть достаточны.

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

Кстати говоря, есть ли какое-то функциональное отличие между группами и ролями? Сейчас мы везде используем группы.

[Геройчиковый]

Ну раз у вас так всё запутано, то вам виднее, что там лучше использовать... Я с такими серьёзностями не встречался .
По поводу групп и ролей:
Заказчик использует Роли только, группы как-то стороной обошли. При том что в целом - они выглядят как бы одинаково - и те и те просто объединяют пользователей.
В MQL Guide написано про различие групп и ролей: что ролью надо объединять именно людей имеющих равные обязанности в компании, типа Дизайнер, Проджект менеджер и т.п. А вот группа - это чисто логическое объединенние.
+ к тому, есть такая настройка в эновии ,которая позволяет автоматически создавать иерархию групп (надеюсь не ошибаюсь, что групп) в соответствии с организационной структорй предприятия (автоматически). Но её никто не использует.
Если подвести итог, то как бы Роли - более корректный подход по разделению прав. А Группы - чисто так, для объединений пользователей по принадлежности к одному отделу ну или по цвету кожи(шутка).