09-26-2011 8:24 PM
Dear Experts,
Could you let me know whether do we still need to keep SE16 in SOD ruleset. With SAP Note 1420281, change access from SE16 is removed even if we have edit access for table auth group in S_TABU_DIS. Now it checks for SM30.
We have not assigned SM30 to business users. But change access for custom tables is present in business roles with SE16 access. Do you see this as a SOD issue if we exclude SE16 from the ruleset. Display access to tables is fine for our business and we don't have issue in providing display only access via SE16. But are there any other reasons to keep SE16 active in ruleset?
Thanks in advance!!!
09-26-2011 9:12 PM
The note relates to se16n in erp systems and not the basis transaction se16.
They are completely unrelated.
The only thing they have in common is that if the user has the correct authorizations for tables, then you have no real org. level control (it is the whole table..).
S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access.
If I were you, i would think about the design and create parameter transactions.
If they (business users) really must use SE16N, then use object S_TABU_NAM instead to control the access at table name level.
Cheers, Julius
09-26-2011 9:12 PM
The note relates to se16n in erp systems and not the basis transaction se16.
They are completely unrelated.
The only thing they have in common is that if the user has the correct authorizations for tables, then you have no real org. level control (it is the whole table..).
S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access.
If I were you, i would think about the design and create parameter transactions.
If they (business users) really must use SE16N, then use object S_TABU_NAM instead to control the access at table name level.
Cheers, Julius
10-03-2011 12:21 PM
If indeed SE16 is restricted to display then i would not include it ithe SoD filterset. As display in general does not cause / contribute to - a SoD conflict.
Julius remarked that
".. S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access. .. "
but we have S_TCODE as part of our SoD rule set, as the same object itself can be used in several transactions. For example V_VBAK_VKO is checked in several SD related transactions, without being only restricted for sales document maintenance. So if part of the SoD filterset is 'Maintain Sales Documents', we check not only for V_VBAK_VKO and V_VBAK_AAT but also for S_TCODE=VA01 or VA02.
Edited by: M. Coenjaerts on Oct 3, 2011 1:22 PM
10-03-2011 8:59 PM
Note that some transactions have "hand made" views to the data. If you double-click the record, you jump into the transaction screen.
Some make checks. Others dont.
Cheers,
Julius