Restrict CHARM actions based on project type/name

[Former Member]

Hello all

We're looking to restrict the available actions in CHARM based on the project type and/or name.

For example, we'd like to restrict developers from releasing transports in project (maintenance cycles) starting with CI_*.

Obviously we are able to restrict over all actions using objects B_USERSTAT and /TMWFLOW/*.  Were were wondering if perhaps S_PROJECT, S_PROJECTS, or S_PROJ_GEN might provide us with the answer (though role stacking becomes an issue because they're not directly linked to the defined actions).

Does anyone know of a way to restrict ones ability to release transports (etc.) by the project type and/or name, while leaving those actions available for other project types/names?

Thanks for your help!

[mich_vollmer]

Hi Andrew,

some question first? Do you want to restrict ChaRM actions like 'COPY_ALL'  or PPF actions ? ANd are you using 7.0 or 7.1 Solman?

Best regards,

Michael

[Former Member]

Thanks for the replies!

Shaun - does this method work to restrict one group of users (say, the developers) from releasing transports while allowing another (say, release managers) to release?  The thinking is that we've many users working on multiple projects, but we only want them be able to release transports from certain ones.

Michael - We are using 7.0 currently (though there have been talks of eventually moving to 7.1 in the coming year). 

To clarify, one scenario is this: Our project developers need access to set 'consolidated' status on projects containing normal corrections.  Our support developers should not be able to set 'consolidated' status on certain projects.  The catch is that often times these developers work both on the project development and the support development.  Creating two roles with different access may not be an option, since the roles will be stacked on their accounts.

Thanks

[mich_vollmer]

Hi Andrews,

I had some thoughts about it. Currently it is not possible in SAP standard (as far as I see it).

The solution would mean development. You could implement a ChaRM condition which checks the project and bp/user for example and if it fails, it resets the status back to the source user status.

Or - as I understand - these are 2 types of developers which might belong to two different partner organizations, so you could implement a new autority object which checks the bp organization he belongs to. Maybe there already exists an authority object, here.

I will ask a colleague today, maybe there is another solution.

Best regards,

Michael

[Former Member]

Michael

The two user groups are currently part of separate internal organizations, though they will likely be merging in the future. 

I am in agreement with you in that it doesn't seem it is technically possible to restrict in this way unless we have some custom development done.  I'm not sure if our users accounts are defined to a specific organization.  What parameter might this be set in (assuming this is even possible)?

Thanks

[mich_vollmer]

Hi Andrew,

another way would be to implement a BAdI implementation for the PPF condition, for the schedule condition EVAL_SCHEDCOND_PPF. You could define a container attribute which is set to true in case the authority check is ok. Then the PPF condition is only available for execution for the relevant developers, the other developers don't see it, even,

best regards,

Michael

[mich_vollmer]

Hi Andrew,

question. How do the developers differentiate? That should be the criteria for the authority object you use. Maybe it's that some do not work in special system landscapes? Meaning logical components?

You could create a customer authority object and take as key the transaction type the user status and maybe the logical component. Or if it is really very differentiate, take the bp :-). Or user (with the project).

Best regards,

Michael

[shaun_kitching]

Hi Andrew,

There sure is.

You can do this by tinkering with the Project Switches.  Here, you can turn off the release of transports for the projects you want.

You can get to the switches several ways...but I find the best way is the following:

1. Login to satellite system which contains the projects (i.e. DR3100)

2. Access tcode SPRO_ADMIN

3. Choose a project and click view

4. Navigate to Transp. Requests tab

5. Click change icon

6. CTS Project Status Switch should now be open to click on

7. Click on this icon and choose All Configured transport targets

8. From here you can expand IMG projects and change which ones can have transports released

Good luck!

Shaun