Double quotes in Authorization fields

[Former Member]

Hi Experts,

I searched hard but couldn't find answer to this query. Sometimes we get double quotes like ' ' in role authorization Objects-Fields value.

Sometimes it is in functional field, sometimes in Org field. The field may have other values along with it. What is the relevance and functionality of this value?

For ACTVT it's description is like "not allowed", but couldn't find its meaning for other fields. Any help on this is highly appreciated.

Thanks & Regards,

Sabita

[former_member204634]

Hi Sabita

' ' or " " or DUMMY means that the field value is blank for that field, so when authority check is performed on the authority object, for the field to pass authority check a dummy/blank value is required and hence we need to maintain " " or ' ' i.e a dummy value for that field in PFCG. I guess the significance is that for a authorization object to be used in various program/t-codes - for some t-codes some fields are important while others are not relevant and hence they are maintained as dummy.

Literally dummy should mean that any value should pass the authorization test but that does not happen as per my experience, you need a dummy value maintained in that field and even " does not suffice for passing the authority check.

Hope this Helps!

Regards,

Prashant

[Former Member]

I am not content with your answer.

Just the other day I ran into precisely this problem where I would have had to maintain BlankBlank (two!) in the plant field in C_STUE_WRK. That's plain dumb!

If the developers mean to emphasize that in certain cases the content of a field is irrelevant, they can pretty well code it accordingly!

So, Dummy is for 'all values pass' and Blank is a case for a call at SMP!

[Former Member]

> If the developers mean to emphasize that in certain cases the content of a field is irrelevant, they can pretty well code it accordingly!

This is something i definitely agree to

My understanding says a ' ' value is to be interpreted as: whatever value the user executing the transaction/program has for a particular field

As a example, if we have a wirtten in the ABAP code for the object M_MATE_VKO , it implies that the user executing the transaction for material master can create materials on sales organization XXXX (or) YYYY (or) ZZZZ, if the user has any one or all of these values in his authorizations

[arpan_paik]

 I searched hard but couldn't find answer to this query 

I don't agree with that. For an instance try this [Thread|]

Edited : And there are many more for this topic.

Regards,

Arpan Paik

Edited by: P Arpan on Jun 29, 2011 2:31 PM

[Former Member]

I searched hard but couldn't find answer to this query

> I don't agree with that. For an instance try this [Thread|]
> 
> Edited : And there are many more for this topic.
> 
> Regards,
> Arpan Paik
> 
> Edited by: P Arpan on Jun 29, 2011 2:31 PM

Brilliant! The thread linked by P Arpan is all the backing my post upthread needs!

But the use-case of SPACE (one character as blank field) is what I find suspect in any coding.
- You do not have to check all fields of the object in the authority-check, so you can ignore a field if no value is expected.
- If no value is found for the check to be performed against, then we can assume that the field selected must be optional - so the authority-check should be as well to optionally activate it. BEGRU is an example of this.
- If it is mandatory somewhere, but not yet known in the program flow then a DUMMY is the correct approach to take a look into the user's authorizations with a crystal ball to see whether there is something.
- If an empty field in the select is to be interpreted as "no access unless all access to SPACE" then it is best to replace the SPACE with a real string (like S_TABU_DIS does with '&NC&') and then check that value as a symbolic representative.
Hardcoding SPACE(s) is suspect and personally I do not see the use-case either for hardcoding SPACE in authority-check statements if their location is correct, let alone stringed SPACE's as an extention of such a workaround.

.

QFT. Thanks, Julius.

[Former Member]

> - If it is mandatory somewhere, but not yet known in the program flow then a DUMMY is the correct approach to take a look into the user's authorizations with a crystal ball to see whether there is something.
> 
> 

.

this pretty much ties in to what i mentioned above, you agree?

[Former Member]

Hi Arpan,

The thread provided by you is still un answered to the original question. Unfortunately I am also not good in coding, hence my question is the same as the Opener of this thread.

I have got really good answers and discussion in this thread, will check all of them and will come back to you all.

Regards,

Sabita

[Former Member]

Hi Sabita,

The value ' ' is used for maintain a particular Org.Level to play as DUMMY.

For Example, in a scenario where in a Report/Transaction Code has values like Plant, Company Code, Sales Org, Division, and Distribution List. The user in general needs to maintain all the respective values to generate a report/Output; however the user doesnu2019t want to maintain the field sales org but wants to generate the report. Though the role has values maintained for Sales Org in the Org.levels.

In these scenarios we can maintain the value ' ' this will assume that this field is DUMMY unless Maintained with Sales Org.Values in the field Sales Org.

If the user wants the report along with the Sales Org he needs to maintain the respective Sales Org as mentioned in the role, if the user doesnu2019t want to use the fields Sales Org but wants to generate the report he can do that with out assigning any values in the Sales Org field.

Hope this answers your query

Regards