maintaining the authorizations for parent role and derived role

[Former Member]

Hi Experts,

Kindly advice me the Pro and cons of the parent role and derived role.. below is the scenario

Currently we have created the 700 role in our regionally organization and we want to dervie the roles for each country

1 ) we want to do the Auth field (activity level) settings in parent role and Org levels in the derived role .

2) But one my collegue says do the default Auth filed ( activity values) common to every country in the parent role and diff activity one in the derived role .

please advice me wat will be the best scenario for mantaining the authorizations filed values like (activity level one)

[Former Member]

Parent --> derived design works well when you have several roles for different org units (like country in your case) - but all these roles are similar in their fucitonal access and only differ with org level values.

Now coming to your questions:

1 ) we want to do the Auth field (activity level) settings in parent role and Org levels in the derived role . - it makes sense, only activity level (fields in auth objects) and transaction access will be mainatained in parent role. Org level accesses should all be defined in individual child roles.

2) But one my collegue says do the default Auth filed ( activity values) common to every country in the parent role and diff activity one in the derived role . - i couldnt understand the meaning of this part.

But you could read up the dervied role concept to understand this better, If you have anymore specific questions, please reply.

Soumya

[arpan_paik]

Try [this|] one

P/S : You will find one post of mine to add objects manually. Disregard that please. Rest is full of discussion on master derived concept

Regards,

Arpan Paik

[Former Member]

Hi,

Regarding the ans to your questions the first scenario is the best one.

1. Since you will be doing all Auth and field setings at the master role same will be Inherited in the derived roles (derived at country level in your case) when you Adjust derived the master role in PFCG however the diff between the master and derived role will be that you will be maintaining the org levels in the derived role and rest all will be same.

2. I could not understand the second question could you please elaborate on the same.

Thanks.

[Former Member]

Thanks fro the reply

Below is my second question

But my expert says they are some NON ORG values different from each country ..suggest us to maintain all the default values in Parent role and auth with diff values needs to be maintained in derived role (child role)..

my suggestion is to maintain all the NON org values ( default & diff ) need to be maintained parent role.. and modify it according to the each country .

[Former Member]

Hi,

I think thats what my first Answer says maintain all values in the parent role and differentiate at the derived role.

Thanks.

[Former Member]

Since the values are different for different countries, why dont you consider defining these values (custom defnition) as org levels in your system? You can use program "PFCG_ORGFIELD_CREATE" for the purpose. That way in the child roles you can give all default values of this field + the country specfic values which that role needs.

If you decide to keep this field as NON Org itself, do keep in mind - you should not maintain the field value in the child role's authorization object level. The child roles should only be maintained at 'org levels'. All object level values should be maintained in the parent only.

" my suggestion is to maintain all the NON org values ( default & diff ) need to be maintained parent role.. and modify it according to the each country ."

if you put the diff org level values into the parent role - all child roles will have these values in them, i think that contardicts the idea of limiting the country role to default + country values only ..right?

[Former Member]

Hi experts ,

please higlight the problems going to be faced by doing the below sceniro

Sceniro :

my collegue says they are some NON ORG values different from each country ..suggest us to maintain all the default values in Parent role and auth with diff values needs to be maintained in derived role (child role)..

[Former Member]

Soumaya

And also please explain me the approch of defining these values (custom defnition) as org levels in your system using program "PFCG_ORGFIELD_CREATE"

Thanks

[Former Member]

I will try to answer both your queries here:

"my collegue says they are some NON ORG values different from each country ..suggest us to maintain all the default values in Parent role and auth with diff values needs to be maintained in derived role (child role).. "

The only set of values which should/can be different in a child role (when compared with its parent) will be the org level values. So if this filed is NON_ORG you will not be able to maintain it directly inside the child roles.....this is the basic principle of derived role conceptu2026 that the only item you will directly maintain in a child role are the org levels(which will come as u2018organisational levelsu2019 in the upper tab in the auth data of a role).

All NON_ORG fields inside a child role is acquired from the parent role. You should never change the values of any such fields (non-org fields) in the child role. these changes will get lost the next time you run the parent child inheritance from u201Cgenerate derived roleu201D function in your parent role.

Coming to the second question on how to run the program, you just need to enter the technical name of the field you want to convert (tech names like BUKRS, WERKS etc u2026 figure out the name of the concerned field you have in hand)u2026.executeu2026 you will that the field will now onwards appear as an org level value in all roles in the system and not just as a field inside the auth objectsu2026.I would suggest you take one field and try running it in ur dev or sandbox..see how the field changes in your roles.... the change can always be reverted by using PFCG_ORGFIELD_delete. ... you will understand it better....

Soumya

[Former Member]

Hi Mohan,

We faced similar problem when some of Functional fields had different values for derived roles but we couldn't convert it to Org field for some limitations. Maintaining it in Master role would be a mess as each time there is any change in master role, the functional field values in derived will be overwritten.

We followed below -

1. We maintained all Org fields in Derived roles.

2. We disabled those Objects containing Functional fields which would be maintained seperately in derived roles(in master roles).

3. We created Enabler roles containing only those Objects for each different derived role and activated required value.

4. Created composite roles containing type 1 and type 3.

Little extra effort first time, but we are comfortable with the results.

Regards,

Sabita

Edited by: Sabita Das on Jun 7, 2011 7:28 AM

[Former Member]

Hi

Point 2 - I'm going to take a stab at these fields (activities) being related to cost centres/storage locations and release strategies?

If these values are contained in a derived role and are actively being maintained at the derived level then these are probably best treated as not suitable candidates for parent/derived and the link should be broken after agreement.

If it's not this then I'm stuck...

Cheers

David

[Former Member]

100% agree with you.

KOSTL (if not using RESPOAREA, which is much better) and LGORT/LGNUM and other associated fields for "storage locations and values" are candidates to consider provisioning isolated roles - but I still believe it is avoidable if the authors of the requirements are given the task of maintaining them (e.g. via the standard hierarchies which these objects also support).

9 times out of 10 you only need to read the documentation and compare it to the coding...

Cheers,

Julius

[Former Member]

Hi Mohan,

You cannot maintain all the non-org values in the parent role. When you derive it, all the child roles would be getting these values. Also, if you manually maintain different values in child roles thats not maintained in parent role, it would become an overhead for you whenever you need to modify the parent role say for example if you need to add a transaction. All the child values would be overwritten by the parent role and you need to maintain these child values all again! This would become tedious maintenance overhead tasks for your security team.

If you have diff auth values for each child roles, better you dont go for the parent child roles or please follow the suggestion given by soumya.

Regards,

Madhukar R