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: 

Derived roles: Inactive auth in Master active again when creating Child

Former Member
0 Kudos

Dear gurus,

I need your help, as I cannot work this out myself. I have tried

Background

I am considering using derived roles for a niche reporting feature which needs to differentiate between ~190 WERKS (plants) on an ECC 6.0 ERP system 7.00 with slightly out of date SP levels.

The reporting solution gives the option to call ME21N and ME22N if authorized. This is intentional and okay (we have a BADI behind it).

Restraint

Now the bugger is that ME2xN are also used by many users (and roles), so we don't want to change the SU24 indicators but want to keep the roles intact at the same time to pull other indicators, so we always use expert mode (read old, merge new) when maintaining them.

So we set the standard authorization to inactive and manually insert the 3 objects we need for these 3 objects as an exception...

Problem

However, when creating the child roles associated to the MASTER, these standard authorizations are again active at first.

Question

We can set them to inactive each time x 190 times.. but is there a way to derive the inactive status of an authorization from the MASTER as well when the Child is created?

Other authorizations are all STANDARD or MAINTAINED (via the org. level) and these work fine.

Cheers,

Julius

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hey Julius,

What happens when you read in the auths from the master immediately after creating the derived role. Ideally it would do it automatically but I think this may fix this particular "feature" - unless I have misunderstand the issue

Cheers

Alex

9 REPLIES 9

jurjen_heeck
Active Contributor
0 Kudos

> Problem

> However, when creating the child roles associated to the MASTER, these standard authorizations are again active at first.

Not that I can be of any help at this moment, but I'd call this a bug, not a problem, and a very big one too. You've got me scared for the rest of the weekend and I wil check up on my derived roles first thing monday morning.

Former Member
0 Kudos

This is one of the issues faced by my client and we dropped the idea of using the expert mode for pfcg. But good to see this issue again. I will check and get back on this.

Rakesh

Former Member
0 Kudos

Hey Julius,

What happens when you read in the auths from the master immediately after creating the derived role. Ideally it would do it automatically but I think this may fix this particular "feature" - unless I have misunderstand the issue

Cheers

Alex

0 Kudos

> What happens when you read in the auths from the master immediately after creating the derived role. Ideally it would do it automatically but I think this may fix this particular "feature" - unless I have misunderstand the issue

Exactly that is what I do. The standard authorization in inactive in the Master, but both Change and Expert Mode pull in the authorization as an active one again.

I can go through each role and manually set them to inactive once... but I wanted to inherit this status to the Child roles as well, or perhaps at a later stage centrally set the authorization to active again (should such a requirement present itself.

I was hoping for some switch to drive the behaviour or possibly a SAP Note as our SP levels are 20 months behind here, but cannot find anything yet.

Cheers and thanks for any clues if you find something.

Our plan B is to use a download, replicate and upload approach from a template role.

Cheers,

Julius

0 Kudos

> I can go through each role and manually set them to inactive once... but I wanted to inherit this status to the Child roles as well, or perhaps at a later stage centrally set the authorization to active again (should such a requirement present itself.

I suppose that pushing the "adjust derived" from the parent would sort out the issue of mass updating when you wanted the auth to be active.

I wonder if there is an exit in the role creation routine that you could use to run the compare against the master role? I'm not aware of any switch that does this but personally would welcome it. On a previous project where we built rather a lot of roles we used to have scripts that would pick up all the new master roles and push the changes down from the master.

cheers

alex

0 Kudos

> I suppose that pushing the "adjust derived" from the parent would sort out the issue of mass updating when you wanted the auth to be active.

I'll try that from the Master role for "inactive" auths first thing tomorrow morning. I was still building the Child roles when I noticed this difference already.

Cheers,

Julius

0 Kudos

Bingo!! That works perfectly once the child roles are created ...

The gotcha here is that you first need to build the Master role as far into completeness as you can, then create the child roles and first hit the "Adjust Derived and generate" before maintaining the org levels in the child roles.

What is inconsistent here, is that opening the child role in change or expert mode reads in the manual authorizations (okay) but does not change the status of the standard one to "inactive". This is a bit inconsistent IMO as if it is going to read all the auths, then it might as well get the status as well.

So 2 things to remember when doing this.

1) First create child roles, then push the master to them, and then maintain the org.levels. Then you can use expert mode on all of them IF the master role is intact. Actually, it does not matter as long as the master is well built and you always adjust and generate.

2) If you push one or some of the org levels from the master to the child roles, then it does populate this field which is to be the same for all child roles (in our case Purchasing Organization). However, you can only do this once as the children will have local org.levels afterwards and you cannot overwrite them from the master anymore. So get it right first time...

Thanks all for the help.

Julius

@ Jurjen: Hope you didn't stress too much over the weekend.

@ Rakesh: You can still use the expert mode, as long as you have also done so correctly in the master role. My guess is that you deleted the standard auths in the master (bas idea) as opposed to setting them inactive (okay idea).

0 Kudos

> What is inconsistent here, is that opening the child role in change or expert mode reads in the manual authorizations (okay) but does not change the status of the standard one to "inactive". This is a bit inconsistent IMO as if it is going to read all the auths, then it might as well get the status as well.

Hi Julius,

the issue is, that when starting authorization maintenance, the 'normal' pfcg functionality is used. Means, authorization data is taken for the t-codes contained in the menu from SU24. It does not matter at this point, that the single role is a derived one.....

So there is no change of the status, the authorizations are not read from the master role! They come from SU24...

b.rgds, Bernhard

0 Kudos

Thanks for confirming Bernhard!

The thing is that I had already finished building the Master role and only wanted to maintain the local org.levels in the child roles, so I decided to do it while creating them as I would already have the role open at that time.

Of course I did not get very far using that approach as it always asked for all org.levels and the authorizations were all standard again.

Now that I am adjusting the Child roles from the Master role first, the inactive status is being correctly set and the "central" org.level which is common to the children is distributed as well. I made a mental RTFM note to myself to proceed in this order always in future...

The only piece of confusion left is that the system still prompts in the child role for all org.levels, regardless of whether the auths are all inactive for the field or not... so we just push 'N/A' out from the Master for that one field as well and hope that it always will remain so...

Cheers,

Julius