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
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
- 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
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:
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,
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
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 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
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 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
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
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,
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 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
page 1of 1 pagesof 2 pages