We know that when we use both General Authorization and Structural Authorization, then a user’s overall profile is determined from the intersection of his or her general and structural authorization profiles. While the structural profile determines the objects in the Organizational Structure which user has access to, the general profile tells about the data (infotypes, subtypes) and the level of access (e.g. read, write etc) for those objects.
Overall profile is the intersection of user’s structural and general authorization profiles as shown below:
This technical separation of general and structural authorization profiles can cause context problems for users who perform multiple responsibilities in an organization. E.g. A manager in an organization is in charge of several departments. However, the manager’s authorization for accessing certain infotypes should not be same for all departments.
Suppose a manager in the accounting department is also manager for another organizational structure (Payroll). Hence, being accounting manager for some of the employees, the manager is authorized to edit infotypes 0000 through 0007 of the employees in his accounting team. Also, since the manager is also manager for payroll organizational structure, he is authorized to access all payroll relevant infotypes (0008 and 0015) for the employees in the payroll organizational structure.
This consequently leads to overridings of authorization.
The structural profile and the general profiles get added to give overall profile. As a result, the manager has full read and write authorization from both structural profiles. When the authorization profiles are added together, the following overall profile is produced:
- All employees in the manager’s team and organizational structure
- Full read and write authorization for infotypes 0000 to 0008 and for 0015.
The context solution has been developed to resolve this issue of overriding authorizations unintentionally. Special context authorization objects having additional authorization field PROFL are used for this purpose.
The new Master Data authorization objects, P_ORGINCON and P_ORGXXCON were developed to make this possible. The new authorization objects differ from the old authorization objects P_ORGIN and P_ORGXX in that they contain a new field, PROFL (in addition to the same fields as P_ORGIN and P_ORGXX respectively).