GRC Compliance Calibrator 5.3 and the "action" field for S_TCODE.

Question

Dear GRC gurus,
I have read the threads here on the search terms for the "action" field in the "function" definitions, but not found a clear answer... so forgive me for asking a possibly obvious question.
When implementing the technical rules for the function, it seems that the "action" field is included in the check even if it's value is not in the "permissions" of object S_TCODE. But there is no "look up" nor validation (how could there be from the Java system?) on what that value is.
Appart from the fact that one might be tempted to enter some nonesense text in there, what is the logic behind the checks in the coding if it happens to fit a tcode name and is this field truncated at any points?
The reason for asking, is that we have some critical functions in the system for which we do not care how the user gets to it (tcode's... , rfc's..., service's... etc) but want to analyze whether the users can infact use the function (as opposed to attempt to start it). This makes sense in many business functions, and for the "basis" stuff which is critical it should be clear).
What we wanted to do was "name" the action by it's well known transaction code (in a symbolic sort of way, for the business users... to be able to recognize it, symbolically... although S_TCODE does not have an activity field........) but not have it checked in the rule set at the technical level. The standard delivered rules seemed to do the same thing... but we are still stuck on the s_tcode check because we dont want it in some cases and have good reasons for this.
- Can anyone confirm how this really works? For example wild carding FB* as the action name?
- Assuming our above analysis is correct, which tricks can you recommend (add a "dummy" action?; add a * action?; a possible naming convention?) to shed the harness of the tcode check (or having to document all of the buggers in the actions...) but still make it useable for the only slightly technically inclined folks who do understand that there are enough tcodes or it is critical enough that we should not rely on the "very general" protection provided by tcodes?
Bad news, future insights and work-arounds are all welcome
Cheers,
Julius
Edited by: Julius Bussche on Dec 10, 2008 11:30 PM

Answer 1

Thank you Sam and also Kaushal for searching
This describes exactly what we were looking for and the manual load / merge was also the intention using the file as the "master" to maintain and not make changes within the application.
Thanks again. I will try it out.
Cheers,
Julius