Avoid Participant Propagation
![]()
We have the following WI structure:
WorkItem3(fathers father) |--WorkItem2 (father) |--WorkItem1 We created an Operation Participant that when the user modifies an attribute in WorkItem1, it updates this value in the fathers WorkItem (WorkItem2). The trouble we are finding is that when the value in WorkItem2 is automatically updated and saved by the Operation Advisor, another instance of the Operation Participant is triggered and tries to update the WorkItem3. Normal behavior, but not desired one: we need only one level of propagation. We cant find the way of detecting who triggered the Save Operation, whether the user, or the "workItemServer.saveWorkItem2()" operation in the Participant. Any idea about how to tackle it?? Appreciate any comment. Thanks Noel. |
Accepted answer
2 other answers
![]()
Hi, I had the same problem and tried to get some help here. As I got nothing, I use a simple manual solution: common plug-in+session manager.
Here is some more information: http://jazz.net/forums/viewtopic.php?p=52519#52519 |
![]()
Hi, I'm facing the same problem but instead of the infinite loop behaviour I'm obtaing a blocking one by several advisors. Is there a way to make a builtin advisor to skip the execution if a postop already run?
I mean there exist a builtin FLAG to skip builtin advisor executions?
Comments ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Raffaele, if you are blocked by other advisors, you should fix the configuration for your role. Also the behavior is orchestrated and they are run in the order top to bottom. You have to satisfy all configured advisors, because that is the rule. They will be called by the save in a participant, but because they are advisors you should have no issue when saving the same work item. If you create work items in participants, you simply have to provide the data that is asked for.
Hi Ralph, first of all thanks for your fast reply. I admit that after a workitem save, attributes status must remain coherent with respect to advisors, but in the case of both readonly attribute for type and state and readonly by condition this might be useful to permit the attribute to be written by the plugin but not modificable by the user.
BTW (if there is no possibility to obtain that) is there the possibility to hide an attribute in the presentation if a condition (server or js side) macthes?
Thank you again
![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Rafaele,
I'm using RTC 401, there are some attributes that become read only only if another wi is linked to a specific link type in the other case the same attributes are not readonly and mandatory (the latter scenatio permit the user to write the attribute). In the former case we would "inherit" values from the linked workitem (and remain "synchronized") but any user modification must be denied. (i know that a participant solve the issue, but the customer won't renunce to readonlyness).
Regarding the ability of calculated values to write on fields, regardless of readonlyness, did you mean a presentation (always) readonly or state by state one?
|