1 of 1 people found this helpful
The blcontent pack should upload examples of the acl templates you would need. Your objects start off with a dev template on them. When they are ready for QA, the dev person applies the QA template. The QA person then has access and can do one of two things, apply the prod template to send it to prod, or apply the dev template to send it back down.
That make sense?
Thanks, Adam. Yeah, I'm following all of that. I'll load the blcontent into my VM environment and take another look at that.
However, the part I'm having troubles wrapping my head around is how we incorporate the concept of individual workspaces into some form of ACL template/policy swapping.
Developers have a /Workspaces/Developers folder for jobs, depot, etc.
We'd like them to promote the package to QA, which includes:
- Altering the ACLs for the QA role (easy enough)
- Simultaneously move the object to the /Workspaces/QA folder ( Am I in NSH script land now?)
It's the concept of not only updating the ACLs, but also moving the package from one physical workspace directory to another. I can't seem to figure a way to simultaneously remove rights from one Role while moving the resource to another directory which the original Role wouldn't even have rights to access.
Well, you could make an nsh script job that does that, and set the "execution override" to always run as a BLAdmin. In the script you would add the QA template, then move it, then remove the Dev template.
Would that work?
you'd typically create roles like this:
Dev: create objects, maybe execute against dev servers only.
QA: run deploys against qa only
prod: run deploys against prod only
CM: change managers, modify acls on objects, possibly move them, no ability to modify object or deploy.
CM role moves the objects, maybe based on a property setting on the object. maybe you have a folder called promoted that dev has only write or create access into.