ReadOnly attributes by condition for Team Area Members

Fran Burgos (123●1●22●52) | asked Jul 17 '18, 4:06 a.m.
edited Jul 19 '18, 5:39 a.m.

I need configure a "Read Only attribute by condition" for several users whom are members of a Team Area and not directly from Proyect Area. But I can not get it to work.

Scenary:

RTC 4.0.1

PA (Project Area): PA1

|- TA (Team Area): TA1 <-- Members are here with role: R1.

I have a condition called "is-done" which returns true when a work item (wi) is on state "done". In addition on the Team Configuration > Operation Behavior > Save Work Item (server) [role: R1] > Preconditions > "Read Only attribute by condition" with condition "is-done" for "Description" attribute.

Script code:


        
            (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";
        
        
                    }
        
        
            

        
        
                });
        
        
            })();

With this configuration when you create a WI with "field against" value TA1 (category associated to TA1) and I transition it to "Done" I expected "Description" attribute is on read-only but is still editable. But if I move an user from TA1 to PA1, then this works as expected and "Description" is read-only.

How should I configure this to work with members that just be only on Team Areas and not on the Project Area member list?

3 answers

Most liked answers|Newest answers|Oldest answers ↑

permanent link

Ralph Schoon (63.1k●3●36●46) | answered Jul 17 '18, 4:29 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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

Fran Burgos commented Jul 17 '18, 5:10 a.m.

I debugged state, action, etc... and its works right when the user is on PA member lists. Actually the condition is pretty simple.

I think is something I misunderstanding about how Operation Behaviour run. Because I thought main role for user who is saving the WI is calculated looking for on Team Organization from top-to-down and if you have a WI with "field against" then applies the Process Area Configuration associated to it(for example if it has a redefined process on the TA). In fact, I tried to set the Operation Behaviour directly on the TA (redefining the process) but it does not works either.

Ralph Schoon commented Jul 17 '18, 5:27 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

This is how operational behavior is working:

Process behavior lookup in Rational Team Concert 2.0

Note, users can ave multiple roles and the roles order counts. Only the first matching configuration is executed.

Fran Burgos commented Jul 17 '18, 7:13 a.m. | edited Jul 17 '18, 7:25 a.m.

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

Fran Burgos commented Jul 17 '18, 8:31 a.m.

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.

Ralph Schoon commented Jul 18 '18, 4:10 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Fran Burgos commented Jul 19 '18, 3:26 a.m. | edited Jul 19 '18, 3:27 a.m.

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)

Because the user has role "Developer" and the work item which is saving has "field against" value with category "TA Test" which is relationed with "TA Test" TA. So I'm not sure why it running for "Everyone" instead of "Developer"

Ralph Schoon commented Jul 19 '18, 3:56 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Fran Burgos commented Jul 19 '18, 4:30 a.m.

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.

Ralph Schoon commented Jul 19 '18, 4:40 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Then it is probably the condition that is the problem. Check the logs and try to debug what the condition does.

Fran Burgos commented Jul 19 '18, 5:42 a.m. | edited Jul 19 '18, 5:43 a.m.

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).

showing 5 of 10 show 5 more comments

permanent link

Stefan Oblinger (185●2●13) | answered Jul 19 '18, 9:11 a.m.

I've seen such behavior before raising following Defect:

378043: Wrong execution of Javascript Conditions in Webbrowsers

It should be fixed with 6.0.2.

Comments

Ralph Schoon commented Jul 19 '18, 9:16 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Stefan, would you think running it in the Eclipse client could show different behavior?

Stefan Oblinger commented Jul 19 '18, 9:33 a.m.

Yes, I recommend @fran00b to test in Eclipse Client, too. If he cannot reproduce the Defect there, then he might have found a regression.

Fran Burgos commented Jul 20 '18, 4:17 a.m.

I tested it on Eclipse Client and the result is the same. "Description" is still editable such as on the browser.

Stefan Oblinger commented Jul 20 '18, 4:37 a.m.

Then I have no clue, sorry.

permanent link

Ashok Karuppiah (5●3●5) | answered Apr 20 '20, 6:24 a.m.

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.

I know it is not the best solution. But, it seems to get fixed, when that precondtion 'Read only by Condition' is set for 'Everyone' role, too. I set the 'Read only by Condition' as the top most condition for Everyone. After that, the precondition works fine for the PM role user, even if that user is present with PM role only at team area and user is not present at all in project area. So, may be pre-condition of 'Everyone' is applied to all users, even for the user who has only one role PM on one team area and that PM role has its own pre-condition defined.

Comments

Ralph Schoon commented Apr 20 '20, 6:42 a.m. | edited Apr 20 '20, 6:49 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I am sure that the behavior can be explained based on the Process behavior lookup in Rational Team Concert.

Note: users can have many roles, roles have an order, only the first behavior found for a role that the user has will be called. Everyone has the default/everyone role. Note that checking preconditions (operational behavior) is configured for a role and not configuring anything, removes any behavior for users where this role is found first.

Your answer

Register or log in 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.

It's all about the answers!

Related questions

ReadOnly attributes by condition for Team Area Members

3 answers

Your answer