ax2012: Как создать правильную роль для разработчика?

[mazzy]

преамбула:
- в ax2012 перехерачили систему прав доступа по сравнению с прошлыми версиями
- выключение лицензионных и конфигурационных ключей в ax2012 может привести к нежелательным побочным эффектам (на view, на унаследованных таблицах, на временных)
- с другой стороны, разработчикам обычно ставят роль "системный администратор". Эта роль открывает всё-всё-всё, включая неиспользуемый функционал.

вопрос:
- есть ли роль разработчика, а если такой роли нет, то как создать правильную роль для разработчика?

правильная роль для разработчика должна:
- не содержать стандартную роль "системный администратор"
- открывать доступ к средствам и инструментам разработки
- открывать доступ ко всем системным настройкам типа database log, aif, dmf, cleanup и т.п.
- но не открывать доступ в пользовательском интерфейсе к неиспользуемым модулям (whs, payroll, retail, recruiter и т.п. по выбору), чтобы тупо не мешалось в интерфейсе

другими словами:
какова методика создания роли для разработчика?

[EVGL]

Разработчика в разработческой системе или разработчика в тестовой системе или разработчика в продуктивной системе?

[mazzy]

Цитата:

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

... или ... или ...?

зачем "или"?
расскажите о всех. И расскажите о разнице между ними.

[EVGL]

Цитата:

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

зачем "или"?
расскажите о всех. И расскажите о разнице между ними.

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

В продуктивной системе мой текущий клиент пришел к тому, что системный администратор остался у одного-двух человек, а "внесистемные администраторы" получили:
[- открывать доступ к средствам и инструментам разработки] в D365 неактуально
- доступ ко всем системным настройкам типа database log, aif, dmf, cleanup и т.п. (хотя в D365 неактуально)
- неиспользуемый функционал, поскольку настройщикам было банально лень (притом whs - вообще наиболее активно используемый функционал, retail тоже частями типа иерархий категорий)

[mazzy]

я повторю свой вопрос:

ax2012: Как создать правильную роль для разработчика?

[EVGL]

Ок, понял. Создать новую роль как суперпозицию всех возможных ролей пользователей. Назначить ее разработчику.
P.S. В D365 это делается опосредованно в один момент (как роль из ролей). В Ax2012, похоже, все Duties в явном виде включать придется.

[mazzy]

Цитата:

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

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

какая именно роль дает доступ к средствам и инструментам разработки?

[oip]

Цитата:

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

- не содержать стандартную роль "системный администратор"
- открывать доступ к средствам и инструментам разработки

Никак.

[sukhanchik]

Цитата:

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

преамбула:
- в ax2012 перехерачили систему прав доступа по сравнению с прошлыми версиями
- выключение лицензионных и конфигурационных ключей в ax2012 может привести к нежелательным побочным эффектам (на view, на унаследованных таблицах, на временных)
- с другой стороны, разработчикам обычно ставят роль "системный администратор". Эта роль открывает всё-всё-всё, включая неиспользуемый функционал.

вопрос:
- есть ли роль разработчика, а если такой роли нет, то как создать правильную роль для разработчика?

правильная роль для разработчика должна:
- не содержать стандартную роль "системный администратор"
- открывать доступ к средствам и инструментам разработки
- открывать доступ ко всем системным настройкам типа database log, aif, dmf, cleanup и т.п.
- но не открывать доступ в пользовательском интерфейсе к неиспользуемым модулям (whs, payroll, retail, recruiter и т.п. по выбору), чтобы тупо не мешалось в интерфейсе

другими словами:
какова методика создания роли для разработчика?

Систему прав доступа действительно переделали, но вместе с ней переделали и идеологию выдачи прав доступа разработчикам.
Предполагается, что:
1. Разработчик имеет права везде и на всё. Это логично и правильно, ибо он всё равно сможет при желании докопаться до всего, что якобы закрыто. Такой доступ обеспечивает роль "Системный администратор", поэтому её назначают всем разработчикам.
2. Выключение конфигурационных ключей теоретически не должно ничему помешать, т.к. поля и таблицы из БД не удаляются (но удаляются данные). На практике предполагается, что у разработчика есть индивидуальная виртуальная машина, на которой включено всё, поэтому если следовать "заветам от Microsoft", то разработчик должен видеть все неиспользуемые модули.
3. Роли разработчика нет и создать её нельзя. Разработчику нужно давать роль Системный администратор (см п.1)
4. Разработчик на то и разработчик, чтобы работать в интерфейсе разработчика, следовательно наличие у него прав в дополнительные модули не должно его смущать.

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

В контексте дальнейшего развития (D365FO и Visual Studio) такая концепция вполне себя оправдывает (на мой взгляд)

[EVGL]

Цитата:

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

Никак.

Точно, беру свои советы обратно.
А в D365 вопрос сам собой отпадает
.

Цитата:

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

В контексте дальнейшего развития (D365FO и Visual Studio) такая концепция вполне себя оправдывает (на мой взгляд).

Да нет, в D365FO можно полностю разделить эти два вопроса. Права - правами, а разработка - разработкой.

[oip]

А еще разработчику в некоторых случаях приходится давать роль Security Administrator, так как без нее пользователь не будет, например, админом Management Reporter.

[Raven Melancholic]

Цитата:

но не открывать доступ в пользовательском интерфейсе к неиспользуемым модулям (whs, payroll, retail, recruiter и т.п. по выбору), чтобы тупо не мешалось в интерфейсе

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

[sukhanchik]

Цитата:

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

Да нет, в D365FO можно полностю разделить эти два вопроса. Права - правами, а разработка - разработкой.

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

[Raven Melancholic]

Цитата:

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

2. Выключение конфигурационных ключей теоретически не должно ничему помешать, т.к. поля и таблицы из БД не удаляются (но удаляются данные)...

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

[Logger]

Цитата:

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

3. Роли разработчика нет и создать её нельзя. Разработчику нужно давать роль Системный администратор (см п.1)
...
Роль, открывающая доступ к средствам разработки всего одна - Системный администратор, а она сразу по сути отключает какие-либо ограничения по функционалу и данным для пользователя.

Интересно, а зачем наряду с методом
Global::isSystemAdministrator
есть метод
Global::isDeveloper

Эти методы, соответственно, вызывают методы ядра
\System Documentation\Classes\SecurityRights\isSystemAdministrator
\System Documentation\Classes\SecurityRights\isDeveloper

Это эквивалентные вещи ?

[sukhanchik]

Цитата:

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

Интересно, а зачем наряду с методом
Global::isSystemAdministrator
есть метод
Global::isDeveloper

Эти методы, соответственно, вызывают методы ядра
\System Documentation\Classes\SecurityRights\isSystemAdministrator
\System Documentation\Classes\SecurityRights\isDeveloper

Это эквивалентные вещи ?

Видел эти методы. Сам не понял, чем они отличаются. Я всегда использовал Global::isSystemAdministrator
Здесь https://community.dynamics.com/ax/f/...-rights/274292 говорят о том, что нельзя дать права разработчика без прав системного администратора

[SRF]

Цитата:

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

Это эквивалентные вещи ?

Скорее всего зависит от лицензии, если на разработку её нет, то разные, а вот если есть, то одинаковые.

[sukhanchik]

А разве можно в 2012 не иметь лицензии на разработку, имея роль системного администратора?

[EVGL]

Цитата:

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

А разве можно в 2012 не иметь лицензии на разработку, имея роль системного администратора?

Можно, если поотключать лицензионные ключи.

[Pokersky09]

Больше всего удивило наличие проверки на Global::isDeveloper в D365 в объектах SysTableBrowser. Мне кажется isDeveloper стало архаизмом в рамках D365.

По поводу разделения на D365 (не в тему, но тем не менее) На дев боксах даже если не дать доступа к базе данных, полученной методом копирования с рабочей, можно всегда воспользоваться AOSService\PackagesLocalDirectory\Bin\AdminUserProvisioning.exe и указанная тобою почта получает безусловный полный админ доступ к юзер интерфейсу.