SU24 proposal settings in system parameters

[Former Member]

Hello

I'm just trying to brush off some Christmas cobwebs and I can't find an oldish thread which I thought I had viewed a little while ago regarding proposals in SU24 being reflected in PFCG when adding a new transaction and updating the authorisations tab in expert mode.

Is there a system parameter (RZ10?) which controls whether or not the 'YES' entry as well as 'CHECK' in SU24 results in the relevant authorisation objects being pulled in automatically in PFCG?

Sorry if this is a basic question.

Kind regards

David

[Former Member]

No, there is no system profile parameter (at least none I am aware of nor in the code of my system here..).

There is however a pair of exits before the popup. You could use them to set the radio button cursor if you wanted to. You can set the customer version in table SSM_CUST where ID = 'Z_BEFORE_PROF_GEN'.

Otherwise, what the expert mode popup does is influence the default of which radio button the cursor is set on:

- If something changed in the menu, it defaults to "Read old and merge new".

- If not, then it defaults to "Edit old status".

Cheers,

Julius

[Former Member]

Reading this again, I think you meant parameter auth/no_check_in_some_cases = Y (default) and not the popup in PFCG itself??

Turning this off will globally deactivate SU24. This means that all "no check" indicators are globally (and suddenly) activated again.

Not a good idea! (despite some auditors recommending it because it sounds nice...)

If you really want to go back to subsistence living in rural areas of the SAP world, then clean out SU24 and set those with Proposal = Yes to No but leave the param and the "Check = yes" as they are. You can do this per authorization object in SU24 (mass maintenance).

Cheers,

Julius

[Former Member]

Hi Julius,

I was eyeing for an answer from you on this one. This is a very interesting question raised here and I am also curious to know what triggers SAP to search for relevant auth objects marked as Check - Yes in SU24 and populated them in Profile as soon as a t-code is inserted in the role menu? However when a t-code is added manually in S_TCODE, this doesn't happen.

Thanks,

Deb

[Former Member]

what triggers SAP to search for relevant auth objects marked as Check - Yes

The menu maintenance or changes to SU24 trigger it. Hence using the merge option is always correct anyway.

Changes to SU24 come from SU22 or yourself (see comments from Frank Buchholz in the Interview questions sticky thread).

Changes to SU22 come from transaction CHECKMAN.

Changes suggested to CHECKMAN come from an RZ11 parameter called auth/authorization trace.

auth/authorization trace is controlled via another parameter called transport/systemtype.

Param transport/systemtype = SAP is in Walldorf...

Cheers,

Julius

[Former Member]

Thanks a lot Julius!!!!

Can you assign some points to yourself on my behalf as this is not my thread??

[Former Member]

No, and I can assure you that I would be the last person to do that if it was possible!

I am not the biggest fan of the points system...

Cheers,

Julius

[Former Member]

Hi Julius

It was a stupid question after all! I had created a test role and assigned SE16N and then expected the authorisation tab to automatically include authorisation object S_TABU_DIS - I was practising creation of auth groups for table in SE54

Due to user error, the SU24 entries I pre-checked were for SE16 and not SE16N. I would blame an old and knackered laptop for the missing 'N' but I got rid of that one

Because I didn't see the authorisation object I thought that this new system was still pending a few tweeks - sorry for the false alarm but I have found the parameter in RZ11 now and all is as should be.

Thanks to all for their time and...no points awarded even though the information was first class and did show a stupid S&A contractor where to find the correct place to check in future.

Cheers

David

[Former Member]

Ah, but exactly what you have described could infact happen without any typing error!

For example, in SU24 you will see that any of the SE16* tcodes do not have any "YES" proposals.

So, add transaction SE16_USR40 or SE16_BKPF etc (for example) to your role menu and open the authorizations tab in expert mode. S_TABU_DIS is pulled in and the where-used-list shows the origin as transaction SE16_USR40. But in SU24 there is nothing...

A round of beers (or pot of tea) is on me for the guru who can explain how that works and which parameter...

Cheers,

Julius

[Former Member]

re-opened.

[Former Member]

So you tried and now you are very curious, eh? Or thirsty?

[Former Member]

I suspect I won't be the one drinking the tea!

Checking SE16_USR40 in TCDCOUPLES it calls SE16 (no 'N') with a no check indicator. SE16 does have S_TABU_DIS set to Check and YS in my system so...just wondered where/if there is some pixie dust going on as a second check against the basic SE16 once called.

This is good!

Cheers

David

[Former Member]

Good instinct, correct conclusion about the pickie dust, wrong table though.

Take a closer look at table TSTCP field PARAM...

Cheers,

Julius

[Former Member]

Pixie dust gets everywhere.

OK - probably going down a completely incorrect path now...

Checking the where-used in SE11 field PARAM seems to be included in 3 function modules:

PRGN_GET_ORIGINAL_TRANSACTION

SRT_CONVERT_PARAM_TO_SREPOVARI

SRT_CONVERT_SREPPOVARI_TO_PARAM

I'm going to risk a beer on the first one but, seeing as I have no idea about function modules, it's a complete and probably laughably wrong guess!

Hope a guru out there can shed some insight

Cheers

David

[Former Member]

Exactly!

If the transaction is of type "Parameter transaction" and does not have an SU24 proposal of it's own, then PFCG finds the name of the core transaction it is calling and that transaction's SU24 proposals are inherited by the parameter transaction.

Waiter, please bring the man a beer!

Cheers,

Julius

[Former Member]

Ah - that was a lucky guess then !

Does this mean that SAP has set this to reduce ongoing maintenance by making the parameter tcodes NO on purpose so that the FM checks the original tcode instead so that we should only update the original transaction in SU24 or is it a good idea for the customer to localise the SU24 entries for the parameter transactions?

Just wondering if there is a best practice for these...and how to spot the little rascals too!

Cheers

David

[Former Member]

It means you can centralize the maintenance and scale the affect of proposing something.

However in this case of SE16* parameter transactions it is actually a symptom of laziness, as the name of the table accessed is known so why not propose the exact authorization group for it in the parameter transaction.

The same applies to S_PROGRAM when parameter transactions of transaction START_REPORT have a program group on them. The group is known so why not simply enter the group as a proposal for the parameter transaction?

A hint at it is in [SAP Note 1373111|https://service.sap.com/sap/support/notes/1373111]:

Within which transaction the authorization check was made; this can differ from the transaction code in the header of the display for technical reasons and is displayed only in this case.

--> the authorization traces mentioned above do not know anything about the calling transaction context anymore as system field SY-TCODE contains the name of the core transaction.

It would have to have been entered manually, and we all know what happens if things need to be done manually...

Had they offered the developers beers for accurately maintaining it, I am sure the situation would be completely different today..

Cheers,

Julius