Display Authorization for MASSD

[former_member188806]

Hi,

There is a requirement for giving a user only display authorizations for MASSD.

I've tried various combinations of objects, however have been unsuccessful so far..

Pls. help.

Thanks,

Saba.

[Former Member]

Hi,

Go to transaction SU24 and check what are the objects that can be maintained and what are the default objects in the Tx MASSD.

check with the correct object and se the default values for it in Su24.

Come back to PFCG maintain that particular object according to the requirement.

Reward points, if helpful

Regards

Malti !!!!

[former_member188806]

Hi,

Without a * in C_APO_PROD, this T-code does not proceed ahead.Do you think in this case SU24 would help?

C_APO_PROD is "Check" in su24.

Thanks,

Saba.

[Bernhard_SAP]

HI,

you cannot change the values which are checked during a transaction with SU24! You only can swith off the check at all.

The single values in SU24 are simply the proposals for pfcg to be merged automatically into the authorizations....

so I have to guess the complete oposite of Malti.

b.rgds, Bernhard

[former_member188806]

Dear Bernhard,

You are indeed right about SU24.

I fail to understand it's real purpose since objects can anyway be modified with PFCG.

Dear Mylene,

I'm not sure what exactly are BUS objects.The problem is that the user does not want to see a "save" button also on the screen..i.e. MASSD in a completely display mode.The problem with authorization level restrictions is that unless the activity is 02, the T-code refuses to go to the 2'nd screen..

We found a workaround...using an SAP query with the right combination of Product-Location tables.

Thanks a lot everybody..

Warm Reagrds,

Saba.

[Bernhard_SAP]

Hi Saba,

the proposals (values maintained in SU24) should save time to role administrators.

The developers maintain those values which make sense in their eyes. As example if they provide a transaction for creation of an item, they propably would maintain the activity 01, for a display transaction actvt=03 and so on. That will save time to admins, as they would not have to enter the values once more (compared to an empty field....). Of course, that proposals are still proposals only!

For complex transactions it makes sense, to have a proposal of which authorization objects are necessary to be able to execute that transaction.

Maybe you can remember the old procedure before pfcg had been invented - it was hard work first to identify all the objects checked with its values, then create the corresponding authorizations in SU03, then create the corr. profiles in SU02 and finally assign that profiles to users in SU01. That was really time consuming....

So the invention of pfcg opened a very comfortable and quick possibility for that tasks with a high range of automatism. Of course this automatism can only be as good as the values which are behind it. So having accurate SU24 settings help a lot.

So enjoy pfcg

b.rgds, Bernhard

[former_member188806]

Dear Bernhard,

Thank You so much for the lovely explanation..I don't know about others..but atleast in our systems; we always begin with PFCG..so SU24 does not have any meaning.

Warm Regards,

Saba.

[jurjen_heeck]

> in our systems; we always begin with PFCG..so SU24 does not have any meaning.

Oh yes, it does

When you enter a transaction in a role in PFCG and go to the authorizations tab you'll see one or more objects, partially filled with authorization values.

This information is pulled from the tables USOBT_C and USOBX_X.

These tables are maintained with transaction SU24.

So, you can safely ignore SU24 and continue as you were doing. If, however you find that you always have a lot of manual work to do in PFCG after entering a specific transaction into a role you could consider adjusting the proposal values for this transaction in SU24.

If you tailor SU24 to your needs the building of roles will take a lot less time and effort.

hth

Jurjen

[Former Member]

Hi ,

i guess definately i t would help

Regards

Malti!!!!!!!!!

[Former Member]

i had a look at MASSD since the transaction was news to me, we still use good old MASS instead. i understand, that the difference is 'only' that all action is displayed on one screen instead of several like with MASS.

so the first object to really restrict your users to view 'all' BUS-objects should be B_MASSMAIN where you decide which BUS the user shall have access to but then it will still be on the level of the bus-object to restrict changes, for example: ojbects M_MATE* for BUS1001.

as for abap-coding in MASS and security aspects, see note [445892|https://websmp130.sap-ag.de/sap(bD1kZSZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=445892]