Restrict users from creating new Transport

[former_member461047]

Dear Experts,

We have a 4 tier landscape. Dev -> Test -> Quality -> Production.

First level of Testing is done in Test (Transport of Copies is sent to Test system).

The main TR (V1) is then relased to Quality so that the BA's perform further Tests. Since the TR is now released and imported to Quality the Objects are no longer locked in Dev.

We want to have a functionality where nobody should Lock their changes in a new TR(V2) until the previous version (V1) reaches Production. I should show an error message.

As an exception there should be access only to the Team Lead.

Any inputs / suggestions / solutions from you all will help me a lot.

-

Thanks and Best Regards,

Naresh

[srikanthnalluri]

You can set the system status as "No changes allowed" in the transaction code SCC4 and once TR reaches production you can change it.

It may not completely solve your problem, as with this option No one can make any changes.

[ArthurParisius]

That is not usable since that would lock the system for all changes, not for specific objects which is his question. The only thing I can think of is only allowing specific users to create transports and before they create a new transport the requester would need to indicate which objects they expect to change. The one that can create the transport would than need to check if any aren't locked in any other transports. It would introduce a lot of administrative steps though, also how would you deal with bugs found during testing that would need to be fixed before everything is allowed to move to the production environment?

[former_member461047]

Hi Nalluri,

Thanks for the reply but we do not want to block the complete Dev system. We only want to lock the objects that have reached quality.

-

Best Regards,

Naresh

[matt]

1. Change your process so that transports don't get released until the whole thing is ready to go to production. ToC changes through the landscape to Q, stopping short of P.

You can restrict the actions allowed by developers, so that only the team lead can change transport ownership or add another task. The team lead should release the tasks, but leave the transport open, so that the objects remain locked. That way, no-one except the team lead can change the transport, and no-one can change the locked objects. When it's time to go to P, release the transport and move that all the way to P.

2. On release of a transport, the team lead immediately creates a new transport with the same objects, but with only a task for himself, that contains all the objects of the released transport and locks them.When the main tp goes into production, the team lead then unlocks all the objects and deletes his locking transport. You could easily write programs to automate this.

[former_member461047]

Hey Matthew,

We actually proposed the first point that you have mentioned and our client straightway rejected the proposal.

They say that we have to come up with a solution to display an error message if somebody else tries to edit the Object, because this inturn leads to a new version. I know it is tricky but we not able to convince them.

Example Scenario:

1. User ABC has fixed a bug and released the TR. (TR now resides in Quality)
2. BA tests the functionality and reopens the Ticket because the issue still persists.

3. Now only user ABC should be authorized to edit this object because it was locked under his name and only under special conditions (like a Team Lead) who has privledges to edit and save in his TR. Other users namely XYZ, MNO etc are not authorized to work on this object unless ABC fixes the issue and reaches Production.

-

Best Regards,

Naresh

[former_member461047]

Hello Everyone,

I was able to implement my code within Method GET_CURRENT_PROJECT of BADI CTS_CURRENT_PROJECT. On this note I will be closing this ticket and thanks a lot.

-

Thanks and Best Regards,

Naresh