права доступа в AX 2012

[macklakov]

В AX 2012 используется много паттернов и фреймворков, знание которых помогает понять зачем так реализовано и как с этим работать. И вот у меня вопрос возник, на основании какого фреймворка выстроена система управления пользовательскими правами доступа? Есть ли какая-то методика управления правами, которую аксаптовский механизм реализует? Какие документы должны сопровождать процесс.
А то уже в который раз чиню криво настоенные права и опять это довольно безсистемное допиливание напильником под лозунгом:"срочно вот это закрой для ВСЕХ ролей, а то юзеры косячат". А закрывать нетривиально, ибо ролей 150, duties на этом объекте висит по нескольку штук на роль, и снятие любой из них закрывает несколько десятков объектов которые закрывать не нужно. Приходится заменять privileges которые в эту duty входят, на самописные. В резултате чтобы один объект закрыть приходится десятки объектов в AOT менять, что может занять пол дня. А перенастроить надо сотни, если не тысячи объектов. Т.е. встает вопрос о том, чтобы перенастроить все с нуля. Но официальные методички говорят "как" но не говорят "что" надо делать.

[Ivanhoe]

Я не видел таких документов.
Из опыта: западные клиенты тащатся от слова "segregation of duties", но реализация этого в Аксе - очень условная. Плюс корявый перевод на русский, плюс ошибки прав в локализации (те же фин отчеты до сих пор не включили нормально в права).

На практике - либо берем стандартные роли и допиливаем, если допилов мало и роли плюс минус совпадают; либо делаем свои с нуля, а тут тогда очень лениво (дорого для клиента - по вкусу) делать промежуточные duty.

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

И да, не надо валить на "плохой" консалтинг

[mazzy]

Был такой документ.

Цитата:

Сообщение от macklakov

Есть ли какая-то методика управления правами, которую аксаптовский механизм реализует?

Давным-давно... )))))
когда Майкрософт меняла систему прав с конфигурационных и функциональных ключей на... то, что есть сейчас...

В майкрософте родили огромный документ с ролями и распределением функций.
Документ позиционировался как "мы знаем что делают наши пользователи"
именно с тех времен повелось называть пользователей именами, а не ролью "товаровед", "кладовщик", "бухгалетр"...
зато теперь есть есть всякие Alice, April, Charlie, Chris и прочие непонятные но очень харизматичные личности (седовласого директора Charlie я теперь узнаю по фотографии)

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

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

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

[macklakov]

Цитата:

Сообщение от mazzy

В майкрософте родили огромный документ с ролями и распределением функций.

Если ты про список стандартных ролей, то он есть здесь https://technet.microsoft.com/EN-US/.../hh527122.aspx.
Меня больше интересует процесс проектирования ролей, привелегий и прочих артефактов. И потом процесс управления этими ролями.

[macklakov]

Цитата:

Сообщение от Ivanhoe

На практике - либо берем стандартные роли и допиливаем

Этот подход не очень-то работает в самом MS. Если у вас есть индийский филиал, все пользователи с этой же ролью увидят индийские элементы. Потому что при локализации правились типовые роли, а не создавались локльные. Если бы для каждой страны создавалсь отдельная роль, то было бы просто. Даешь пользователю австралийскую роль в австралийской конторе и индийскую роль в индийской. Никакой путаницы.
ISV делает какую-то особо ценную приблуду в своей вертикалке и в своих ролях ее открывает непонятно кому. Потому что одному из клиентов так было удобно. Пользователи радостно жмут в новую кнопочку, которую они раньше не видели и тем генерят прорву левых проводок.
Примеров масса.

[mazzy]

Цитата:

Сообщение от macklakov

Если ты про список стандартных ролей, то он есть здесь https://technet.microsoft.com/EN-US/.../hh527122.aspx.

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

[Ivanhoe]

Цитата:

Сообщение от macklakov

Этот подход не очень-то работает в самом MS. Если у вас есть индийский филиал, все пользователи с этой же ролью увидят индийские элементы. Потому что при локализации правились типовые роли, а не создавались локльные. Если бы для каждой страны создавалсь отдельная роль, то было бы просто. Даешь пользователю австралийскую роль в австралийской конторе и индийскую роль в индийской. Никакой путаницы.
ISV делает какую-то особо ценную приблуду в своей вертикалке и в своих ролях ее открывает непонятно кому. Потому что одному из клиентов так было удобно. Пользователи радостно жмут в новую кнопочку, которую они раньше не видели и тем генерят прорву левых проводок.
Примеров масса.

Например, для своих решений мы создаем priv и duty, оставляя выбор - создавать новые роли или включать duty в свои.

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