1 of 1 people found this helpful
The traditional way of doing this is via ACL Templates, using the "Replace" option to set new ACL's on the objects. This can certainly be done via a script, but you might like to try working with the process manually to start with.
The process would be something like this:
- DEV role creates the package, with their default ACL Template
- Once the package is ready for QA, someone in the DEV role applies an ACL Template called something like "Promote to QA", which opens up the object to the QA role, and makes it read only to DEV
- Someone from the QA role can now choose to either apply a "Release to PROD" or "Demote to DEV" ACL Template, depending on the outcome of their testing and/or your internal processes.
- If it's now released to PROD, then the PROD role will have the rights to deploy the package to production and other roles will have either read only or perhaps even no rights to the relevant objects
If I was doing this myself, I would consider using a folder structure - something like Dev, QA and Prod, and have write access to the QA folder for people in DEV, so that they can move packages there before applying the ACL Template, and a similar construct for Prod. This will keep the packages physically separate.
If you find that this solution is working, you can still look at writing a simple NSH script to do it for you and in doing so (and through the use of an execution override) you could even tighten down the ACL's further.
Does that help?
Hello Jhon, thanks for your answer.
Usually i work with ACl Policy so i forget using ACL Template functionality.
Your process seems very interesting.
This means that when i want to promote from DEV to QA, i just have to move to the QA directory (package + job if needed), then replace hte Acl Template permission on the top of the directory QA (so i'm really sure that all objetcs under the QA directory have the same rights).
I prefer to create small scripts (promoteToQA for exemple) because i don't want user have to manage rights.
i've seen it done where the promotion happens as another role, where that role only has acl modify on the objects - dev does something to say something needs to be promoted, and then the promoter gets it to QA so they can deploy it, then the same to prod. once the pkg is out of dev, no write/modify access to the object for anyone other than the qa promoters.