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: 

Mass addition of document type for authorization object in a role

MaheshKumar
Contributor
0 Kudos

Hi All...

I have a role ABCD in that i have a authorization object XYZ. I would like to know is there any way i can add document type ZGH1,ZGH2 to about 200 roles at one shot. or do i need to add it manually.

waiting for ur responses.

18 REPLIES 18

Former Member
0 Kudos

If you are using derived roles then update the master roles & distribute to the child roles. Budget 1 minute per master role to change & maybe 5 minutes per master to distribute the changes (could be longer or shorter depending on lots of factors).

If it is for a specific transaction/s and applies to all uses of those then you could look at updating SU24 and automate the reading into roles. Depending on your setup this could cause lots more issues if you haven't been strict around SU24 use.

If it's only single roles that you are updating then there is no alternative automation method that I would recommend. You can hack about with text files & download/upload of roles but unless you really know what you are doing then you are opening yourself up to a whole load of problems.

Ultimately at an update rate of 1 role per 30s - 1min then 200 roles can be done in anything from 1.5 to 3 hours

0 Kudos

Alex wrote:

If it's only single roles that you are updating then there is no alternative automation method that I would recommend. You can hack about with text files & download/upload of roles but unless you really know what you are doing then you are opening yourself up to a whole load of problems.

Very risky and fast

For 200 roles manual is not a big deal.

Regards,

Arpan Paik

Edited by: P Arpan on Jul 8, 2011 3:43 PM

0 Kudos

> Very risky and fast

>

> For 200 roles manual is not a big deal.

Agree on both counts!

Former Member
0 Kudos

Hi

SUPC is your friend - easier than PFCG copy/paste

Cheers

David

Former Member
0 Kudos

Hi,

Why can't you look at eCATT scripts, if you are quite sure that the new values have to be added for the same authorization object?

Regards,

Raghu

0 Kudos

> Why can't you look at eCATT scripts, if you are quite sure that the new values have to be added for the same authorization object?

I wouldn't even explore that route as cursor position in SECATT is virtually impossible and the chance the object and fields to edit are at the exact same position in every role is very small.

0 Kudos

Hi Jurjen,

I wouldn't even explore that route as cursor position in SECATT is virtually impossible and the chance the object and fields to edit are at the exact same position in every role is very small.

I agree with your point, if I am manually drilling down to a specific cursor position. But, hope this can be achieved with using the find option for the authorization object and changing it.

and ofcourse I agree with others, changing 200 roles is not a big task since it is only adding document types

The other alternative is using a bolt-on role adding the authorization object with all the document types and attaching them to the users

Regards,

Raghu

0 Kudos

Hi Raghu

The other alternative is using a bolt-on role adding the authorization object with all the document types and attaching them to the users

You're teasing us!

I've just add 'task-value' roles to my most hated list again (it fell off the bottom when I added composites late last year...

Cheers

David

0 Kudos

So, I found another way:-)

Create the dreaded 'bolt-on' role and generate it's profile but do not assign it to anyone.

Now record an ECATT script which opens one of the roles you need to change in PFCG, go into the authorization tab and from the menu choose "EDIT"->"Insert authorizations"->"From profile". Enter the profile name for your bolt-on.

0 Kudos

the downside of this is that the best documentation on why the values were added is here in this thread on SDN...

su24 should be the weapon of prefered choice, unless there is a compeling reason not to use it.

even a bolt-on symbolic parameter transaction is better and easier IMO.

cheers,

Julius

0 Kudos

> the downside of this is that the best documentation on why the values were added is here in this thread on SDN...

I disagree on that one. I am used to document authorization changes within the roles' profile. The object description per authorization (Yellow line in PFCG for each object) can be changed to any text you like (stored in AGR_1250). I f you enter your motivation in the bolt-on role it'll come along into the roles you change.

Edited by: Jurjen Heeck on Jul 8, 2011 10:17 PM

0 Kudos

LOL

sorry - that's probably txt spk nd nt alwd

The scenarios is 200 roles to update at 30-60 seconds each either via clunky old PFCG or SUPC (my preferred weapon of choice)...

Why re-design an entire authorisation concept to handle a tiny update need?

Stomps around the office and comes back to ancient DELL...

I'm all for it after all it is a Friday.

Bite the bullet - consider SU24 - update and option 3 in expert mode and happy trails...

Cheers

David

Edited by: David Berry on Jul 8, 2011 9:21 PM

edit

Trouble is - I see this every day at my client's as they have done just this and I cry quietly into my Ibis sachet coffee..

Edited by: David Berry on Jul 8, 2011 9:27 PM

0 Kudos

Yep, I also use that text description of the authorization (object) when temporarily adding something which I later want to replace again. For that it is cool and "in your face" for anyone else tampering with the role.

But still, Su24 is better because it applies to all roles using that transaction context.

Additionally, if the merge function where ever to to merge this authorization with changed text together with another one, the text will be overwritten by the standard object long text --> your documentation is gone...

Cheers,

Julius

0 Kudos

> if the merge function where ever to to merge this authorization with changed text together with another one, the text will be overwritten by the standard object long text --> your documentation is gone...

Point taken but do merges overwrite manually inserted objects as well?

0 Kudos

Not in "expert mode". But there is an option within the authorizations tab to manually merge. It is usefull, but if you rely on this documentation then you cannot use it.

SU24 should take preference, but I have also used your approach for quick fixes until it settles down -> then maintain SU24.

Cheers,

Julius

0 Kudos

Hi Jurgen

Create the dreaded 'bolt-on' role and generate it's profile but do not assign it to anyone.

Now record an ECATT script which opens one of the roles you need to change in PFCG, go into the authorization tab and from the menu choose "EDIT"->"Insert authorizations"->"From profile". Enter the profile name for your bolt-on.

Thought I'd just add an extra post as I've read my previous post to you and it does come across as a little (or lot) mocking which it wasn't intended to be.

The LOL was for finding an interesting way of getting a script to create an additional authorisation object via "insert from" and not at you trying to use "bolt-ons".

Sorry if any offence was caused.

Regards

David

0 Kudos

No offence taken. I imagined the LOL was for the script solution which I did try out and post just for the fun. I will keep it in mind for emergency fixes in the future though.

Former Member
0 Kudos

Plan 😧 Open a Role and go to f_bkpf_bla and hit the where used list to find where it is coming from (su24). If you can isolate a tcode to add these values to without disturbing other roles then add it to su24 and then useing SUPC you only need to hit the Read old and merge with new button once each time (if the roles are "intact"...).

Then mass generate and voila.

There are a few pre-requisites though regarding how you built and maintained the roles in the first place

I can very strongly recommend avoiding bolt-on roles. They are a terrible pest in the Medium to longrun and you will end up having to reimplement everying sooner or later.

Cheers,

Julius