We have a custom Z-table with Sales Organization and Order Type as key fields.
There's an associated maintenance view.
Users will be using this maintenance view to maintain entries in the table.
Users should only be allowed to display and edit records that belong to the sales organizations and certain order types that they are authorized to.
The usual approach
As many of the articles would suggest, the most sought-after approach would be to create 2 authorization objects (one for sales org, one for order type) and then use maintenance view Events 01 (Before saving the data in the database) and AA (Instead of the standard data read routine) to check each row's data against the authorization object and remove unauthorized entries.
If the authorization objects are already in place and assigned to the user, there's no work to be done from the authorization (BASIS) perspective.
As this is purely a custom logic, this also gives freedom to introduce new error messages, extra validations, etc.
There is coding involved as the authorization check happens at the code level.
As there's custom code involved, there will be increased unit test efforts for positive and negative scenarios to ensure that all scenarios (display, change, insert, delete) work as expected.
If we don't authorize the maintenance view from standard auth objects (S_TABU_DIS), the user should have "change" access to the SM30 transaction. Then the coding will have to control everything else. With the user getting "change" permissions to SM30, other Z tables will also become changeable - which is not what we expect.
One can't see from the authorization object assignment perspective whether there is an object assigned to the maintenance view or not.
The better approach
We can use the two standard authorization objects and the maintenance view's authorization group to handle this requirement with no code changes.
The authorization checks, error handling, and everything is handled by the standard itself which takes a significant burden off our shoulders. Also, we can clearly see in user roles how the assignment is done.
Here are the steps:
Authorization Group setup
This is needed only if you don't have an Authorization Group created already.
Go to the table maintenance view generator, and create an Authorization Group via Environment > Authorization > Authorization Group
In the new screen, under object S_TABU_DIS, create a new Authorization Group with a 4-character name that starts with Z. For this scenario, let's say it's ZAUT.
Go back, and assign this new Authorization Group in the Table Maintenance Dialog Genearator window.
Authorization Object: S_TABU_LIN setup
Go to SPRO > IMG > SAP NetWeaver > Application Server > System Administration > Users and Authorization > Line-oriented Authorization > Define organizational criteria
Create new Organization criteria entry:
We don't need to do anything for the "Assignment of authority object to organizational c" step.
Select the created entry, and go to "Attributes". Then, hit "New Entry". Here, we can list up to 8 attributes. The attributes are basically the key fields that we need to filter the records based on values that we define later. In this example, we need 2 attributes - VKORG, AUART. Create the first:
Hit the "Next Entry" button and create the second attribute as well. Note that the "Authorization fld:" value at the bottom of the screen is now changed to ORG_FIELD2 from ORG_FIELD1 for VKORG.
Then, go to "Table Fields" in the left-side tree. And create an entry specifying our custom table and field name that would align with this attribute.
Do the same for the next field (Attribute 2) as well. And continue to do this for all the attributes you've defined.
Once done, save under a workbench TR and exit.
Authorization Object configuration from BASIS
Now, it's time to set the appropriate values for the respective authorization objects so the setup starts working as we want.
Set "Change" permission for the Authorization Group via the S_TABU_DIS authorization object. To do so, set ACTVT= 02 DICBERCLS = ZAUT (authorization group assigned to the table) This allows the user to access the tables with auth group ZAUT in change mode.
Set row-level filtering via S_TABU_LIN authorization object. Set values as ACTVT = 02
ORG_CRIT = ZTESTAUTH (this is the new organization criteria we created in SPRO) ORG_FIELD1 = <sales org>
ORG_FIELD2 = <order type>
With this setup, it says that the user can insert/change/delete the entries belonging to sales org 1030 and order type ZORD.
Assign these to respective roles and to the users as usual and let the standard take care of all the validations, etc.