Skip to Content
avatar image
-1
Former Member

Can a user with access to SE38 & SE80 make changes to programs or objects?

my audit is asking me to remove users (developers in DEV environment) with access to SE38 and SE80. The client is closed (no changes allowed) and they don't have the developer key or DEVACCESS.

Can they create, modify or delete programs, objects etc. using these t-code based on the above scenario?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

6 Answers

  • Best Answer
    avatar image
    Former Member
    Jan 26 at 12:14 AM
    -1

    If you want to change any programs or objects, the below conditions need to met.

    1. Users should have access on S_Develop activity 01 and 02 and other fields and field values as per requirement

    2. Those users (mainly abap developers) should have developer key

    3. The client should be opened for cross client changes as these programs and objects are cross client objects.

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 23 at 06:17 AM

    In order to support prod, developers must have these transactions. However, the auditors often feel that it's safe to remove them - a sort of belts and braces approach. They reason that if these tx are removed, then should the system be opened, no-one will be able to make changes directly in prod. What you should do is ensure the support developers' roles do not allow change or create access within S_DEVELOP. Blocking transactions is wrong.

    I've seen this before with auditors. They've locked SE80 and SE38. But SE24 is still available, which gives you all the access you need... ;-)

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 23 at 08:49 AM

    I see several mentions of DEVACCESS and/or developer keys. This isn't required anymore in S/4HANA.

    S_DEVELOP authorizations are the only proper way of securing this, as Matthew stated in earlier comment.

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 23 at 04:09 PM

    Jurjen appears to be correct re: that a developer key is no longer required for maintenance of development objects in S/4HANA, as it is in SAP Business Suite systems like ECC, SRM, CRM, etc. I corroborated this in a Sandbox system, and also found supporting SAP note:

    • SAP Note 2309060 - The SSCR license key procedure is not supported in SAP S/4 HANA

    This also appears to similarly apply to object keys in S/4HANA, which are issued for standard SAP developed repository objects delivered in SAP Business Suite systems like ECC as an additional prerequisite that would be required in order to maintain such objects.

    Aftab - as a few mentioned above, there are still several conditions which must be simultaneously met in order for changes like those referenced in your original question to be permitted (though there was a few considerations which are not yet mentioned above that I include in the detail below). However, your original question specifically referenced "programs and objects". While we know programs are repository objects and thus cross-client by nature, when discussing the changeability of "objects", it is important to distinguish between client-independent and client-dependent customizing objects:

    Changeability Requirements for Client-Independent Customizing and Repository Objects

    User-Specific Requirements

    • User is authorized for changes to cross-client customizing or repository objects, depending on the change being made (i.e., authorization requirements will slightly vary depending on how the change is initiated and what exactly is being changed, but generally requires S_TABU_DIS / S_TABU_NAM / S_TABU_CLI authorizations at a minimum for client independent customizing objects, or S_DEVELOP / S_TRANSPRT authorizations at a minimum for repository objects)
    • For certain custom repository object maintenance activities (e.g., creation / change of custom ABAP programs), the User must have a registered developer key issued by SAP for their specific user master record (i.e., table DEVACCESS), as applicable to respective system according to installation number (note: as confirmed above, this requirement only applies to SAP Business Suite systems like ECC, but is not required for S/4HANA)*

    Client and System-Specific Requirements

    • Client protection for cross-client customizing objects (i.e., table T000, field CCNOCLIIND) is set to '1' (No changes to cross-client customizing objects, but changes to repository objects allowed), '2' (No changes to repository objects, but changes to cross-client customizing objects allowed), or blank (Changes to both cross-client customizing and repository objects allowed), depending on the change being made
    • System Change Option set through SE03 / SE06 (i.e., table TADIR, field PGMID = HEAD, field OBJECT = SYST) is set to 'Modifiable' (TADIR-EDTFLAG = 'X')**
    • For certain standard repository object maintenance activities (e.g., changes to standard ABAP programs), the object being changed must have a registered object key issued by SAP for the specific repository object (i.e., table ADIRACCESS). (Note: as confirmed above, this requirement only applies to SAP Business Suite systems like ECC, but is not required for S/4HANA)*

    *For SAP Business Suite systems where SSCR keys are applicable, note that certain repository object maintenance activities such as creation / change of ABAP programs require the user making the change to have a developer key (and potentially an object key, if the program is standard), while other repository object maintenance activities such as data dictionary changes to a table's technical settings (e.g., table logging flag in SE13) do not require a developer / object key.

    **Note that the System Change Option also includes modifiability settings by software component and namespace as well. Each of these dimensions as they relate to the object being changed need to be set to 'Modifiable' in order for the "System Change Option" changeability condition to be met (i.e., even if the global System Change Option is set to 'Modifiable', if the Software Component and / or Namespace corresponding to the object being changed is set to 'Not Modifiable', SAP will not allow the change - see the following link for additional detail: https://help.sap.com/viewer/4a368c163b08418890a406d413933ba7/7.5.5/en-US/5738de9b4eb711d182bf0000e829fbfe.html)

    Changeability Requirements for Client-Dependent Customizing Objects

    User-Specific Requirements

    • User is authorized for changes to client-dependent customizing objects (i.e., authorization requirements will slightly vary depending on how the change is initiated and what exactly is being changed, but generally requires S_TABU_DIS / S_TABU_NAM authorizations at a minimum, and S_TRANSPRT authorizations if a transport request is simultaneously created as a record of the change, which is not necessarily required depending on the corresponding setting in table T000 as noted below)

    Client-Specific Requirements

    • Protection for client-dependent customizing objects (i.e., table T000, field CCCORACTIV) is set to '1' (Automatically record changes in transport request), '3' (Allow change, transport request cannot be generated), or blank (Allow change, transport request possible but not required)

    *Note that the System Change Option described above does not apply to client-dependent customizing objects. Also, keep in mind that client-dependent customizing objects which belong to "Current Settings" (i.e., table OBJH, field CURSETTING set to 'X') can be changed in clients with the Productive role (i.e., table T000, field CCCATEGORY set to "P") by authorized users, irrespective of the CCCORACTIV protection settings noted above (i.e., can be changed by authorized users even with T000-CCCORACTIVE = '2' for "No changes allowed.").

    Hope this helps!

    Josh

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 23 at 12:19 AM
    -1

    SE38 and SE80 can have different kind of access View, Run reports and make changes

    by default if its not restricted for the users everyone has access to view things in Se38 and Se80 if you have a developer access key assigned to your User Id in the system you can change all objects with Z* and Y*

    Let me know if that answers your question.


    Regards

    Vinita

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Vinita Kasliwal

      Hi Aftab,

      Basically it's a process to check the database consistency I was part of EWM project where they use to take audit process for the warehouse and checks all the details from the materials present in the warehouse to how much are in replenishment area and how much has been processed.

      Lets say while checking the database someone creates an outbound delivery so the entire data for the material will be revised which will be far different from what auditors are expecting.

      So that's why we try to remove all developer access authorizations during audit process and as Vinita said we follow the same process which she mentioned above.

      Thanks,

      Madhur.

  • Jan 22 at 10:39 PM

    they don't have the developer key

    Then they will not be able to create/edit/delete development objects like programs etc.

    Add comment
    10|10000 characters needed characters exceeded