У кого в продуктиве используется деривация ролей. Поделитесь опытом, всё корректно отрабатывает?

все отлично! если бы не было деривации, то вообще-бы была вешалка с ролямии! очень рекомендую)

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

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

Мы тоже используем, правда не в 100% ролей, то есть есть и роли с деривацией и простые роли. нельзя сказать что это панацея от всех бед, как всегда палка о двух концах. но в принципе очень удобно, если полномочия простые и прозрачней.

Какие проблемы были при использовании. что за второй конец у палки?)))

Скрытый конец - если мастер-роль становится "моложе" потомков, то профайлы таких потомков становятся не активными и требуют регенерации.

Как это выглядит:
1. Кто-нибудь потогал мастера (даже не менял, просто пересохранил, т.е. изменилась дата последнего изменения) в DEV.

2. Понадобилось изменить одного из потомков в PROD. Ессно это делается в DEV, включается в транспорт. САП сует в этот же транспорт мастера.

3. После переноса в QA и PROD этого транспорта все потомки, за исключением измененого перестают работать.

Еще есть прекрасная возможность убить всех потомков, нажав в мастере "Adjust profiles for derived roles".

Большого плюса в использовании нет, если не пользоваться какой-нибудь автоматизацией, типа CATT.

А мне кажется, что в этом и есть плюс. Допустим, поменялся отчетик и требует дополнительных полномочий. Добавил их в родительской и вперед - все дочерние автоматически перегенерировались уже с добавленными полнмомочиями. Не надо тестировать каждую роль, т.к. все они работают аналогично родительской. Так же с тарнзакциями.
Что касается концепции в целом - у нас такой порядок, все роли для всех предприятий аналогичны, т.е. имеют одинаковый набор транзакций и объектов для их корректного выполнения, соответственно. Нечего самодеятельность разводить а-ля нам это надо, а другое не надо)))) все работем одинаково! на то и нужен САП)
еще бывают "одаренные" разаботчики, которые пишут транзакции для каждой БЕ отдельно, вместо того, чтобы нормальную проверку в программе реализовать. такие тр-ии мы обрубаем на корню. ибо нефиг))) за редким исключением
глюк - иногда в какой-нить объект в дочерней роли может затесаться поле орг.уровня со значением из родительской роли, но такое за всю мою практику было всего раза 2-3)

Это удобно, если дочерние отличаются только орг.уровнями. А если прописаны всякие типы материалов, документов и другие auth.groups, то все будет затерто значениями родителя.

Это удобно, если дочерние отличаются только орг.уровнями. А если прописаны всякие типы материалов, документов и другие auth.groups, то все будет затерто значениями родителя.

Любое поле можно сделать орг уровнем. есть специальные программы

В продолжение темы о концепции - от деривации предпочел отказаться в пользу разделения ролей на два типа - "роли с меню" и "роли с полномочиями".
У нас так же куча филиалов, и в большинстве своем роли отличаются лишь оргуровнями. Поэтому есть общие для всех филиалов роли с меню (из ОП там только s_tcode), ну а дальше разные роли с полномочиями, причем тоже 2-3 уровня (1-й - с орг уровнями, 2-й - с большинством остальных, 3-й - специфические, в основном z...)

при большом количестве различных БЕ и различных полномочиях на просмотр изменение и т.д. деревация есть оптимальным решением ... езинственное это необходимо при изменениях генерить профайлы... но это мелочи...

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

вот они, программки)
PFCG_ORGFIELD_CREATE
PFCG_ORGFIELD_DELETE
PFCG_ORGFIELD_UPGRADE
а консультатнам мы объясняем так: допустим, есть роль по Главной Книге, в ней набор транзакций, который вообще-то должны определить сами косультанты. В идеале, ими всеми должны пользоваться все предприятия, пользуются они ими или нет - их проблемы. зато везде порядок)