Application Development 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
Showing results for 
Search instead for 
Did you mean: 

SCC4 & SCC1

Former Member
0 Kudos

hi all, i am building a role for functional consultanat and i want to know how can i restrict the transaction SCC4 to display only and still allow full authorization to transaction SCC1?

11 REPLIES 11

Former Member
0 Kudos

There are few options:

1.If you plan to restrict SCC4 tcode with display access to every user in the system, In SU24 tcode you need to restrict S_TABU_DIS auth. object ACTVT field to value 03 only.

2.Else if you plan to restrict the access at role level, you should be able to achieve by changing the ACTVT field value of auth. object S_TABU_DIS to 03 for auth. group to SS.

3.You may try the option to change the auth group for the table related to tcode SCC4 - T000 to a custom auth group as given in the below thread related thread:

3rd option should solve your query. You may test the option to derive if it solves your requirement.

Former Member
0 Kudos

You could possibly leave the SCC4 settings open for client copy, and then give the SCC1 users more access for the profiles being copied (SCC1 makes more checks) but no S_TABU_DIS for "modify" of T000's auth group (as per the first answer, by isolating it into a protected group of it's own).

You might want to check the Service Market Place as well for ways to tweak this, as I remember some changes to the maintenance views and the ability to distinguish between the activities permitted on the fields of the table.

Cheers,

Julius

0 Kudos

Restricting SCC4 to Display only and at the same time, providing full authorization to SCC1 seems to be not possible as both the transactions carries same Authorization Object i.e - S_TABU_DIS and if we restrict this auth object to Display only will not allow SCC1 to work.

But will surely be awaiting more comments from our Experts...

0 Kudos

S_TABU_DIS is a table grouping concept.

My understanding of what has been suggested above is to move T000 out of it's default group and into one of it's own using SE54. I am pretty sure that you can restrict to the client copy option this way.

Which release and SP level are you on?

Cheers,

Julius

0 Kudos

iam using ERP 6.0 with SPS 17, how can i remove the table T000 from its authorization group and add it to another one?

0 Kudos

ok do anyone know how to create a role that prevent special transaction from opening and allow all the other transactions?

0 Kudos

> iam using ERP 6.0 with SPS 17

Then you can also implement the options mentioned in [SAP Note 1047952|https://service.sap.com/sap/support/notes/1047952] and control the authority using object S_CTS_ADMI. You might not want to control CCCOPYLOCK_VAL_DEFAULT though. You will need an ABAPer (one who knows a little bit about Badi's and OO programming) for this.

> how can i remove the table T000 from its authorization group and add it to another one?

You can do this using transaction SE54, to isolate it from the other tables in the same group. However if you implement the above note, then this may no longer be necessary as long as the user has the correct authority.

Cheers,

Julius

0 Kudos

ifi implement this note and i restrict SCC4 to display only, i will not be able to make any customizing in the client which i need to do, anyway i got an idea:

1- go to transaction sm01 and lock transaction scc4 in it.

2- restrict logon transaction sm01

now the functional consultant can use transaction SCC1 and cannot use SCC4.

0 Kudos

Aha !! you locked the transaction code itself ... "SCC4".

Rather than locking it and restricting everyone's access to this tcode, why don't you "not assign" the transaction code SCC4 to the functional consultant, if you are only concerned about functional people running it.

By the way, even if you don't given access to transaction code SCC4, a programmer can easily update the table T000 programmatically ( if you have not protected the table)

Cheers !!

Zaheer

0 Kudos

> ifi implement this note and i restrict SCC4 to display only, i will not be able to make any customizing in the client which i need to do,

The note I mentioned will help you to determine yourself which fields are editable only if the user has additional authority for S_CTS_ADMI..

The other restrictions such as S_TABU_DIS will still apply as before, except additional access is required for the fields in the BADI.

> anyway i got an idea:

> 1- go to transaction sm01 and lock transaction scc4 in it.

> 2- restrict logon transaction sm01

> now the functional consultant can use transaction SCC1 and cannot use SCC4.

In that case no one can use SCC4, and if they can use it anyway... then obviously they all can anyway...

Bad idea. Can look good in a .ppt presentation though...

Cheers,

Julius

0 Kudos

> By the way, even if you don't given access to transaction code SCC4, a programmer can easily update the table T000 programmatically ( if you have not protected the table)

Protecting the table in this way will not help against a programmer. They could anyway update their own authority first (to pass the protection).

There is a certain point though, at which good training and possible consequences for ill thought out actions takes over. That does however not apply to the hordes of end users and .ppt programmers, who will also be more inclined to take some less carefull chances because they are not trained to know better.

If an end user accidentally deletes your productive client, then that is no reason to be angry at them ...

Cheers,

Julius