Question:
We have to add a new transaction to an existing Role. The new transaction brings in an object that is already there with a different standard value because of a different txn. When we bring in the transaction, it merges the values under the same object in one line. Our problem is that we have added this new txn to many roles where we want the value active for some roles and inactive for others. Because SAP has merged the two together, to inactivate, I also have to inactivate the other value. Can this automatic merge be turned off so I could get two lines one with each value where I could inactivate the one I want to.. I have a work around but time consuming. Any ideas would be of help. PS I like to keep the statuses either standard or maintained
Answer:
You could use su24 to change the settings for the auth-object for this transaction from PP to P. When creating the profile the Auth-obj. won't be added anymore and u can do it manually for the roles you want...
it should be possible to add the txn with the setting "pp" to the roles you want to change, change the parameter via su24 to "p", and then add the tcode to the other txn...
pp = check & add to profile (in pfcg)
p = check
Answer:
Don't want manual status as you lose history on why its there and don't know if you should remove it if txn are removed. The work around was to inactivate the object that is currently there., add the txn and then go back in again and reactivate the inactive auth. That way you get the two lines. Was hoping a setting or switch could be turned on or off so that the new auth would not be automatically merged until you wanted it to.
Answer:
You do not want the merge to be inactive. Problem is, an addition of another tcode may cause your individual object to merge, which is what you want. By keeping authorizations "individual" and not merging you over load the user buffer, slowing the system down, increases the user logon time as more records have to be retreived, your database storage has to be larger, the SUIM reports run too long... and the list goes on.
A solution to your "problem" if you have some roles with one value ande some with others is to configure SU24 to be the most restrictive, generally display. You then add a manual to give the sensite access. To do this you adopt the practice of 1. documenting the access specifics in documentaton tab and 2. only allowing a MANUAL in a role if supported by a standard. Then if you remove the tcode and the Manual sit alone, then the manual should be removed after refering to the documentation.
Answer:
As an ddenum to john's note, another good practice when forced to insert MANUAL authorizations, is to changing the actual text on authorization (double click)
example: for P_APPL object
Manually HR: Applicants -Jul 19 change for all PERS Area
_________________
regards,
rob
Answer:
how to add a manual in pfcg without changing the maintained state to changed state , for example , we have an object for which by default it asks for 03 , so i go to su24 and set 03 as default , now only in this role i require to give 02 access , if i change inside pfcg from 03 to 02,03 the status changes to "changed" which is not good , so how can i add manual in pfcg without changing the status from maintained to changed status? where is this option? can you explain this please ,
Answer:
how to add a manual in pfcg without changing the maintained state to changed state , for example , we have an object for which by default it asks for 03 , so i go to su24 and set 03 as default , now only in this role i require to give 02 access , if i change inside pfcg from 03 to 02,03 the status changes to "changed" which is not good , so how can i add manual in pfcg without changing the status from maintained to changed status? where is this option? can you explain this please , You use the "insert Manual" button on the application tool bar on the authorizaiton page, do not use the copy.
Do note that if the tcode need 03 and is truely display, and is not table maintenacne , giving an 02 will not make the display tocde(requiring 03 and so configured in SU24) a change tcode. If you are required to give change access you may need to find the change transaction code to give the user. There are exceptions where a tcode can toggle based on access.