Everyone role operational behavior taking precedence over other roles?
We are having an issue with Operation Behavior inheritence in RTC, all part of the Save Work Item (Server) behavior sets. Let me paint the picture:
We have configured Operation Behaviours for the "Everyone" default role, and recently configured an additional role to have a different set of behaviours. The "Everyone" role has Read-Only Attributes for Type and State configured to lock off some attributes on a certain work item from most users. There is one other role, call it "Role A", that has Save Work Item operation behavior configured, where it has no Read-Only Attributes for Type and State (they both have different Required . There are other roles, and users have Role A in addition to other roles, but no other roles have operation behaviors configured. I know the roles are not additive, but I believe any role should take precedence over "Everyone" and any user assigned the role at any level of the project area would have that role's operation behavior take effect. No other roles have behaviour configured, so my expected behaviour is:
- Users who have Role A, usually in addition to other roles, will be able to edit the attributes (because they do not have a read-only behaviour configured)
- Users who do not have Role A, regardless of other roles, will not be able to edit the attributes (because the Everyone role's op behaviour takes effect in absence of another role configuration).
- Op Behaviours not configured anywhere besides project level
- Teams configured without any permissions and most do not even have users. In the rare case a user is on a team that's assosiated with a work item, they have Role B or something else.
- Users and their roles are mostly at the project level.
Ways I have "fixed" the problem:
- Synced items, made users relaunch browsers, clear cache, etc.
- Moved Role A to being the first role in the user's config - this appeared to instantly fix issues on refreshing, then stopped working.
- Set the Operation Behaviors for the two roles to Final (though no op behavs should be configured anywhere besides project level) - appeared to fix on refresh, later stopped working.
- Change Filed Against to root level or a teamless Category, which makes the fields editable for a user with Role A, and switching back locks them down again. Looked through process template, came back, fields were editable regardless of Category even though I didn't change anything. Not sure when this will stop working.
I have read the hierarchy guide at https://jazz.net/library/article/292 and it makes sense, though I have a few questions. If an item is filed against/team bound to a team that the user is not specifically in, it maybe would roll up the Everyone role for them, but that goes to the bottom of the stack right? If an item's team does contain that user and they have Role B or C etc, Role A should still beat Everyone when it's all said and done because they have that role at the project level.
Any ideas on why this issue randomly appears and disappears? I will open a PMR if there is no obvious answer I'm missing.
|
3 answers
Hi June,
I would say it 'randomly appears and disappears' because you are not taking care of the order of the roles. The order however is important when it comes to operational behavior
Source Ralph Schoon: A Custom Condition to Make Attributes Required or Read-Only by Role
I know that many people from different companies have struggled with that concept already, as it is definitely not obvious, so I'm sure there is already a PMR/RFE for this.
Comments Thanks Lukas.
Unfortunately we've already run through that doc and looked into role order. It appeared to fix the issue at first but it still seems to randomly fail. Only one role is configured as well so by that document's description of how things are queued, it should work either way. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Mar 03 '18, 11:35 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER It is correct that the Everyone role is only checked after all other explicitly assigned roles have been checked.
I have seen some caching related delays in picking up new behaviors, but that doesn't seem to explain the behavior you are seeing, so a PMR is probably appropriate.
|
Ralph Schoon (63.5k●3●36●46)
| answered Mar 05 '18, 2:36 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Mar 05 '18, 2:39 a.m. I am not sure what the problem is. The description is nice, but I seem to be unable to identify the part that creates the problem. I have seen claims that this somehow does not work in the past. Most of them resolved to be a user problem.
I know the roles are not additive, but I believe any role should take precedence over "Everyone" and any user assigned the role at any level of the project area would have that role's operation behavior take effect. It is really important to look into the article https://jazz.net/library/article/292 . The operational behavior only executes the first configured operation for the role in the order it is set to the user. Just checking the box that operational behavior is configured (even if nothing is configured) is enough. The process area that owns the element that is changed is the one that the role search starts. Comments As noted in my post I did read the article 292 and it didn't quite cover this use case. Normally I find checking the box to be enough; for example, I check the box on Administrator to override various required fields and such when doing unusual bulk operations. I forgot to add to my diagnostics steps that we did indeed change the order of roles to ensure Role A was at the top, though as Role B C etc are not configured and only Everyone needs to be superceded it shouldn't realllly matter. First time we reordered roles, it appeared to fix it and then it stopped. |
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.