Locking down an Asset
Hi,
I am trying to understand if it is possible to lock down an Asset when it reaches a certain state. What I mean by lockdown is not allowing changes to the attributes, relationships or artefacts. We do however want to be able to progress from one state to another. We have an Asset Type called Release that represents a release. There is also an associated lifecycle. The lifecycle has a start state of draft. In this state we want to be able to make changes to all of the asset parts, i.e. relationships, attributes, etc. Then when we are happy that the asset is correct we move to the next state, submitted. It is at this point that we do not want to allow any more changes to the asset, other than the ability to move it onto the next state, accepted. It would seem that a policy would be the best way to accomplish this. However, there does not appear to be any out of the box policy that gives us this capability. Is using a policy the best approach and if so is there already a policy that gives me this ability? If there is no out of the box policy then would writing a custom policy allow me to achieve our goals? Thanks for your help Des Drury |
14 answers
We added the ability to do this in RAM 7.5. As an administrator, go to the community and edit the lifecycle. Select the state you want to restrict. Click the Advanced link. There you will see 3 radio buttons:
- No change - Override modify permissions - Override all You probably want "Override modify permissions," which will still allow people to view the asset, but only collaborators you specify (and admins and the asset's owners) will be able to modify the asset. See http://publib.boulder.ibm.com/infocenter/ramhelp/v7r5m0/topic/com.ibm.ram.web.doc/topics/t_create_custom_lifecycle.html |
Hi,
Thanks for the info about the new feature in RAM 7.5. It does seem that the closest match is "Override modify permissions". However, this still allows the Asset owner to make changes. Ideally we would not want anyone to make changes to the Asset, other than move it to the next state. Is it possible to get this kind of lockdown or is a custom policy the only way to go? Cheers. Des |
On 10/3/2010 10:37 PM, desdrury wrote:
Hi, RAM has no distinctions between Update and change state. They are both considered updates. The only entitlement is "update" and if you have update then you have the capability of changing content or moving state. This is an outstanding enhancement request: https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/29880 Rich |
Hi,
Though this enhancement controls who has ability to change state. We could probably add "can change state but not update." Or separate the entitlements. Rich |
Hi Rich,
It does make sense to me to have change Asset state and update Asset as two separate entitlements. This way an Asset could be considered complete, and therefore not update-able, but still be able to be moved into different states. States that would show, for example, how the Asset had been tested and then deployed into production. In the meantime do you think it is possible to implement this kind of behavior using a custom policy? Something like the following: 1. At Asset save time the policy would check the current state. 2. If the curent state was one that was defined to be immutable then the policy would check what had changed. 3. If anything other than the state had changed the policy would not allow the Asset to be saved. 4. If the change was only a change to the state the policy would allow the Asset to be saved. Thanks for your help. Des |
Hi,
The problem is that policies run AFTER the change has already been done. It can't prevent an update. It can only indicate that something is not valid in the update. That can prevent the action (state change) from occurring but it can't undo the change. Rich |
Hi Rich,
We do understand that the policy would not run until after the change had been done and the Asset was about to be saved. Obviously this would be an annoyance to the end user, but then again the end user would be the release manager and they should be aware of what can and can't be done in the various states. So we decided that this behavior was not a problem. Given that, would using a custom policy allow us to do the following: 1. At Asset save time the policy would check the current state. 2. If the curent state was one that was defined to be immutable then the policy would check what had changed. 3. If anything other than the state had changed the policy would not allow the Asset to be saved. 4. If the change was only a change to the state the policy would allow the Asset to be saved. Many thanks for your help. Des |
Hi,
Like I said the asset has already been changed. It can't be prevented. You can either raise an error condition on it, or move it to another state that says it was changed and needs to be fixed up, or if you know what the change was exactly then you can undo the change and resave it. But it would be difficult to know what was changed. You don't have the older version to compare against since it has already been changed. Rich |
Hi, Hi Rich, I'm probably being a bit dense here but does this mean that policies do not have the power to stop changes? As I understood it the policy would kick in at certain point, in this case when the user clicks to save the asset, and the policy would then check that everything was as it should be. I thought that if the policy failed then the changed Asset would not be able to be saved. And as it would not be able to be saved it would not be changed as the only option available to the user would be to press the cancel button. Cheers. Des |
Hi,
I'm probably being a bit dense here but does this mean that policies No they do not have the power to stop changes. The save has already physically occurred before the policy even runs. Rich |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.