modify indentity policy rule

[bnielsen]

when a object has been moved through a life cycle, lets say (concept, inwork, released) and then are revised back to in work state, you have to have elevated user rights in order to change the NAME of the object. im not talking about FILENAME and NUMBER, but only the descibing text of an object

in order to rename the user has to have Modify rights for all versions=in all states, that also means that the user gets the permission to check out objects in state released!!! because the Modify rights also controls the check in and out

i would be nice to seperate the modify and the modify indentity, so that the modify identity would work as its name says

1. suggestion: modify indetity will affect only the NAME field, so with the modify identity granted you are able to RENAME the objects in all states. the name should not control the uniqness of the object, that is the NUMBER and FILENAME

2. suggestion: MODIFY IDENTITY will affect only the latest iteration of the object, and only the NAME field

      a. so if you have MODIFY rights in a certain state you can rename the object, then the history will also display renaming though out the lifecycle

3.suggestion: add a new policy rule called MODIFY NAME

[OliverDroop]

In rev9 name was controlled by modify identity which worked well since number should not change anymore after release.

Name could be synched to a versioned iba which is already the source - e.g. Common name parameter in cad. Since this needs to be cuatomized there is no security issue.

Now with modify it is not clear, mixed identity and MBA and I guess it was more a quick fix.

Option 3 is the cleanest. A preference if name should be handled by identity or modify permission would be an alternate as well. But often I see even more granular permission demands. Like role a may modify certain attributes in certain states. Or role b can change links of released objects but may not change attributes.

Therefore it might bw worth to make it a dedicated project