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: 

Su24 maintenance for Custom tcode for standard Table Maintenance.

former_member721373
Participant
0 Kudos

Hello everyone,

I had a requirement where i had to create a tcode for the standard table maintenance.

I have created the maintenance view for that and tcode using sm30.

But I am confused with the next requirement which says:

" SU24 customizing and authorization related aspects not centrally managed by PSI within their own environment

  • Ensure IT is able to perform customizing in dev system with maintenance authorizations (in addition to display)
  • Changes to be changed in a customizing request
  • IT shall be able to display configuration in Qual and Prod system => No maintenance authorization"

Can anyone help me with this requirement? What exactly i need to do in SU24 as i have never worked on SU24 before.

Thanks in advance.

1 ACCEPTED SOLUTION

Colleen
Advisor
Advisor

Hi Mohd

It's a mixture of how you maintain the SU24 values for the different environment usage (development where you make the change versus other environments where you are only allowed to display the change)

SE11 TABLE DEFINITION

In this development, the table will be classified as to the type of table it is and whether changes can be made when client is open, etc. Security does not control the validation from client settings "changes not permitted..."

Basis is also involved in SCC1 client settings and SE03 transport/configuration settings to control how table is maintained outside of transports.

SE93 TRANSACTION DEFINITION

First up: Someone has created a parameter "Z" transaction for SM30 to the table you are granting access (let's call this ZTABLE_TCODE) The "Z" table belongs to an "Z" auth group (let's call this ZAUTHGRP)

SU24 MAINTENANCE

In SU24 you will need to add the transaction code ZTABLE_TCODE with the following values

S_TABU_DIS (option) --> leave ACTVT empty (do not choose 02 or 03) and end TDDAT group value as ZAUTHGRP

S_TABU_NAM (preferred) --> leave the ACTVT empty (do not choose 02 or 03) and enter ZTABLE as the table name (this way you only give out the exact table access value)

If table is client independent (i.e. cross client) then it will also need S_TABU_CLI = X but would maintain as a proposal to control at role level

Note: user would also require transport creation access in development but I wouldn't typically map that in SU24 as you will most likely grant SE01/SE09/SE10 access to a user as a separate transport role.

PFCG ROLE MAINTENANCE

2 Roles would be required

DEVELOPMENT role - add the ZTABLE_TOCDE to the role menu then chose complex/expert mode in Authorisation tab. SU24 values that you maintain will default. Choose ACTVT 02 and 03 for maintenance and display. You can disable S_TABU_DIS if you don't want to use auth group

QA Role - optional but you can have a different role with only the ACTVT 03 for display only. However, in QA system, the client/table settings will prevent the change any. Security would be an additional layer to prevent updates when client settings are changed.

Back to your requirements...

  • Ensure IT is able to perform customizing in dev system with maintenance authorizations (in addition to display) --> refer to steps on SU24 and PFCG development build
  • Changes to be changed in a customizing request --> refer to SE11 and client settings information for table definition
  • IT shall be able to display configuration in Qual and Prod system => No maintenance authorization" --> both client settings/table settings AND pfcg display role will achieve this

Good luck learning SU24 and PFCG maintenance.

Remember: the goal of SU24 is to help consistently build security roles without authorisations gaps. It relies on the administrator to update the mappings to facilitate the automations in PFCG.

When you maintain SU24 have a think about the types of roles you need to build. Your goal is to avoid overwriting SU24 defaults (which causes the authorisation to become a "changed" status). When a transaction needs to be used in both a change/maintenance and a display version, you can leave ACTVT field empty in SU24 and maintain at PFCG role build level.

Regards

Colleen

5 REPLIES 5

Colleen
Advisor
Advisor

Hi Mohd

It's a mixture of how you maintain the SU24 values for the different environment usage (development where you make the change versus other environments where you are only allowed to display the change)

SE11 TABLE DEFINITION

In this development, the table will be classified as to the type of table it is and whether changes can be made when client is open, etc. Security does not control the validation from client settings "changes not permitted..."

Basis is also involved in SCC1 client settings and SE03 transport/configuration settings to control how table is maintained outside of transports.

SE93 TRANSACTION DEFINITION

First up: Someone has created a parameter "Z" transaction for SM30 to the table you are granting access (let's call this ZTABLE_TCODE) The "Z" table belongs to an "Z" auth group (let's call this ZAUTHGRP)

SU24 MAINTENANCE

In SU24 you will need to add the transaction code ZTABLE_TCODE with the following values

S_TABU_DIS (option) --> leave ACTVT empty (do not choose 02 or 03) and end TDDAT group value as ZAUTHGRP

S_TABU_NAM (preferred) --> leave the ACTVT empty (do not choose 02 or 03) and enter ZTABLE as the table name (this way you only give out the exact table access value)

If table is client independent (i.e. cross client) then it will also need S_TABU_CLI = X but would maintain as a proposal to control at role level

Note: user would also require transport creation access in development but I wouldn't typically map that in SU24 as you will most likely grant SE01/SE09/SE10 access to a user as a separate transport role.

PFCG ROLE MAINTENANCE

2 Roles would be required

DEVELOPMENT role - add the ZTABLE_TOCDE to the role menu then chose complex/expert mode in Authorisation tab. SU24 values that you maintain will default. Choose ACTVT 02 and 03 for maintenance and display. You can disable S_TABU_DIS if you don't want to use auth group

QA Role - optional but you can have a different role with only the ACTVT 03 for display only. However, in QA system, the client/table settings will prevent the change any. Security would be an additional layer to prevent updates when client settings are changed.

Back to your requirements...

  • Ensure IT is able to perform customizing in dev system with maintenance authorizations (in addition to display) --> refer to steps on SU24 and PFCG development build
  • Changes to be changed in a customizing request --> refer to SE11 and client settings information for table definition
  • IT shall be able to display configuration in Qual and Prod system => No maintenance authorization" --> both client settings/table settings AND pfcg display role will achieve this

Good luck learning SU24 and PFCG maintenance.

Remember: the goal of SU24 is to help consistently build security roles without authorisations gaps. It relies on the administrator to update the mappings to facilitate the automations in PFCG.

When you maintain SU24 have a think about the types of roles you need to build. Your goal is to avoid overwriting SU24 defaults (which causes the authorisation to become a "changed" status). When a transaction needs to be used in both a change/maintenance and a display version, you can leave ACTVT field empty in SU24 and maintain at PFCG role build level.

Regards

Colleen

0 Kudos

Thank you so much Colleen 🙂
So this is what i understood:
1. I need to create a custom Authorization group and assign that in the Table maintenance group field.
2. In Su24, i need to maintain as you mentioned in your answer.
3. Then ask the security team/ basis team to do the PFCG part.

Also the standard table i am working on is 'C' type, so i have kept the Maintenance view also as 'C' type. Is this how it's supposed to be right?

perhaps have a look at this old blog.. there seems to be a series of them if you search (blog comments mentions a part 4)

https://blogs.sap.com/2010/01/11/getting-the-basics-right-creating-the-perfect-config-table-part-1-t...

The custom auth group is to stop is from ending us a &NC& - not classified. So as much as you are trying to restrict access to the table, if a security role has S_TABU_DIS &NC& to it, then users will get access to your new table. Put it in an auth group but still try to get security to use S_TABU_NAM

If you are the developer, discuss with security team as a lot of the times they maintain the SU24 mappings (well I do anyway 🙂 )

good luck with it!

0 Kudos

Thanks Colleen! 😁

I asked the security team and they hàve asked me to do this:

enter the following in the SU24:

S_TABU_NAM

ACTVT: (please leave blank)

TABLE : /COV/VIM_T852_V

But as i have never used SU24 before, I don't have an idea how i can do this.

Can you please provide me the stepwise ss how to achieve this for my tcode in su24.

Thank you so much in advance

0 Kudos

Hey - sounds like the security team is in alignment with the advise that I've been giving you

For SU24 - try to google the steps as SAP help documentation most likely has it. You will need a workbench transport request to save the changes in development

SAP Help example (may not be your current release but most likely steps are the same) https://help.sap.com/saphelp_nw73/helpdata/en/1e/ce3075dd4e4116b23e006552374ffc/content.htm?no_cache...

Happy to help guide you but in this specific case SU24 is > 20 years old as a concept. If you google you will find a wealth of knowledge out there including someone probably running a YouTube channel taking you step by step through it

Regards

Colleen