Can an authorisation object ever have an open field and still work?

[Former Member]

Hi

Just a general question.

I'm compiling some SAP help guides and for PFCG I'm running through the authorisation tab and wondered about open fields in authorisation objects.

I was about to write "if a field in an authorisation object is empty (the field is showing status 'Yellow') then the object will not support its related transaction(s)"

I thought about putting "usually" or "very seldomly" in there as I'm not 100% sure that it was a true statement

Are the occasions when an empty field (not a ' ' dummy) in an authorisation object will still allow a transaction which relies on it to run as designed?

(I'm assuming no other roles are providing the missing object in full state)

Cheers

David

[Former Member]

HI David,

If the check is only coded against a single field in an auth object then it will work if that field is populated with an acceptable value.

If a field is empty and it's checked against then the check will fail & the rest of the program logic will decide what to do.

edit to add: I would stick with your original statement to stop any smart-arse using it as an excuse to not treat the gaps properly.

Cheers

Edited by: Alex Ayers on Jul 5, 2011 10:14 AM

[arpan_paik]

Sometimes in ST01 trace it could be found that one field value is checked and the other field/s is/are blank. However open field creates lot of trouble.

While generate profile it will give you an extra pop-up

While look into role authorization tab, traffic light is not green

Makes me feeling bad about that role and the creator

...so on

Regards,

Arpan Paik

[Former Member]

I would phrase it as "should never be able to... if coded correctly."

That was you do not give open field access and defunct checks in code dont work.

Cheers,

Julius

Edited by: Julius Bussche on Jul 5, 2011 3:29 PM

[Former Member]

Thanks all,

One training guide updated accordingly

Regards

David

[Former Member]

HI David,

the simple answer is, the Object will not function/work for that tcode, if any one of its fields is left blank. I do not know any standard object which has any one/more of its filed unchecked, and the rest checked. For customized object, if any filed is unchecked, then do not include it in the object.

[Former Member]

Hi Plaban,

Your answer is partially correct. If an authority check is performed against a single field e.g. ACTVT in F_BKPF_BUK then only that field needs to be populated. If company code is not populated then the check would still pass as it is only checking against ACTVT. As Julius mentioned, a correct check would be expected to be coded against both ACTVT & BUKRS and in that scenario the check would fail if either were blank.

[Former Member]

Hi Alex,

i agree to your answer. But i also mentioned, whether there was any standard Object which had one of its filed checked and the rest Unchecked. If there is, can you name so.

SAP standard objects should not be modified in code, to make one of the fields unchecked.

[Former Member]

Hi,

I've seen plenty of instances of P_ auth objects which have been incorrectly coded in the past. It was a few years back that I last worked in HR so you'll have to forgive me for forgetting which programs were involved. If I come across another one I will make sure to post it up here for your perusal!

[arpan_paik]

 Plaban wrote :
whether there was any standard Object which had one of its filed checked and the rest Unchecked. If there is, can you name so. 

I have seen plenty of them in many cases (many of them were for standard SAP). For an instance look at this [thread|;. The trace given by OP. There it is for S_DEVELOP object.

Regards,

Arpan Paik

[krysta_osborn]

I actually have an example where the answer to your question is yes.

We have a certain group of fields on the customer master that only a small group of users should be able to update. For all other users, those fields should be display only. We put the fields in a group and have secured them with auth object F_KNA1_AEN. The users who are allowed to update them have the value for the field group in their role. The users who are NOT allowed to update them have nothing, i.e. the auth is open in their role. It's all standard SAP, and it does exactly what the users want.

Now whether the customer master update program is coded correclty with regard to that auth object is a whole separate question. Another point to debate is whether we should've configured the customer master so that ALL fields are in a group so that we could eliminate the need to have an open auth. I'd argue no mostly because that is a lot of config just to give the security admin a warm fuzzy.

Krysta

[Former Member]

This object should be optional. So you should be able to set it to inactive and not leave the field open...

  if l_flg_x055_read is initial.
*-----select groups for account type 'D' with authority relevance
    select * from t055g where koart = 'D' and xnobe = space.   " ---> the result of the = select is not reacted to before the check...
      authority-check object 'F_KNA1_AEN' id 'VGRUP' field t055g-grupp.
      if sy-subrc ne 0.
*-----no authority -> select according fields
        select * from t055 where koart = t055g-koart
                           and   grupp = t055g-grupp.
          g_t_x055-feldn = t055-feldn.
          append g_t_x055.
        endselect.
      endif.
    endselect.

I would class this as a program error in my books, as optional objects should not be checked if a group is not assigned.

Cheers,

Julius