SAP Note

113290 - PFCG: Merge process when maintaining authorization data Version 26 Validity: 20.02.2008 - active Language English

Header Data
Released On 20.02.2008 10:13:55 Release Status Released for Customer Component BC-SEC-AUT-PFC ABAP Authorization and Role Administration Priority Recommendations / Additional Info Category Consulting

Symptom
The standard documentation currently does not contain any detailed information about the merge functions in transaction PFCG. However, these are helpful functions for simplifying the use of this transaction.

Other Terms
Role maintenance, activity group maintenance

Reason and Prerequisites

Solution
The merging of authorization data is a key function of the Profile Generator. It ensures the automatic adjustment of authorization default values contained in a role (activity group) after changes are made to the role menu. These default values can be sourced from the field values maintained intransactionSU24fortheauthorizationobjectsflaggedwiththecheckindicator"Check/Maintain"(asofBasisRelease7.00:"Check,default: Yes").. The merge function is called by selecting the option "Read old status and merge with new data" in the "Expert mode for profile generation" on the tab page "Authorizations". This option is already set by default after changes are made to transactions in the role menu. The mode of operation of the merge function is explained in detail in the following sections: A) General Information The authorization default values defined in transaction SU24, which you can recognize in the authorization list by the "Standard" maintenance status (and are therefore also described as standard authorizations), and authorizations that have the status "Maintained" form part of the merge process. All authorizations that have a different maintenance status ("Changed", "Manually") do not change during the merge process. The definition of the individual maintenance status is contained in the Summary of important definitions at the end of this note. Each time a merge process is carried out, the Profile Generator collects all of the authorization default values belonging to the transactions in the role menu and checks which ones have to be added to the authorization list. The result depends on previous changes to the menu or the authorization default values, and on authorizations that already exist and have the status "Inactive Standard" or "Maintained". Necessary adjustments of these authorizations are also carried out. B) Updating authorization data Depending on the maintenance status, the following rules apply to changes to the authorization data: 1. Standard a) Active An active standard authorization is always displayed if no authorizations with the status "Maintained" (active or inactive) or "Standard inactive" exist for the same authorization object,

in which the same fields are filled with default values as in the standard authorization and

whose default values contain the values for the standard authorization.

Ifanewactivestandardauthorizationisadded,itisflaggedwiththestatus"New". The above rules will be illustrated if you use any authorization object consisting of three fields as an example. The example must have a maintained authorization with authorization default values in the first two fields. In the first case, the new standard authorization is not added because, in both authorizations, the first two fields are filled with default values ("Standard" status) and the maintained authorization contains the default values of the standard authorization. MaintainedOldStandardNew Field1A,B,CStandardA,BStandard Field2C,DStandardC,DStandard Field31,2,3Maint.(empty)Standard

In contrast, the new standard authorization is adopted in the second case, although all fields contain identical values. However, the first criteria is not met because the third field also contains default values in the standard authorization; this field was originally empty in the maintained authorization. This shows that the standard values of both authorizations originate from different transactions. MaintainedOldStandardNew Field1A,B,CStandardA,B,CStandard Field2C,DStandardC,DStandard Field31,2,3Maint.1,2,3Standard The new standard authorization is also added in the third case, because its authorization default value contains more values in the second field than the maintained value. This means that the second criteria is not met. MaintainedOldStandardNew Field1A,B,CStandardAStandard Field2C,DStandardC,D,EStandard Field31,2,3Maint.(empty)Standard Note: The maintenance statuses of individual fields are not specified explicitly in the authorization list. Only the status of the entire authorization is displayed. Fields with maintained or changed content, however, can be identified by the dark background color behind the field name. The color of fields with the status "Standard" is brighter (see also the function "Legend" (ctrl+shift+F8)). b) Inactive Inactive standard authorizations are not automatically generated during the merge process, but are the result of the manual deactivation of authorization default values by the role administrator (see section D) Deactivating Authorization Data). In the following cases, the merge process causes changes to inactive standard authorizations.

An inactive standard authorization disappears if a menu transaction no longer exists whose authorization default values are contained in the inactive authorization. For example: A role contains the following inactive standard authorization for any object consisting of three fields StandardInactive Field1A,B Field2C,D Field3(empty) There are two authorization default values for the same object: Defaultvalue1Defaultvalue2 Field1AA,B Field2C,D,E(empty) Field3(empty)(empty) The first default value contains more values in the second field than the inactive standard authorization, while in the second default value, the same fields are not filled with values. This means that neither default value is contained in the inactive standard authorization. It is therefore no longer current and the system deletes it. Instead, both default values are added as active standard authorizations.

The inactive standard authorization is deleted if there is a maintained authorization whose standard values contain the values of the inactive standard authorization. For example: Assume the inactive authorization of the previous example again. After adding another transaction in the role menu, the following active standard authorization is included: Field1A,B,E,F Field2C,D Field3(empty) Maintaining an empty field causes an authorization to appear as "Maintained", which contains all default values of the inactive standard authorization. This is no longer needed to prevent new standard authorizations from being included, and therefore disappears after the next merge process.

If an inactive standard authorization consists of the default values of several menu transactions, and one or more of the transactions involved are deleted from the role menu, the Profile Generator automatically removes the respective default values from the inactive authorization. For example: The following inactive standard authorization consists of two authorization default values: Field1A,B,C,D Field2E,F,G Field3(empty) Defaultvalue1Defaultvalue2 Field1A,BC,D Field2EF,G Field3(empty)(empty) After deleting the transaction related to default value 1, the values that belong to default value 2 remain in the inactive standard authorization.

2. Maintained (active and inactive) Special care must be taken when handling maintained authorizations during the merge process in order to avoid any loss of values entered by the role administrator. The rules for maintained authorizations differ in two fundamental points from the rules for inactive standard authorizations:

If there is at least one authorization default value, whose default values differ from the maintained authorization, but has at least the same fields filled with default values, then the maintained authorization remains and is given the status "Maintained New". A new standard authorization is also added (see Note 766483). For example: The maintained authorization from point 1.a) again serves as a reference. The values of the authorization default value below are not contained in the maintained authorization. In both authorizations, however, the first two fields are filled with default values. Maint. New Standard New Field1A,B,CStandardA,E,FStandard Field2C,DStandardGStandard Field31,2,3Maint.(empty)Standard The change of status from "Maintained Old" to "Maintained New" is designed to make the role administrator aware of the fact that he must decide whether the maintained authorization will still be required or not. The Profile Generator is not able to make this decision because the cause of the discrepancy between the standard values of the maintained authorization and the authorization default value is unclear. This may concern two business processes that would have different consequences: The first option is to change the role menu by deleting transactions whose authorization default values originally created the maintained authorization. If this is the case, then the maintained authorization would become unnecessary and could be deleted. However, it is also conceivable that, instead of the role menu, the authorization default values were changed by participating menu transactions (transaction SU24). In this case, the maintained authorization must remain of course. It would be preferable if its standard values were automatically adjusted. The Profile Generator does not know which process has occurred because the database does not contain information about which transactions the authorization default values originate from, and it is therefore unavailable for future merge processes. This means that the role administrator must decide on the correct way to process the maintained authorization.

If there is no authorization default value in which the same fields are filled with default values as in the maintained authorization, the maintained authorization is deleted. The maintained authorization of the previous example disappears as soon as there is no authorization default value in which the first two fields are filled with values. There are then no more transactions in the role menu whose authorization default value can generate the maintained authorization. This means that it is unnecessary and can be deleted.

If the maintained authorization contains the merged default values of several menu transactions, and one or more of the transactions involved is deleted from the menu, the Profile Generator automatically removes the respective default values from the maintained authorization. This rule is exactly the same as the third rule for inactive standard authorizations (see 1.b)), which means that the example for that rule can be used to illustrate this rule. Simply assume that field 3 is maintained.

3. Changed and manually Authorizations with the status "Changed" and "Manually" are not affected by the merge process. They are always unchanged. C) Combining authorizations If several authorizations exist for one authorization object, the Profile Generator checks whether the status and content of the combination allow two or more authorizations to be merged. Automatic compression allows optimal display of the authorization list, and prevents unnecessary data from being saved in the role and the generated profile. The compression function works according to the following rules: 1. The active status (active/inactive) and maintenance status (standard/ maintained/changed/manually) must correspond for authorizations. Exception: Changed authorizations can be merged with manual authorizations, provided that the active status is identical. 2. Two authorizations that fulfill the prerequisites mentioned in 1. are combined if one of the two following cases occurs:
l

For all fields, one authorization is contained in the other (which includes the identity as a special case). The values of both authorizations differ in exactly one field, and are otherwise identical.

Exceptions:
l

An authorization that contains empty fields cannot be combined with another authorization in which at least one of these fields is filled. An authorization that contains fields with total authorization (*) cannot be merged with another authorization, in which at least one of these fields does not indicate a total authorization.

A classic example is the combining of authorization default values, in which only one field is filled with values in each case. The three following standard authorizations are combined into one single authorization during the merge process: Def.val.1Def.val.2Def.val3 Field1A,BB,CD Field2(empty)(empty)(empty) Field3(empty)(empty)(empty) After the merge process: Field1A,B,C,D

Field2(empty) Field3(empty) This situation is especially frequent for authorization default values for objects that contain the field "Activity" (ACTVT). In exceptional cases, the combining of default authorization objects given in the example may be unwanted. Instead, the role administrator wants to maintain the different values for the individual authorization default values in fields 2 and 3. Since you cannot deactivate the compression, you must correcttheproblemmanually.Therearethreeoptionsavailable: a) Copy the combined standard authorization as often as required. Maintain the empty fields in the copies and change the default values. This changes the authorizations to the status "Changed". Then deactivate the standard authorization (but do not delete it!). This creates a green status display for the object, and prevents the same standard authorization from being included in the next merge process. b) If you do not want authorizations to be changed, you use transaction SU24 to delete the default values in the first field for one of the relevant menu transactions. As a result, an additional standard authorization with three empty fields is included in the role during the merge process. You can maintain and copy this authorization as required for the desired differentiation. The other standard authorization with default values in the first field can also be maintained. However, you can also deactivate it if required. c) You add manual authorizations, enter all desired values, and deactivate the standard authorization. Note: Automatic combining during the merge process is only possible on authorizations with the status "Standard" and "Maintained". To combine changed and manual authorizations, you must execute the function manually. You can do this for a single object or for all objects. For a single object, click on the corresponding symbol in the authorization list (select Utilities -> Settings... -> Icons in the tree structure for merging several authorizations). To do this for all objects, select Utilities -> Merge authorizations. D) Deactivating Authorization Data After merging, several standard authorizations are often displayed with open fields for the same object. However, not all authorizations always have to be maintained to implement the desired authorization values. In this case, therefore, it is useful for two reasons to deactivate the unwanted standard authorizations: 1. No unnecessary authorization data is transferred to the profile that belongs to the role because deactivated authorizations are ignored during profile generation. 2. The same standard authorization is not added again during the next merge process (see Section B) 1.). For the reason given above, we do not recommend deleting standard authorizations completely. These could be added again during the next merge process. Note: As of the corrections contained in Note 679050, authorizations with the status "Maintained" and "Changed" are no longer given the status "Inactive standard" during deactivation, but instead retain the correct maintenance status. E) Authorizations for the Object S_TCODE Due to the dependency of the content of the role menu, the authorization object S_TCODE is of particular significance and is subject to special rules: 1. Authorizations for S_TCODE can exist only in the maintenance status "Standard" or "Manually". The standard authorization reflects the transactions and authorization default values contained in the role menu, while manual authorizations can include additional transactions that do not occur in the menu. 2. To ensure that the menu and the authorization data of a role correspond, you cannot change the standard authorization for S_TCODE (see Note 624207). This does not include the deactivation function (see Note 745665). 3. Combinations of active and inactive standard authorizations for S_TCODE are not possible. There is only one standard authorization, which you can set to either active or inactive. During merge operations, the authorization is automatically adjusted regardless of its active status, provided that transactions were changed in the role menu. Therefore, if the authorization is inactive, all added transactions are automatically inactive (also see Note 745655 under "Additional corrections"). 4. Transaction codes, which occur in manual authorizations as well as in the standard authorization, are removed from the manual authorizations during the merging process. This also applies if the standard authorization is inactive. If an authorization loses all transactions in this process, it is deleted completely. Combining important definitions
l

Authorization objects protect the execution of business processes. An authorization object includes up to 10 authorization fields, in which authorization values can be entered. An authorization is the permission to carry out a business action in the SAP system. It always relates to an authorization object and is defined by the values in the authorization fields for the object. An authorization is only effective for a user if a profile was used to assign it to the user. The total of the authorizations in a role or profile is classed as authorization data. To determine whether a user is authorized to perform a business action, the system carries out an authorization check in advance (ABAP command AUTHORITY-CHECK). When doing this, the system checks whether the required values are present in the user master record for each field of the authorization object. The authorization check is only classed as fully successful once all individual checks have been passed (AND operation). Maintenance status

Each authorization contained in a role is identified by one of four different maintenance statuses, which are defined as follows:

Standard The authorization has not been changed since it was included in the role during the merge process. It contains only authorization default values that are defined in transaction SU24. Maintained The authorization originates from a standard authorization, in which at least one empty authorization field was filled. Changed The authorization default values were changed in at least one field. Manually The authorization does not originate from the authorization default values defined in SU24, but is included using the menu function "Edit" -> "Insert authorization" (six options) or by migrating a profile that was created manually (transaction SU25, step 6.).

Update status After each merge process, the update status is specified in addition to the maintenance status. There are three possible statuses with the following meanings:

Old The authorization already existed before the merge process. There were no changes to field values Updated (see Note 871787) The authorization already existed before the merge process. However, the merge process led to changes in the field values.

The authorization was added with the last merge process (exception: see Section B) 2.).

Other Attributes
Transaction codes

PFCG SU24 TRANSAKTIONEN

Validity
This document is not restricted to a software component or software component version

References
This document refers to:
SAP Notes 1364935 General procedure for S_TCODE authorization default values 1441463 Interface to merge authorization data 1455518 Improved SAP authorization default values 1455679 Corrections for default values for field TASK_FLD3 1655686 i.s.h.med Authorizations: Correction of Default Values 624207 PFCG: Authorizations for object S_TCODE 679050 PFCG: Merging and combining authorizations 745655 PFCG: Various errors in the authorization data maintenance 766483 PFCG: Merging and combining authorizations (2) 871787 PFCG: New update status after merging