Question: Promoting a field to Org Level

[Former Member]

All,

I just need an opinion or advice on promoting a field to org level. When I run PFCG_ORGFIELD_CREATE in test mode, the program displayed numerous roles affected, there are about 50 plus. Iu2019ve done a field promotion to org level in the pass but that was before go-live and we have minimal security roles being affected.

Question: Based on your experience or good business practice, if the affected roles are not regenerated after the field promotion, how will they behave? Please note that eventually I will be regenerating them all if a change request comes in for the affected role/roles regarding other changes. My main goal for now is to promote a field to org level so I can create a new derive role to child roles (600+) security design.

Replies, feedbacks will be appreciated.

John N.

[Former Member]

AGR_1251 is your friend here if the profiles are current and SU24 does not have any non-org data for them not merged yet.

The main pest is that org fields are auth object independent per role so your previous build might have been done at a higher level of single roles than what the new org. field will permit.

This might even impact more than 50 roles if you built dependencies into them (delta roles, enabler roles, emergency user roles...).

Cheers,

Julius

Edited by: Julius Bussche on Jun 3, 2010 11:23 PM

[Former Member]

>

> AGR_1251 is your friend here if the profiles are current and SU24 does not have any non-org data for them not merged yet.
> 
> The main pest is that org fields are auth object independent per role so your previous build might have been done at a higher level of single roles than what the new org. field will permit.
> 
> This might even impact more than 50 roles if you built dependencies into them (delta roles, enabler roles, emergency user roles...).
> 
> Cheers,
> Julius
> 
> Edited by: Julius Bussche on Jun 3, 2010 11:23 PM

Thanks Julius. I'm quite familiar with table AGR_1251 and I was pleasantly surprise that the test mode numbers do match this table. The test mode even took into consideration auth objects with the field that are deactivated ("objects is deleted" in AGR_1251).

I'm leaning towards just doing the changes for all the affected roles and notifying the business owners to test.

[Former Member]

If each of the 50 roles have the same value for the field per role and there are no other impacts, then I would say it is a natural candidate for promotion.

Another eventuality you might want to check is that there are not more than 99 authorizations per role for the objects which use this field. For org. level fields, the system cannot generate a second, third, etc profile for the role to add more authorizations for them. An org. level makes the field authorization object independent with only one profile.

Cheers,

Julius

[Former Member]

> Question: Based on your experience or good business practice, if the affected roles are not regenerated after the field promotion, how will they behave? Please note that eventually I will be regenerating them all if a change request comes in for the affected role/roles regarding other changes. My main goal for now is to promote a field to org level so I can create a new derive role to child roles (600+) security design.

Hi John

There shouldn't be any immediate impact on authrizations. Why not do a mass generation of these roles through trxn SUPC.

Note: We should always ensure that all our roles are generated.

Thanks.

Anjan

[Former Member]

Thanks Julius and anjanpandey. Work is work so I have to eventually regenerate the roles, so we'll just be doing it. I believe the impact will be very minimal since we are keeping the same values. I'm setting this question to resolve. Thanks again.

[Former Member]

Just curious: Which field is it?

Cheers,

Julius

[Former Member]

Julius,

It's GM_AUTHGR.

[Former Member]

As the field is an "authorization group" type of field and used by 4 auth objects, you should perhaps check that you are using all 4 with the same semantics for the groups.

For example, the authorization groups for programs and tables are not natural candidates for org. levels as they are not scalable in this way.

Central customer, vendor and GL account groups not necessarily either.

You should check the grey areas, and if you are not using all 4 objects then consider down the line that you might. Downgrading the field is an option, but if you have built derived roles based on it then it will hurt...

Cheers,

Julius