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: 

build a read only role - change an attribut on different objects at once

Former Member
0 Kudos

Hi,

my task is to build a read only role. Many attributes occur on different security objects with the same value (e.g. BERGR =*, or FM_AUTHACT=03, 11, 21, 30, 32, 35, 41, 52) It is very stupid and wastes a lot of time to click on each attribute. Therefore my idea is to change such attributes at once (e.g. I can do that for some attributes at organization level). Now my question: Does a possibility exist to change attributes of security objects at once (in pfcg or export the role and edit it in an external editor with search/replace)?

tnx

Steffen

1 ACCEPTED SOLUTION

Former Member
0 Kudos

I would not recommend going the Org Level route.

Field ACTVT cannot be converted, is used by many objects and (as you have noticed) it is not the only one.

The only way I know which gets close is to have a list of all the fields which have an action type of character, and maintain values for them which which you have researched.

Usefull is to have ONLY that one role assigned to your user and use it as much as possible to find the tweaks. Do not grant any access for the BEGRU type of fields. You will find them as you go along by trial an error.

A real pain will be S_TCODE and upgrades. That is why these roles don't "survive" for very long...

Cheers,

Julius

7 REPLIES 7

Former Member
0 Kudos

I would not recommend going the Org Level route.

Field ACTVT cannot be converted, is used by many objects and (as you have noticed) it is not the only one.

The only way I know which gets close is to have a list of all the fields which have an action type of character, and maintain values for them which which you have researched.

Usefull is to have ONLY that one role assigned to your user and use it as much as possible to find the tweaks. Do not grant any access for the BEGRU type of fields. You will find them as you go along by trial an error.

A real pain will be S_TCODE and upgrades. That is why these roles don't "survive" for very long...

Cheers,

Julius

0 Kudos

In addition to Julius' comments, a lot of activity related fields have different values for reading, it isn't always 03 and there are way more fields than ACTVT........

So manual work is about the only solution in my opinion. Once you've completed, be sure to backup this role, you don't want to do it a second time

Former Member
0 Kudos

Thank you for your recommendation! I'm still searching for a faster way out.

> I would not recommend going the Org Level route.

This was only an example. The Org Level shows, there exists a mechanism to set attributes with a value role wide...

>The only way I know which gets close is to have a list of all the fields which have an action type of character, and maintain values for them which which you have researched.

Did you mean search and replace? I didn't understand the complete syntax of the textfile yet, so I'm scared to change the textfile.

>Usefull is to have ONLY that one role assigned to your user and use it as much as possible to find the tweaks.

of curse

>Do not grant any access for the BEGRU type of fields. You will find them as you go along by trial an error.

???

>A real pain will be S_TCODE and upgrades. That is why these roles don't "survive" for very long...

My pain is to create such a role for one user at present

tnx

Steffen

0 Kudos

> >The only way I know which gets close is to have a list of all the fields which have an action type of character, and maintain values for them which which you have researched.

> Did you mean search and replace? I didn't understand the complete syntax of the textfile yet, so I'm scared to change the textfile.

No, I meant that there are a lot of fields which control "read" actions. You will need to "research" them, not "search and replace" them...

The textfile (download --> edit --> upload) is indeed tricky but not really a usefull option either which will help you here, because the problem is not really the number of ACTVT fields used but rather the number of "action" type of fields which additionally control an activity response from the system.

> >Do not grant any access for the BEGRU type of fields. You will find them as you go along by trial an error.

> ???

BEGRU type fields are those which relate to Athorization Groups --> Groups of programs, tables, accounts, document types, etc... They are optional and not always included in objects with another activity type of field. Typically they are used in an exclusive scenario to protect only parts of functionality or data (permit all, except those assigned to a special group) and it is hard to tell in advance whether they are used and for what.

So what I meant was don't grant it, and work on finding those which you do need by trial and error.

Such a role might well also need to be system or even client specific, and will not work on other systems or clients.

> >A real pain will be S_TCODE and upgrades. That is why these roles don't "survive" for very long...

> My pain is to create such a role for one user at present

An auditor?

If time and skills allow, then let them deliver their check list and a role to match it in advance and check it.

Another option is to use the AIS (see transaction SECR) or get ideas from it to isolate the person to a role menu. But this depends on the check-list they have and what they want to look at and whether they will recognize it in the AIS menu.

If not, then you are even better off giving them SE38 than SA38 in my opinion.

Cheers,

Julius

Former Member
0 Kudos

Hi,

I also discussed this problem with my mentor. As a newbie in this field I hate to do such a stupid work...

For auditors sap prepared different roles. Making these templates usable is fun in comparison to my actual task.

No - there exist a special customizing in our system which one consultant is looking for to learn and to understand.

So nice try - I learned my lesson

tnx for your help

Steffen

0 Kudos

> No - there exist a special customizing in our system which one consultant is looking for to learn and to understand.

Why don't you create a project in tcode SPRO_ADMIN for it, and then proceed as per [SAP Note 46546|https://service.sap.com/sap/support/notes/46546].

Where you will get stuck is if the transaction does not have the capability of being used in a display only mode, and in some cases there are "Test Mode" or "Simulate" flags which do not make changes, but request change authority none-the-less.

Others are protected only by S_PROGRAM groups - see my comment above about trial & error. Also if one does turn up, check the other programs in the group.

Cheers,

Julius

Former Member
0 Kudos

Hi,

sounds good, but this solution must wait. I am busy at present.

tnx

Steffen