RE: Client Not Modifiable for Z Tables

[sreekanth_sunkara]

Hi all,

One of our developer created 3 custom Ztables, when he is testing in testing environment, he is able to modify 2 of them using SM30, but for one table it says "Client status not modifiable". i checked his profile and he got access to SM30 and also to S_TABU_CLI--> Allowed (X).

I dont know why it is not allowing this table to change and allows other tables to change ( I dont think this is any thing wrong with his authorization)

I also checked in SE11 and his delivery class is type "A" like the other 2 tables.

what else i need to check?

thanks,

Sun

Edited by: sun on Nov 19, 2008 3:53 PM

[Former Member]

Sounds like the currect settings flag is missing for the one maintenance dialog.

See [SAP Note 522215|https://service.sap.com/sap/support/notes/522215] as well.

Cheers,

Julius

[sreekanth_sunkara]

Ok Julius,

I will have a look at this note, thanks for your help

thanks,

Sun

[Former Member]

If you display the customizing views from transaction SOBJ, you will see if there is a difference in the flag.

If so, then your developer probably forgot to set it, if that is what they intended to do with these tables.

Cheers,

Julius

[sreekanth_sunkara]

Hi Julius,

As you said we went in to Tcode SOBJ and changed catagery from CUST to APPL, but before doing this change our abap programmer went in to SE11 and changed the data class to APPL0 and transported.

I dont know the difference, but it worked even with out transporting the modification that we made in tcode SOBJ

thanks for your help

thanks,

Sun.

[Former Member]

There was a little bug in SOBJ a while ago which let you change the owner of the object in a development system without transporting. But that should be fixed - as it is simply not an option anymore, also in a production system.

The better (more transparent) option in my opinion is to use the current settings flag if these tables are going to serve a "customizing" type function of the application and you want the flexibility to change them system specifically within your landscape without having to transport it and not wanting to open the (productive or test) client just to make a change of something non-critical for the application.

But you need to pick and choose them carefully. There are also some other settings which you might want to tighten the control on - for example very application sensitive master data.

Now I don't know what these tables are used for, but you did mention S_TABU_CLI being required so they are even client independent (most likely)... at least as far as their maintenance is to be concerned.

As you are asking this in the security forum (and not the ABAP or Data Dictionary forums), you might want to review the technical design of this solution...

It is not unknown that the developer and customizing roles find their way to production and used there with reliance on the SCC4 client settings either, and as these are client dependent... what are the settings of the other clients and the authority of the users in them?

But that is up to you. Certainly training and experience helps as well (which includes learning the hard way

I prefer the current settings to the client settings where the "use case" is justified.

Cheers,

Julius

ps: The one table which could not be changed, was it being changed from a different client than the other two?

[sreekanth_sunkara]

Ok,

thanks for more information

thanks,

Slun

[former_member1061482]

Check client options in Tcode scc4. The "Cross Client Object Changes" option might be set to "No Changes to Cross Client Customizing Objects".

May be somebody would have changed this setting after he had modified the two tables.

Can he modify those two tables now? I may be wrong.. its just a guess!

[sreekanth_sunkara]

Hi,

thanks,

But we checked again and its not working, i will have a look at the Julius note

thanks,

Sun