Been discussed before...
* is everything, Dummy is "something" - basically in some checks, the
code just wants to ensure that you have an authorisation for a given
object, and it doesn't matter what the value is, so you'll see Dummy
in the SU53.
hope that helps.
/henrik

hi monu,
can you explain better what you are trying to do?
i want to assume that you have a user with an authorization problem; and you ran an Authorization Trace, which showed you what Authorization components are missing...and you now want to add the missing authorization to the users Role.
is this it?
chumy

Dummy includes _nothing_! It will fail any check that isn't Dummy. As I
explained earlier, there's only a few places this is needed - and this isn't
one of them. No idea why you would think so...
If you want those values included, include them, otherwise don't

your explanations answers not the question where the Dummy-fields out of the trace are come from (SRM_MODEL= ). Is this because you choose no SRM_MODEL in this specific trace-action?

In his first post Henrik says that the code (dummy) want to make sure, that you have an authorisation for an given object and it doesn’t mater what the value is. So, the only restriction is that the value the user fill in, has to exist, not more, right?

In his second post Henrik says that any check will fail, that isn’t dummy. The question is, how can a check fail? I anyway have the authorisation, because it doesn’t matter what the value is. What’s my understanding problem?

In my generated trace I have one value (additionally to * and blank = dummy) that I can’t say what this is needed for. This value is a blank between apostrophe (‘ ‘, example S_BTCH_JOB, JOBGROUP=' ').

So we got three possibilities. *, ‘ ‘ and blank (that is dummy). Maybe somebody can explain an example to ‘ ‘ and blank (dummy) to complete my understanding.

your explanations answers not the question where the Dummy-fields out of the trace are come from (SRM_MODEL= ). Is this because you choose no SRM_MODEL in this specific trace-action?

In his first post Henrik says that the code (dummy) want to make sure, that you have an authorisation for an given object and it doesn’t mater what the value is. So, the only restriction is that the value the user fill in, has to exist, not more, right?

In his second post Henrik says that any check will fail, that isn’t dummy. The question is, how can a check fail? I anyway have the authorisation, because it doesn’t matter what the value is. What’s my understanding problem?

In my generated trace I have one value (additionally to * and blank = dummy) that I can’t say what this is needed for. This value is a blank between apostrophe (‘ ‘, example S_BTCH_JOB, JOBGROUP=' ').

So we got three possibilities. *, ‘ ‘ and blank (that is dummy). Maybe somebody can explain an example to ‘ ‘ and blank (dummy) to complete my understanding.

Wow, I sure must be off base - I always thought that &NC& was like ' ', and different from * . And, being the trouble maker that I am, how do you put Dummy inti a field that is less than 5 characters long?? Thanks Jim Wells

You said you concur with Henrik, but then you went on to completely contradict him!

This is really simple, and I don't know why we've managed to confuse it so horribly. If, in the ABAP code, the authority-check statement is coded to use DUMMY instead of a specific value for one of the fields, then it DOES NOT MATTER what value appears in the role. Period. Any value will do, as long as the user has a role that contains an authorization for that object. Here's the direct quote from ABAP help for authority-check: "Authorization fields that are not included in the statement or that have DUMMY specified for them are not checked." I have NEVER seen any deviation from that behavior.

The more fundamental point to get from that, for some people, is that "dummy" appears in the ABAP code - NOT in the values in a role!

The side discussion about &NC& was misleading too. This applies ONLY to the authorization object S_TABU_DIS, and the value &NC& for the field DICBERCLS means that it matches (authorizes for) any table whose "authorization group" is empty. This is NOT the same thing as ' ' (which would actually be a valid 'authorization group' - quote space space quote), and is a very restricted subset of *.

It's possible that one thing confusing the heck out of this discussion is the fact that the OP (both OP's actually - back in January and again in June) was looking at an authorization trace. Several people implied (or flat out stated) that you could "give the value DUMMY" to 'satisfy' the trace, but in reality the OP was looking to
_restrict_ the user's authority. If the ABAP code is checking that field with DUMMY, then there is NO VALUE IN THE WORLD that you can give the user for that field to make the authority-check fail. The only thing you can do is not have any authorization for that object at all.

My answer was focused on some minor exceptions around the treatment of
certain values in auth checks. Regarding the behaviour of dummy, I agree
with Henrik and now you but there are exceptions to the case.

In some rare instances the ABAP code evaluates * as a character and some
dummy checks coded will also not be satisfied. It is a nasty inconsistency
that I have seen less and less of the more the product matures.

You may not have experienced it and I am thankful of that as it is a pain in
the neck to get to the bottom of. Regardless, this behaviour occurs and I
have raised notes with SAP on a couple of occasions over the years when I
have come across it. The last one was on an ECC6 project 2 years ago so it's
not relegated to old systems only.