It's all about the answers!

Ask a question

Type and role-based and state-based work item attribute change permissions


Natalia Liaskovski (5711219) | asked Nov 25 '13, 11:02 a.m.
For RTC 4.0.4 in order to restrict who can change attribute value in a certain state, do I need to go custom process  adviser route or is there another approach(es) ? E.g. Defect severity can be set by anyone in the New state, but only by management roles in any other state (role based, work item type and state based rule)

Comments
1
sam detweiler commented Nov 25 '13, 11:10 a.m.

there is no provided Advisor that will manage access to workitem field changes by user role.  So you would have to create that. Because the user (Contributor) and role cannot be accessed in Javascript, you will have to create a full Java Advisor/Precondition

its not all too hard.. you could copy the existing type/state advisor source and add Role support. (I have built an advisor like that.. copy product source, and build new)


Natalia Liaskovski commented Nov 25 '13, 11:24 a.m.

Thank you. I suspected that much, just wanted to confirm that custom java process adviser is the only route. Thanks again

Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered Nov 25 '13, 12:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can use the "Read only attributes for Type and State"  operation behavior precondition.   This is a precondition of the Team_Configuration -> Operation_Behavior -> Work_Items -> Save_Work_Item operation.
Natalia Liaskovski selected this answer as the correct answer

Comments
sam detweiler commented Nov 25 '13, 12:55 p.m.

it doesn't have Role as one of its control attributes..


Geoffrey Clemm commented Nov 25 '13, 1:13 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Every operation behavior has role as one of its control attributes ... you always select what role a given operation behavior should apply to.


sam detweiler commented Nov 25 '13, 1:20 p.m. | edited Nov 25 '13, 1:51 p.m.

Yep, sorry, you are correct.  I forgot that the 'save workitem' thing is a grid based on role, and the OOtB selects 'Everyone' as the role.

but what happens with multiple roles selected and multiple different operations?  who wins what? 


maybe this explains it
https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.platform.doc/topics/c_roles.html&scope=null

When operation behavior is configured for multiple roles, the process runs the behavior that is associated with the highest-priority role for the user. Priority does not affect permissions; users can perform actions that are granted through any of their assigned roles.




Natalia Liaskovski commented Nov 25 '13, 6:48 p.m.

Thank you ! This is exactly what I needed.

In my case there is no role conflict - in OperationBehavior the role of Everyone is not allowed to set attributes for the given states, while only selected roles override this condition. I think role 'Everyone' is somewhat special, I don't know how conflict would play out for other roles (Sam's link may come in handy here).

As a side note to anyone who may need this - there is no conflict with Permissions either. Permissions are set to allow write on all attributes for Everyone. Operation Behavior (where I introduce restrictions) wins over Permissions.

Thank you, Geoffrey


Geoffrey Clemm commented Nov 27 '13, 2:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

WRT Sam's question, the search path for which Operation Behavior is run is somewhat complicated (I always forget the details a few months after I refresh my memory :-), but it involves searching through all the relevant process areas (including iteration types and parent team/project areas), and all of your assigned roles, with the nearest process area and the first assigned roles it finds taking priority.

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.