S_DEVELOP

[Former Member]

Hy Gurus,

For any endures Tcode mb51 tcode showing authorization issue.

In Su53 screen shot is this.

Authorization Object S_DEVELOP

Activity 03

Package <dummy>

Object name <dummy>

Object type DEBUG

Authorization group ABAP/ program <dummy>

why S_DEVELOP object is required for end user.

Best Regards

Dilip Pasila

[jurjen_heeck]

I've seen this on several occasions where a short dump was about to occur. When I gave this object the dump actually came in view. Do you have ST22 entries around the same time?

[sdipanjan]

No issues with the demanding values and also S_DEVELOP is proposed by SAP as a Check object for MB51. But, to be aware of the action the user is trying to perform, please study the SM20 & ST01 results. So that you can get the confirmation of proper usage of data through permitted actions.

Regards,

Dipanjan

[Former Member]

This is a check to determine which screen the system should use. It that point, the system does not yet know (or care) what the name of the program is which is dumping.

The result of this check determines whether or not the little "Debug program" button is visible or not.

End users do not need ST22 nor SM51... and not the ability to debug their (your) program errors on their own.

See for more infos and test it with a trace on. You will find the source code location of the check; again only if authorized to display the coding but you can still trace without it.

Cheers,

Julius

[former_member182098]

Hello,

Yesterday, we got similar issue. The SU53 screen shot shown exactly the same for the transaction code FK15.

Whereas the SAP note says that

SAP Note 4092

The user input (field P_ACTION) BTCSUBMIT is missing in

authorization object S_PROGRAM.

We have given this and it solved our issue.

Regards,

Ravi

[Former Member]

Hi,

As my experience auth object S_Develop will not give the end users in production system and even IT users also not used in production system this is for only development systems.

BR,

Biksham

[Former Member]

I completely agree with Biksham, and that is also not a reason to not check the authority.

DEBUG authority is checked in a number of places (also "external debugging") and not just "/H" etc.

Just because an authority-check turns up in a trace (or even a short dump in extreme cases), is no reason on it's own to add the access. In this case it is pretty clear because of the DUMMY constructs that it is such a "plausibility" or "visibility" check.

Cheers,

Julius

Edited by: Julius Bussche on Jun 11, 2009 11:14 PM

[former_member701183]

Hi,

The su53 in this case is giving a wrong out put. There may be may cases for this wrong out put viz.

1. User giving wrong su53.

2. Input values after running the transaction are wrong.

3. Even the parameter fields of the user may be wrong.

Finding out the solution

1. Run Trace st01.

2. Simulate the same in quality. Create one id in another system eg quality and copy the user roles and not parameters. Run the same with trace on.

3. Check with functional guys whether user giving right input after running the transaction.

I am sure it will help you to find the solution. s_develop I guess is an erroneous result. Let me know if you face any problem.

Regards

Aveek.

[Former Member]

Another possibility which occured to me (because I just found one of these) is that there is some custom coding activated in an exit, and the developer "forgot" a BREAKPOINT in the code.

This will also make the check you are seeing before attaching the debugger session, and explain the SU53 result.

Try to check that: search the coding for "BREAK-POINT" or "BREAK-USER" where "USER" is the name of the user ID.

Cheers,

Julius