Multiple preconditions for operation behaviour.
I am trying to set-up an operation behaviour when delivering change-sets to a stream. First, what is the difference between Deliver (client) and Deliver (server) ? Does client mean the Eclipse IDE ? But, the Web front end could be a client too.
The second question is about the description of Pre-conditions as seen in the page for setting operations from the Eclipse client (emphasis mine). Preconditions are checked before running an operation; follow-up actions are executed after. An operation's preconditions and follow-up actions can be configured differently for each role. Note that operation configurations completely replace each other; they are not additive. The process runtime will choose the most appropriate operation configuration for the logged-in user and will use only the preconditions and follow-up actions defined in that configuration.The text in bold is apparently referring to the fact the final condition is not a AND of the comprising conditions. So, what happens if multiple configurations are actually provided ? Here is an example. For Deliver (client) and Deliver (server), there is a precondition for to have a Work Item and comments. (I presume, comments are for change-sets ?). Then, there is one for the Work Item to have an Approval. My requirement is to have both. That is, a change set should be delivered if an associated Work Item exists AND the Work Item has an approval. So, if both preconditions have been selected, then exactly what is in effect ? I seem to have achieved my goal by selecting the precondition for approval; but, I do not understand what do the options on this page actually mean. |
Accepted answer
on the second part, they mean if you have multiple roles assigned to the user, they are not additive.
the highest authority role configuration wins. these pre/post actions are configured by role. <br> The process runtime will choose the most appropriate operation configuration for the logged-in user and will use only the preconditions and follow-up actions defined in that configuration. Nagesh Subrahmanyam selected this answer as the correct answer
Comments
Nagesh Subrahmanyam
commented Dec 28 '12, 8:00 a.m.
"the highest authority role configuration wins"
sam detweiler
commented Dec 28 '12, 9:45 a.m.
everytime I see the role grid, it is left to right, everyone, then lower further to the right.
Nagesh Subrahmanyam
commented Dec 28 '12, 12:36 p.m.
everytime I see the role grid, it is left to right, everyone, then lower further to the right. you could look at the grid used for pre-condition setup.. Sorry, Sam, I didn't follow that. Perhaps, I am being dense. Are you saying the highest is at the left of the grid ?
the workitem the user is acting on determines the role the user has. the workitem has the data in it that selects the TeamArea.Yes, I got that. However, what if a person has different roles in different team areas ? We want to nominate a person as a "Librarian" whose task is to migrate code to system testing and then to production regions. However, as our team is small, this person is also expected to be a "Developer". Naturally, we would like to have the Librarian role have broader access than the Developer. I thought, we could implement this by having different team areas where the same person has different roles. But, I am not sure, what roles takes into effect as soon as this person logs in ? (In the meantime, I am arguing with management to allow a different person for librarian activities to avoid such hassle.)
sam detweiler
commented Dec 28 '12, 4:55 p.m.
see the great articles posted below by Ralph
|
2 other answers
on the seconds part, they mean if you have multiple roles assigned to the user, they are not additive.I see. So, it is about multiple roles a user could have; not the multiple preconditions as applied to a given role. Having said that, these preconditions can be adjusted up and down. So, there does seem to be some order of the preconditions being applied. What does this mean ? Comments I don't think the order of the preconditions is significant. Or at least not very significant. I think all preconditions are still run even if the first one fails. Even if that is not true and precondition checking stops at the first failure, the order of the preconditions would only affect the error message that you receive, not the overall success or failure of the operation.
sam detweiler
commented Dec 22 '12, 11:39 a.m.
I hadn't noticed the up/down even after all this time.
Nagesh Subrahmanyam
commented Dec 22 '12, 12:19 p.m.
I think, the key message is, all the preconditions do run.
|
Ralph Schoon (63.5k●3●36●46)
| answered Dec 28 '12, 2:05 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Please have a look at https://jazz.net/library/article/292 for how that works. Also look at https://jazz.net/library/article/291 .
Comments And be aware that if a higher priority role has a configuration, configurations for lower priority roles are not going to trigger. E.g. If you have a precondition for TeamLead, the preconditions for Everyone won't trigger for someone wit TeamLead role. |
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.