Currently the way access control works for shared objects is that whatever permisisons your role has, you have the same permissions on anything shared to you. So, if you're sharing to someone, be aware of what permissions they have and what you're sharing.
Generally we set up workflow so that you share the job, not the original package or script. That way development has control over what gets deployed, and makes parameters available to the people doing the execution.
It is a good idea to set up a shared folder and a backup folder, in case you're worried about someone messing with something you've shared.
Sharing is eventually going to change in Config Manager. I'm not one who can elaborate on it right now, but I know in the future you'll have much more control over the objects you share and permissions people have on them.
As an addendum, the sharing model is changing in BL's next major release, due out in (I believe) March or April next year. At that point, the permissions one gets on a shared object will be manageable on a per-object basis rather than a per-role basis.
In the meantime, I would follow Greg's advice.
Ok, thanks for the info.
In the Lotus release next year, there is not a separate folder structure for shared objects (e.g. Depot and Shared Depot). Instead, folders and objects have access control lists (ACLs) that grant permissions to specific Roles on a per-object basis. "Sharing" an object would be done by granting a different role access to Read, Update and/or Delete an object or folder.
Generally we set up workflow so that you share the
job, not the original package or script. That way
development has control over what gets deployed, and
makes parameters available to the people doing the
I've tried sharing the job, but the problem with this is that the output from each job is also shared, as you cannot change where the job output goes. So if one Solaris client installs Apache and runs a Patch Check Analysis, the output is shared with all Solaris clients sharing those jobs. This isn't going to be acceptable to most clients.
Do you know if this will also be covered in the next release?
Is there currently (6.3.2 or 6.3.3) a way around this without creating duplicate jobs for every package or script I want to share?
I encounted similiar issue under : https://www.bladelogic.com/community/thread.jspa?threadID=860&tstart=0 which I ultimately raised a call against (9110). As one of the chaps on here has mentioned, there is a future release which is due out which addresses some of these functions.
If you're concerned about job run logs being seen by people of various roles, then you will want to create a different share for each role. Currently there is no way to control who sees job runs, as we assume if you share the job with a role then you also want to share the history of that job.