Добрый день.

Кто нибудь когда-нибудь ограничивал полномочия консультантов которые внедряют\настраивают систему? Например можно генерировать роль на основе проекта spro[_admin]. И такую роль присвоить консультанту. А sap_all убрать. Наверняка еще потребуется добавить других, технических ролей. Может кто-то пытался так сделать?

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

вы таки не поверите... но бывает и базис без sap_all...и ничего, работают

В первую очередь стоит вспомнить, что есть разные по задачам системы.
В SAP Solution Manager - всегда делали роли под конкретный проект.
В DEV - все обычно работали с SAP_ALL, обрезать права консультантам можно, но это может вызвать большие дополнительные затраты времени по решению каждого вопроса. Достаточно нормальный вариант применять zSAP_ALL - где из SAP_ALL выброшены критичные базис-полномочия.
В QAS - лучше работать всем на уровне пользовательских ролей - иначе потом сюрпризов не оберешься...

В PRD (PROD) - вообще, ни консультантов ни разработчиков не пускать!
Да и проектной группе лучше бы права крепко пообрезать в Продуктиве или после старта совсем не впускать.
(Но это уж определяется целями и задачами проектной группы).

В отношении базиса - сильно нравится схема, когда из полномочий базисников исключаются все полномочия по функциональным модулям.
Т.е., делается zzSAP_ALL, где сохраняются только базисные функции. Сам такое делал, но утверждать что удалось применить на 100% не буду.

Кода я базисничал - у меня это было само-собой разумеющимся.

А это уже звучит как анекдот.
"У базисника SAP_ALL отобрали."

murenets
шутки шутками но есть и такое.

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

философский вопрос - а зачем sap_all даже в системе разработки?

я ж говорю - ситуация реальная, и работа от этого не встает, даже времени задуматься не хватает.

при наличии выделенного админа полномочий - вполне грамотно

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

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

Наверно имеет место моя "костность мысли". То есть если не SAP_ALL то забраны базисные полномочия, в первую очередь.

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

В системе разработки консультанту хватит как сказали выше, подобие ZSAPP_ALL, оставив настройки SPRO, работу с пользователями, ролями, перенос запросов, трассировки, пакетный ввод к примеру. Можно еще по модулям роли разграничить.
В QAS тоже самое, только на просмотр. Или все пользовательские роли.
В продуктивной системе, ну как повезет. Пока проект не завершен, на просмотр частичное изменение, каких-либо данных все равно должны быть.

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