This website is not affiliated with, sponsored by, or approved by SAP AG.

C_STUE_WRK fail

SAP Security

Moderators: Snowy, thx4allthefish, jurjen

C_STUE_WRK fail

Postby thx4allthefish » Wed Jun 22, 2011 12:53 am

Hi all,

I have some eerie issue with C_STUE_WRK. Whilst the user has the following authorisations with this object:

ACTVT 03
CSWRK 1000,2010

when running CS11 we're always getting the error: not authorised blah blah, with the SU53 showing in missing objects

C_STUE_WRK
ACTVT 03
CSWRK 2010

and in objects available: exactly the same!

I have been running a trace (ST01), it comes back with a returncode 4 on C_STUE_WRK, 03,2010. I checked the role - it's active generated and present in the user-buffer.

The trace doesn't hint at any murky user-exit or anything. Checking SMP notes revealed a couple of notes like 656868 describing the just the other way round of what I need, nothing else came up.

Anybody any ideas? Ever run into this? Oh, and this is ERP 5.0, NW640/SP1 (yes, it's ancient).
curiousorange wrote:I give up. Humanity isn't worth saving. Why is there never a Vogon Constructor Fleet around when you really need one?
thx4allthefish
 
Posts: 5694
Joined: Sat Oct 26, 2002 6:18 pm
Location: barolo barrel

Re: C_STUE_WRK fail

Postby Al. » Wed Jun 22, 2011 5:52 am

Hi,

I've seen something similar in a WM auth object a while back. If I remember correctly it was a bug in the coding for the auth-check on the activity and the only way around it was *. That doesn't explain why there is a RC4 when the auths are buffered though.

Is this repeatable in a non-prod environment? if you have a role with only C_STUE_WRK 03/2010 (so not including the 1000 plant) does it still fail?
http://www.turnkeyconsulting.com/
Al.
 
Posts: 3049
Joined: Tue Feb 25, 2003 5:35 am
Location: London

Re: C_STUE_WRK fail

Postby thx4allthefish » Wed Jun 22, 2011 7:12 am

Al. wrote:Hi,

I've seen something similar in a WM auth object a while back. If I remember correctly it was a bug in the coding for the auth-check on the activity and the only way around it was *. That doesn't explain why there is a RC4 when the auths are buffered though.

Is this repeatable in a non-prod environment? if you have a role with only C_STUE_WRK 03/2010 (so not including the 1000 plant) does it still fail?


I'm quite the lucky chick - it's reproducible (word?) in every system in that particular landscape. And yes, it throws the same error when the object only has 2010 for CSWRK. I don't trust myself, so I double-checked on UST12 and USBRF2 again. Everything is, as it should be.

Le Sigh.

Next step: debugging MC29LIE1.
curiousorange wrote:I give up. Humanity isn't worth saving. Why is there never a Vogon Constructor Fleet around when you really need one?
thx4allthefish
 
Posts: 5694
Joined: Sat Oct 26, 2002 6:18 pm
Location: barolo barrel

Re: C_STUE_WRK fail

Postby Al. » Wed Jun 22, 2011 8:06 am

thx4allthefish wrote:
Next step: debugging MC29LIE1.


Bonne chance !
http://www.turnkeyconsulting.com/
Al.
 
Posts: 3049
Joined: Tue Feb 25, 2003 5:35 am
Location: London

Re: C_STUE_WRK fail

Postby thx4allthefish » Wed Jun 22, 2011 10:19 am

Allright. *throws arms into the air* I give up.

I added a debug-authorisation (just a role with object s_program, debug, all activities) to the userID in question and went on my merry way to debugging in the QA-system. There are only 3 parts in MC29LIE1 concerning said object. I passed the first, everything o.k. - at the second it was asking specifically for CSWRK = ' ' (two blanks!! two!). This is where the RC=4 comes from. This should be reset as soon as I come to the third auth-check. But it isn't!! The third bit is passed with everything o.k., but the returncode stays on!

So, this dumb thing is asking me to give authorisation to CSWKR = blankblank. That's downright BS. I went in search of notes again, but either I have lost all my skills at google-fu or there simply isn't any note. The interesting bit: if I replace 2010 and/or 1000 with '*' it passes, even though I should have a blankblank in there. But then, I'm no abapper, so maybe I missed something there ...

This cannot be - hundreds of thousands of people must have experienced said error!But there's nothing on SDN or SMP or someplace else ... how can that be?

How am I to authorise blankblank when there is a table behind the field that checks on valid entries?

I'm going to insert blankblank using SE16N to have a workaround and open a call with SAP for a proper solution.
curiousorange wrote:I give up. Humanity isn't worth saving. Why is there never a Vogon Constructor Fleet around when you really need one?
thx4allthefish
 
Posts: 5694
Joined: Sat Oct 26, 2002 6:18 pm
Location: barolo barrel

Re: C_STUE_WRK fail

Postby Al. » Thu Jun 23, 2011 1:07 am

I'm glad you found the root cause, definitely sounds like a fix for SAP to implement. What was the transaction? As you said, I would have expected more people to have picked this up. It's not like full auths are usually granted for stuff with BOM's (assume that's what it is?).
http://www.turnkeyconsulting.com/
Al.
 
Posts: 3049
Joined: Tue Feb 25, 2003 5:35 am
Location: London

Re: C_STUE_WRK fail

Postby henrik » Thu Jun 23, 2011 4:39 pm

I've seen this problem before, and the only way around it - except table hacking and code change - is to assign *. Not an ideal, or for many people even possible solution.
It does happen in some of the "old" transactions. Thought most of it had been cleaned up by now...
www.turnkeyconsulting.com.au
henrik
 
Posts: 493
Joined: Wed Oct 23, 2002 6:38 am
Location: London, UK

Re: C_STUE_WRK fail

Postby Sharpshooter » Fri Jun 24, 2011 7:09 am

I ran into this years ago with object C_DRAW_TCD. I could not create a role with 'space' as the document type because it was validated, but I was able to create a profile the old way in SU02 with the space value in DOKAR.
This was on a 3.x system so I have no idea if it is still possible - I have no access to SUxx transactions on my current gig.
Good luck!
Sharpshooter
 
Posts: 1171
Joined: Wed Mar 17, 2010 12:01 pm
Location: In the dark

Re: C_STUE_WRK fail

Postby thx4allthefish » Mon Jun 27, 2011 1:28 am

Yes, it's in one of the 'old' transactions, CS11-13. No, it hasn't been cleaned up.

I have been testing this on a ERP 6.0 SR3 (quite new!), same shit, different day.

So, it's one of both: nobody else but me has the challenge to keep BOMs of one plant out of the sight (and the hands) of people of the other plant(s) (exception: CO, they have to look at the calculation data of combinations of plants)!!

How likely is that?

Or are people just not talking, simply hack tables or modify code to avoid the subject?

Opened call at SMP. Will come back with news (if there are any).
curiousorange wrote:I give up. Humanity isn't worth saving. Why is there never a Vogon Constructor Fleet around when you really need one?
thx4allthefish
 
Posts: 5694
Joined: Sat Oct 26, 2002 6:18 pm
Location: barolo barrel


Return to SAP Security

Who is online

Users browsing this forum: No registered users and 2 guests





This website is not affiliated with, sponsored by, or approved by SAP AG.