You can set execution override but once you change the job that gets removed by design. for example – you setup the override to run the job as it is w/ one set of options. someone changes the options, because it’s running with different permissions the new options need to be approved to run at the different permission level.
Why does the job need to run as BLAdmins, what is it doing ?
We have a solution which Locks (with ACL) a package once its ready for Deployment (Automated). This is not Unlocked until someone need to re-package the same. This is done by BLAdmins only.
Requirement : By testing/checkout team
Solution: I have created a job, which can be used by testing team to Unlock, but they do not have BLAdmins permission to execute this.
This Job requires the Depot Object Name which changes everytime as per requirements. This is where they modify/update parameters in the Job, and while saving..execution override is removed.
Yes – as mentioned, by design. why can’t the testing team or whoever change the acls on the object themselves ?
This is what is being designed as per our solution so that no one can modify the package while its being deployed and its common for all Dev/QA/Prod.
The solution is executed using BMC Atrium Orchestrator who executes as BLAdmin.
If you are going to have to change the job between runs, why not have the users run a workflow job, which calls the bao workflow, which does the acl changes ?
My question here is, Can this be done using some Property/BLCLI/NSH which would allow the user to change the Job Parameter options without resetting the Execution Override?
I do not want to change the existing process how that is working..nor give additional permissions to the Testing team.
1 of 1 people found this helpful
If you change the job the execution override is removed.
Maybe the job can look at some property class values instead, and the users can change those ?
The job can read the values when it runs.