How can you make a button accessible only for a specific login ID in a custom Z report in SAP ABAP?

[Gauravvashishtha7]

First, go to System → Status and find the program name of the custom transaction code (T-Code).

Go to the code and press Ctrl + F to search for REUSE_ALV_GRID_DISPLAY. Check how many times it is being called. For each occurrence, find the PF-STATUS parameter. If it's commented out, uncomment it and declare a PF-STATUS for each instance.

THEN, we will create a table and declare a field using a Data Element, where only the entries maintained in the TMG will determine access to a specific button.

Go to SE41 and copy the standard PF status for two cases:

1. One where the button is present.
2. One where the button is not present.

THEN, develop the code using a PERFORM routine, ensuring that the button visibility is dynamically controlled based on the user command’s ID. The button should be visible only if the user command originates from a specific user ID; otherwise, it should remain hidden.

Now, only the user with the assigned access can see the button. For all other users, the button will remain hidden

[Sandra_Rossi]

REUSE_ALV_GRID_DISPLAY is obsolete.

Use CL_SALV_TABLE instead (or the IDA variant).

Concerning SET PF-STATUS, if all buttons except few are the same, you might opt for only one GUI status and exclude dynamically one or more buttons via EXCLUDING:

DATA(function_codes) = COND ui_functions( WHEN condition = abap_true
                                          THEN VALUE #( ( 'ZZBUTTON' ) ) ).
SET PF-STATUS 'ZSTANDARD' EXCLUDING function_codes.

Also, for posting code, please use the </> code button instead of screenshots as explained here: https://community.sap.com/t5/questions-about-sap-websites/how-to-post-code-in-sap-community-gt-2024/...

[jmodaal]

Hello,

in addition to what @Sandra_Rossi already has written, I would like to add, that hiding / enabling functions depending on a user ID I consider as a really bad idea and a bad design. If there are reasons for offering functions to specific people (maybe admins), then this should be implemented by authorizations and not depending on user ID's.

Kind regards

Jan

[Jelena_Perfiljeva]

Agree 100% with @jmodaal : instead of storing user ID in Z-table, create a custom authorization object (or use an existing one, if appropriate), then run authorization check. Based on the result, use EXCLUDE, as Sandra suggested to exclude function(s) user is not authorized for.

Storing specific IDs in Z table is not only maintenance nightmare (who's going to maintain entries when users leave the company or new ones come in?) but is difficult to troubleshoot. If you use authorization, then to answer "hey, why Joe doesn't see what Jane does?" can be answered by running SU53. This is also a common approach in standard transactions in similar cases.