How to know if a security field in an object, is an activity type or if it is a local value?

[Former Member]

For Example, I have the security object CRM_BUHI, which has the fields:

ACTVT

HIER_TYPE

I would like to know, which table in SAP identifies if the field is an activity type (such as the ACTVT is in the list before), or if it is a local value (such as the HIER_TYPE is in the list before).

There are some other activity type fields that are not called ACTVT, so I would like to know if there is a way to validate the information type in a security Field.

Regards

Alan

[mvoros]

Hi,

you can see all fields used in authorization objects in transaction SU20. It tells you which table is used as a source of values. In case of ACTVT it's TACT.The field ACTVT is special because it's handled differently in SU21. You will get button "Permitted Activities" when you use this field on authorization object.

Cheers

[Former Member]

Hi Martin,

Thank you for the quick response.

I saw report SU20 and it states that ACTVT is in fact TACT, but what about for example ACO_ACT_S? It is also an activity field but the TABLE information is not populated.

Also, I have to validate a lot of security roles. Is there a way to do it massively?

Regards

Alan

[mvoros]

Hi,

I don't know why some objects do not use ACTVT. One of the reasons could be that developers were not happy with activities in TACT and created separate field.

Regarding ACO_ACT_S. It uses domain ACO_ACTIVITY_SUPER. If you open this domain in SE11 then you will see that it allows only 3 values (ADMIN, WRITE, READ). Why developers did not use activities 33,34 and 70 of field ACTVT? No idea.

Generally, you could have a field with domain that does not restrict values and no table assigned to this field. In this case the only 2 ways how to figure out values for this field would be to tracing application or reading of code.

Cheers

[Frank_Buchholz]

Authorization fields having the semantic of an activity are not special (except for the special 'permitted activity' function for field ACTVT ) - they are just ordinary authorization fields like most others (in opposite to org.level fields which are treated in a special way within PFCG).

Most developers at SAP had used the authorization field ACTVT for representing an activity, however, you can find many more fields in transaction SU20 which are activities as well. Filter for '*Activity*' or  '*Action*' in the short text or for '*ACT*' or '*FCT* 'in the field name or data element name to get some examples. 

.. bad luck ..

That means, e.g if you want to create a reald-only role you should have a look to all authorization objects in a role. (And in addition you never can know if a transaction or a report is read-only or not.)

.. more bad luck ..

Kind regards

Frank

[Former Member]

One way of doing it is to gather information content which is "white listed" for read only. This includes occational write access to logs even which might be authorization relevant! Excludes selected transactions, function modules, webservices and dynpro contexts that are functionally only capable of displaying. Documents all the content sensitive or context neutral object related and field values which are "ok".

Then you need to have a naming convention which allows you to identify roles which are mean to be "display only" and have a way of mitigating some roles as exceptions (otherwise you end up with 5000 roles and not 50....

If you get that right (not easy, but not "bad luck") then all you need is to start the watchdog to scan the roles for those exceptions to the white list content and integrate it into the transport system with a warning and optional workflow for approval....

Normally a warning and email about the event is enough.

Cheers,

Julius

[Former Member]

UI looks like this: