It's all about the answers!

Ask a question

Locking down an Asset


Des Drury (66107) | asked Sep 30 '10, 8:46 p.m.
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



permanent link
Eric Bordeau (27632) | answered Oct 01 '10, 10:59 a.m.
JAZZ DEVELOPER
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

permanent link
Des Drury (66107) | answered Oct 03 '10, 10:35 p.m.
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

permanent link
Rich Kulp (3.6k38) | answered Oct 04 '10, 9:48 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
On 10/3/2010 10:37 PM, desdrury wrote:
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

permanent link
Rich Kulp (3.6k38) | answered Oct 04 '10, 9:50 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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

permanent link
Des Drury (66107) | answered Oct 04 '10, 10:01 p.m.
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

permanent link
Rich Kulp (3.6k38) | answered Oct 05 '10, 9:34 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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

permanent link
Des Drury (66107) | answered Oct 05 '10, 7:13 p.m.
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

permanent link
Rich Kulp (3.6k38) | answered Oct 06 '10, 10:28 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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

permanent link
Des Drury (66107) | answered Oct 06 '10, 10:53 p.m.
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

permanent link
Rich Kulp (3.6k38) | answered Oct 07 '10, 9:40 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hi,
I'm probably being a bit dense here but does this mean that policies
do not have the power to stop changes?

No they do not have the power to stop changes. The save has already
physically occurred before the policy even runs.

Rich

Your answer


Register or to post 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.