How to hide buttons of PF-Status in ALV report for specific users?

I have ALV report, couple of buttons performing certain actions(create, delete lines etc.) and I'd like to forbid specific users from seeing those buttons.

Where exactly in PFCG should I go after creating auth. object in SU21 in order to set it up?

Is it even possible to hide let's say just one button or do I need to create separate PF status just for the specific object with users?

Thank you

Solution

There are no implicit permission checks for specific buttons in specific programs. So you can not make buttons disappear from a GUI-Status using permissions alone. But you can make individual buttons disappear via code using SET PF-STATUS.

When the report is your own, then you can of course just modify your own call to SET PF-STATUS. But when the gui-status is set by the SAP standard code, then you need to figure out:

Some place in the PBO modules after the original SET PF-STATUS where you can inject code
The name of the status set by the standard
The function codes of the buttons you want to remove

For example, when your status is named "STATUS_1" and the buttons you want to hide have the function codes "CREA" and "DELE", then you would do it like this

DATA(hidden_buttons) = VALUE syucomm_t(
   ( 'CREA' ) 
   ( 'DELE' )
).
SET PF-STATUS 'STATUS_1' EXCLUDING hidden_buttons.

But always remember that hiding the button does not disable the function code! Users who knows the function code can still enter it into the SAPGui command field and the PAI will react to it as if they had clicked the button. So when this button does something that should require a permission, then you still need to make sure that this permission gets checked before the action is executed.

If you want to construct the table of excluded buttons based on permissions, then you can check a specific permission with the AUTHORITY-CHECK statement within your code and decide based on the sy-subrc value whether or not you want to add a button to the list of excluded buttons.

But first need to decide what object to test for and what field values within that object. This depends on the permission concept of the system you are working in and the module you are dealing with. Perhaps you already have some permissions for a standard permission object which would be suitable to cover your particular use-case. Perhaps you do not, which means you might have to create a custom permission object, create roles which contain permissions for that object, and assign those roles to users.