Добрый день, коллеги!

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

При этом права на изменение СПП-элементов должны быть и у тех, и у других.

Какие могут быть варианты решения проблемы?

Собственная идея на тему "как быть":

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

2. Одновременно сделать проверку: что статус "блокировано для контировки" может быть только у СПП-элемента, имеющего пользовательский статус "N".

Но это так, мысли в слух. Может быть есть более правильное и простое решение?

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

Допустим такого объекта нет, тогда я бы не стал заморачиваться на польз.статусы. Имхо, в данном контексте, лишние движения.
Мне кажется в этом случае более предпочтителен вариант с проверкой полномочий в экзите:

1. Создаем объект полномочий, в который будут включены, как минимум, поля Пользователь и СистСтатус(если речь идет о блокировке, то можно прям взять обозначения соотв.системных статусов).
2. Присваиваем нужным пользователям соответствующие полномочия.
3. В экзите, например в расширении CNEX0002 / EXIT_SAPLCNAU_002 проверяем пользователя на наличие полномочий по изменению сист.статуса. Нет полномочий - блокируем объект и возвращаем соответствующее сообщение.

т.е. юзеру нет необходимости ставить/снимать соответствующие пользовательские статусы.

добрый день

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

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

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

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

Добрый день!

Искать пробовала... Но наверно не так искала...

Так что простите, что отрываю от важных дел и БОЛЬШОЕ СПАСИБО, что ответили..

Ну а если еще ссылку на пост кините, то буду Вам очень обязана.

Пользовательские статусы мы не ведем. С разработчиками тоже напряженка )))

Так что, "что воля, что неволя"...

Нашла ))))

http://sapboard.ru/forum/viewtopic.php ... ht=#273531

(правда по Вам как по пользователю, уважаемый GREED )

Еще раз большое спасибо за ответы )))