Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Restrict RZ20 transaction to DISPLAY ONLY

Former Member
0 Kudos

Hello,

I am trying to create two roles for t-code RZ20 "CCMS monitor".

One is full authorization for our Basis Team, and the other is a "display only" role for our Operations staff to verify alerts. I have looked into editing authorization object S_RZL_ADM which has activities

01, and 03. Even when restricted to only activity 03 the user can go into RZ20 and turn on maintenance, create and make changes to objects and values such as alert threshholds.

Is there any other configuration that needs to be done in the RZ20 transaction or it's authorization objects?

Any help would be greatly appreciated...

Thanks!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

I have noticed a number of places in the system where S_RZL_ADM actvt '03' is checked for authority of change mode in "basis" related areas. Often, these checks are made after the user must have been able to proceed so far (passing other checks) that the system is only checking that the user has something to do with basis area work, and not necessarily that they should be able to create (actvt '01') external programs. Such a strong authority-check would open other unintended problems.

My recommendation:

- Check to see whether there are other auth objects checked (or somtimes customizing options) to control display options.

- Accept the fact that this transaction is a change transaction if the user is able to use it (and be more carefull with '03'...).

- Look around for another transaction which might be the display version.

- Consider a variant transaction, but these are not always water-tight.

- Grant access to the alerts themselves by sending them via mail to the "display only" users.

I also remember having read somewhere that RZ20 based CCMS has been replaced, so there might be newer functionality for this. For some reason SSAA rings a bell. If I find the infos again or remember what it was, then I will share it.

Cheers,

Julius

3 REPLIES 3

Former Member
0 Kudos

I have noticed a number of places in the system where S_RZL_ADM actvt '03' is checked for authority of change mode in "basis" related areas. Often, these checks are made after the user must have been able to proceed so far (passing other checks) that the system is only checking that the user has something to do with basis area work, and not necessarily that they should be able to create (actvt '01') external programs. Such a strong authority-check would open other unintended problems.

My recommendation:

- Check to see whether there are other auth objects checked (or somtimes customizing options) to control display options.

- Accept the fact that this transaction is a change transaction if the user is able to use it (and be more carefull with '03'...).

- Look around for another transaction which might be the display version.

- Consider a variant transaction, but these are not always water-tight.

- Grant access to the alerts themselves by sending them via mail to the "display only" users.

I also remember having read somewhere that RZ20 based CCMS has been replaced, so there might be newer functionality for this. For some reason SSAA rings a bell. If I find the infos again or remember what it was, then I will share it.

Cheers,

Julius

0 Kudos

Hi Julius,

I had looked into dependencies and other objects. Good idea though!

After reviewing what you brought up, and looking into the base roles used for central monitoring it does appear that this transaction was not meant to be setup for "display only".

I'm going to explore the idea of changing the business process rather than altering the auth_objects or attempting to create a variant.

Thanks for all of your help!!!

0 Kudos

I like questions like this - not just tracing and finding the auth checks with what appears to be a correct description of a field value, but understanding what the options are and why the choice of a certain check was made...

If I bump into something (or a bug I will let you know.

Cheers,

Julius