Community
Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

SECATT, SCAT & S_DEVELOP AUTHORITY CHECK

Former Member

‎2015 Jun 17 9:18 PM

0 Likes
907


Hello.

After consulting  this discussion forum still it is an  unresolved issue,  for many years,  the authority check of S_DEVELOP  fieldname OBJNAME = *;  every time when the SCAT or SECATT transactions are used.

I do not know if this issue has been under consideration by  SAP developers  team , but It is a fact that nothing can be done to allow defining  the field value  of the fieldname OBJNAME with a corresponding name,  and be able to build  multiple authorization profiles  for specific processes.

 

I have not tried to solve it by changing the values allowed in the Object S_DEVELOP , fieldname OBJNAME  using  the transaction SU24, it would be interesting to know the opinion of experts. 

Thank you very much.

 

Best
Regards,


Hello.

After consulting  this discussion forum still it is an  unresolved issue,  for many years,  the authority check of S_DEVELOP  fieldname OBJNAME = *;  every time when the SCAT or SECATT transactions are used.

I do not know if this issue has been under consideration by  SAP developers  team , but It is a fact that nothing can be done to allow defining  the field value  of the fieldname OBJNAME with a corresponding name,  and be able to build  multiple authorization profiles  for specific processes.

 

I have not tried to solve it by changing the values allowed in the Object S_DEVELOP , fieldname OBJNAME  using  the transaction SU24, it would be interesting to know the opinion of experts. 

Thank you very much.

 

Best
Regards,

Reply
3 REPLIES 3
Read only

mvoros
Active Contributor

‎2015 Jun 18 9:56 AM

0 Likes
785

Hi,

it seems like a bug in SAP. Check note  1710350. It seems to be describing and fixing same issue. Originally, the check is for '*'' and OSS note changes it to DUMMY. Do you know where exactly is the check being executed?

Cheers

Read only

Former Member
In response to mvoros

‎2015 Jun 19 12:48 AM

0 Likes
785

Hello Martin.

Definitely the SAP note implementation solves the authority check incident. CAT_PING Function Module and AUTHORITY-CHECK statements for the OBJNAME followed with DUMMY is flawlessly working as a wildcard entry. 

I was in debug mode and find out that the authority check is being executed for transaction SECATT thru ABAP program: SAPLECATT_MAIN , it makes a dynamic call to SAPLECATT_EXECUTE at  include LECATT_EXECUTEI03; MODULE ecatt_execute_active_tab_get, this is the moment when CAT_PING function module is invoked.  I will keep investigating the exact point because the function module is not explicitly called.


I appreciate this valuable information.

Best regards,


Read only

mvoros
Active Contributor
In response to mvoros

‎2015 Jun 19 7:59 AM

0 Likes
785

Hi,

I don't have access to a system at this moment so I can't check it but it seems to me that SAP made a mistake. The logic should be that it checks that you have an authorization for at least one object. This can be done with DUMMY but it was coded with * which checks if you have authorization for all objects. That's why I was asking if you can see the exact code where it is being checked. You can easily navigate to code from ST01 when you have a trace. If you believe this is the case then I would suggest raising a message with SAP to fix it.

Cheers