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: 

How to allow users to enable/disable checkbox on the basis of authorization?

former_member197578
Participant
0 Kudos

Hi,

I have a requirement wherein I do not want my users to be able to enable or disable checkbox "TEST RUN"present in standard t-code MRRL. So basically, test run will always remain checked for them and they willnot be able to change it's status.

How can this be achieved by creating authorization object?Can you please guide me how to do that and then how to use that authority object in my code.

Regards,

Chetna .

1 ACCEPTED SOLUTION

Private_Member_25738
Participant
0 Kudos

Hi Chetna,

Apparently this authorization is not a standard requirement.

Maybe I will try the following:

  • Create a non standard authorization object in transaction SU21, with for example Activity (ACTVT) 01.

  • When you have the authorization object created, with a developer mate, you need to check the corresponding user-exit/enhancement for the MRRL transaction.

  • When you have identified the user-exit, enhancement, the developer need to add an authority-check (checking your authority object, field and value).

  • The authority-check will check if the user has the authoriy object, field and value, if is yes, the exit will allow update the field "Test Run", if the user dont has it, the program dont allow update "Test Run" field.


  • Finnally, you will need to assign the authority object into the corresponding roles according the users that need update the field "Test Run" field.

I hope that it can to solve your doubt.

Please let me know with anything.

Best regards.

15 REPLIES 15

Former Member
0 Kudos

Hi chetna,

I don't think that you do this by adding an authorization object. as you can't /shouldn't modify standard code.

However, you might want to rebuilt the selection screen and use a wrapper for the standard transaction.

Then you can add a custom-authorization object to the standard transaction and your new one.

You can slo define 3 activities, one for full access one for access on the wrapper with full control and one that does not allow to uncheck the box.

just my 2 cents, you have to try if it is even possible for you to wrap the standard transaction into a custom one.

Regards

Markus

Private_Member_25738
Participant
0 Kudos

Hi Chetna,

Apparently this authorization is not a standard requirement.

Maybe I will try the following:

  • Create a non standard authorization object in transaction SU21, with for example Activity (ACTVT) 01.

  • When you have the authorization object created, with a developer mate, you need to check the corresponding user-exit/enhancement for the MRRL transaction.

  • When you have identified the user-exit, enhancement, the developer need to add an authority-check (checking your authority object, field and value).

  • The authority-check will check if the user has the authoriy object, field and value, if is yes, the exit will allow update the field "Test Run", if the user dont has it, the program dont allow update "Test Run" field.


  • Finnally, you will need to assign the authority object into the corresponding roles according the users that need update the field "Test Run" field.

I hope that it can to solve your doubt.

Please let me know with anything.

Best regards.

0 Kudos

Hi Alejandro,

Thanks for your detailed response.

Can you please tell guide me as to what all "Permitted Activities" must be selected for this authority object for Check Box Test Run ?

I did consult  few people and according to them CREATE and DISPLAY will do. As i am not much aware of authorization object area kindly explain a bit.

Thanks and Regards,

Chetna D

0 Kudos

Hi Chetna,

It depends that you want to do with the validation.

- If you want allow/not allow to update the field "Test Run", really you only need to check the authorization object (if the user has the authorization object = allow update the field, if the user dont has the authorization object = not allow to update the field. For these, the value that will check is not important, for these you can use some activity value (for example 01).

- If you want that the field "Test Run" are checked/unchecked according the autrhority object. The activities 01 and 03 can to be good. User has the authorization object and Activity 01 = Test Run field not checked, if the user has the authotation object with activity 03 = Test Run field checked.

I hope that it can tobe helpfull according with my opinion.
Please let me know with something.
Best regards.

0 Kudos

Hi,

What you mean by activities 01 and 03. These values need to be defined while creating authority object ?

Let say i have created authority object zsd_trun with permitted activities create and display. Now, i call it like this in my program:

AUTHORITY-CHECK OBJECT 'ZSD_TRUN'

              ID 'ACTVT' FIELD '03'.


So what is this 03 here? Where isit defined?


Regards,

Chetna D

Former Member
0 Kudos

Hi,

There are lot of Enhancement spot is available in this tcode. May be at selection screen or start of selection check the user has authorization (based on may be company code?) if no authorization then check the test run is unchecked then throw error message.

Auth object you can use existing or create new one.

Regards,

Jelena
Active Contributor
0 Kudos

Since the requirement is simple, why not just use a good old approach with a variant transaction (SHD0)? Tons of posts on SCN on this.

0 Kudos

Hi,

Have never used SHD0 process, will surely explore it more. Would be grateful if you can guide me a little more as in how it can be used to solve my problem.

Regards,

matt
Active Contributor
0 Kudos

Variant transactions allow you to create a Z transaction that is the same as a standard transaction, except with screen modifications. In your case - making one of the fields display only. In my view, this is the absolute best and correct way to do it.

  • No custom authorisation object required
  • No enhancements required
  • SAP suggested and supported technique
  • Simple, quick and easy.

You assign a role containing the Z transaction to the users only allowed to run in test the Z transaction. To the others a role containing the normal MRRL.

For further details please search - it's all well documented and there are several wiki articles, blogs and documents.

0 Kudos

Hi,

Yes I did explore Variant transactions and found it fairly simple to use. Only thing is we want to make changes in same t-code. So that's the reason i was more keen on knowing authority objects and how they can be used.

I am still open to any further suggestions you want to give. Thank you for responding.

Regards,

Chetna D

Sandra_Rossi
Active Contributor
0 Kudos

Instead of using authorization objects, you may also create variant groups in SHD0 so that the transaction variant is used only for a group of users. The drawback is that it's like maintaining authorizations at two places. Consider it more like a customizing.

matt
Active Contributor
0 Kudos

There is no business reason that I can think of why you must use the same t-code.

Users get roles. The roles decide what transactions they see and what they have access to. There is no reason whatsoever that users with access and those without shouldn't have exactly the same user experience with a Z-variant transaction.

This seems to me to be typical of the "here is my solution, make it work" posts we see here very often. In this case, in my opinion, any other solution is just wrong. Remember there is a business reason for the requirement - so long as that is met, go for the cheapest easiest solution.

former_member197578
Participant
0 Kudos

Thank you all for responding.

I will try creating custom authorization object in su21. Still need to understand how authority object can be used in  program to allow/not allow users to check/uncheck checkbox.

Your suggestions are very helpful. Please keep respondi

Regards,

Chetna D

Sandra_Rossi
Active Contributor
0 Kudos

Another solution is to create a program variant which protects the field, and you copy MRRL transaction code (of type report RMMR1MRS 1000) to ZMRRL, and define it for starting with this program variant. Users will have to start ZMRRL instead of MRRL. BUT you must make sure the program runs without issue with another transaction code.

By the way, you didn't say explicitly whether some users should also have the authorization to change the TEST checkbox? (you didn't say if the need of an authorization object is because of that).

former_member194965
Active Participant
0 Kudos

This message was moderated.