ReadOnly attributes by condition for Team Area Members
(function() {
dojo.declare("com.example.Condition", null, {
matches: function(workItem, configuration) {
var STATE = com.ibm.team.workitem.api.common.WorkItemAttributes.STATE;
return workItem.getValue(STATE) === "3";
}
});
})();
3 answers
This is not trivial and your assumption about the state might be incorrect. Debug the attribute customization to understand the values of the state, the action etc.
You also can not access team membership in the JavaScript API. See https://rsjazz.wordpress.com/2016/07/15/rtc-process-customization-what-you-can-and-cannot-do/
Here some examples where you have all the information and that also calculates the current state:
https://rsjazz.wordpress.com/2015/08/07/a-custom-condition-to-make-attributes-required-or-read-only-by-role-version-2/
https://rsjazz.wordpress.com/2015/06/19/a-custom-condition-to-make-attributes-required-or-read-only-by-role/
More Java API, simpler: https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/
Comments
This is how operational behavior is working:
Note, users can ave multiple roles and the roles order counts. Only the first matching configuration is executed.
Yes, I keep it in mind. In this case "developer" user on "TA Test" only has "Miembro de equipo" role. To testing I configured the Read-Only for Everyone role within PA and it works, which is very rare because this means the Operation Behavior is running with PA configuration instead of TA config.
In addion I checked this link: https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.platform.doc/topics/c_behavior.html&scope=null
And the order to run Operation Behaviour should be: Iteration > Iteration Type > Team Area > Project Area
Related to referenced articles, they say:
"...when saving a work item, the governing process area is the one that is associated with the work item’s category..."
"...if a user is assigned the team lead and developer roles, we first try to find behavior configured for team leads. If we don’t find any behavior configured for team leads, then we try to find behavior for developers. Failing that, we try to find behavior for everyone (the “default” role). The first of these roles that is configured is the one whose behavior will take effect; we don’t combine behavior from multiple roles..."
In this case is entering using "Everyone", so it looks like such as not "Miembro de equipo" role is not found.
Most of the users I am aware of in general configure operational behavior on the PA for the role everyone. This reduces the configuration effort.
If you configure it for other roles say developer as well, the issue is that you will need to manually redo the configuration for the behavior you want to keep from everyone. Otherwise the behavior is overwritten and will not be executed if a user has the role developer.
Everyone will always be the last role in the role order.
Yes, I keep in mind that is better configure everthing you can on Everyone role. But this secenario is a simple case from ones I have on a production environment. Related to process behaviour lookup when a user "developer" performance a work item save, reading the article I understand the order should be:
- Developer (TA: TA Test)
- Everyone (PA: RTC Extension Workshop)
If the category is associated to a team area I would assume the operational behavior to start at the team area level, find the user role and then work up to the PA if the user does not have the role. I can not verify this here. You can run a Generate Runtime Report for the user on the project area in Eclipse to see their roles.
NOTE: by configuring Operational behavior on a role in the Team area, only that operational behavior will be run in case the role is found. The operational behavior configured on Everyone in the PA will not be run in this case.
I have checked this configuration using "Read-Only Attributes for Type and Sate" instead of "Read-Only Attributes for Condition" and the behavior works right. Hence it seems something with this last extension. In addition I tried both cases on RTC 6.0.6 and it has the same result: With "...Type and State" works like expected but with "... Condition" does not work.
Then it is probably the condition that is the problem. Check the logs and try to debug what the condition does.
I debugged and it works right when the user is on PA but not when he is on TA. I updated original post with script code (it is very simple).
Comments
Stefan, would you think running it in the Eclipse client could show different behavior?
Yes, I recommend @fran00b to test in Eclipse Client, too. If he cannot reproduce the Defect there, then he might have found a regression.
I tested it on Eclipse Client and the result is the same. "Description" is still editable such as on the browser.
Then I have no clue, sorry.
Hi Fran, I guess this post is old. But, still want to updte, in case if it helps anyone. I encountered a similar situation i.e. An applied 'Read only by Condition' set for a Role say PM works only if the user is present with PM role at container level. If the same user is not present at container level, but present with PM role at team area level, the precondition does not work at all. This is for the version 6.0.5.
Comments