Цитата:
Сообщение от
mazzy
преамбула:
- в ax2012 перехерачили систему прав доступа по сравнению с прошлыми версиями
- выключение лицензионных и конфигурационных ключей в ax2012 может привести к нежелательным побочным эффектам (на view, на унаследованных таблицах, на временных)
- с другой стороны, разработчикам обычно ставят роль "системный администратор". Эта роль открывает всё-всё-всё, включая неиспользуемый функционал.
вопрос:
- есть ли роль разработчика, а если такой роли нет, то как создать правильную роль для разработчика?
правильная роль для разработчика должна:
- не содержать стандартную роль "системный администратор"
- открывать доступ к средствам и инструментам разработки
- открывать доступ ко всем системным настройкам типа database log, aif, dmf, cleanup и т.п.
- но не открывать доступ в пользовательском интерфейсе к неиспользуемым модулям (whs, payroll, retail, recruiter и т.п. по выбору), чтобы тупо не мешалось в интерфейсе
другими словами:
какова методика создания роли для разработчика?
Систему прав доступа действительно переделали, но вместе с ней переделали и идеологию выдачи прав доступа разработчикам.
Предполагается, что:
1. Разработчик имеет права везде и на всё. Это логично и правильно, ибо он всё равно сможет при желании докопаться до всего, что якобы закрыто. Такой доступ обеспечивает роль "Системный администратор", поэтому её назначают всем разработчикам.
2. Выключение конфигурационных ключей теоретически не должно ничему помешать, т.к. поля и таблицы из БД не удаляются (но удаляются данные). На практике предполагается, что у разработчика есть индивидуальная виртуальная машина, на которой включено всё, поэтому если следовать "заветам от Microsoft", то разработчик должен видеть все неиспользуемые модули.
3. Роли разработчика нет и создать её нельзя. Разработчику нужно давать роль Системный администратор (см п.1)
4. Разработчик на то и разработчик, чтобы работать в интерфейсе разработчика, следовательно наличие у него прав в дополнительные модули не должно его смущать.
Роль, открывающая доступ к средствам разработки всего одна - Системный администратор, а она сразу по сути отключает какие-либо ограничения по функционалу и данным для пользователя.
В контексте дальнейшего развития (D365FO и Visual Studio) такая концепция вполне себя оправдывает (на мой взгляд)