RTC API - Creating WorkItems and modifying them - serverside

See also https://rsjazz.wordpress.com/2012/12/14/do-not-modify-the-triggering-element-in-an-operationadvisor/

You can do all this and Sam's explanations are great - as always. Unfortunately I haven't gotten to blog an example yet. It is high on my list.

I thought that the 'workitem' newstate was effectively a temporary read only copy of the  workitem changes proposed by the thread that initiated the save. any change made to that read only copy would be lost.

reading the workitem AGAIN from the database in an Advisor and then initiating a save breaks the chain of modifications, as you are attempting to override change1 while it is in flight with change 2 (which MUST complete its pass thru the advisors and participants before the advisor for change 1 can get control back from the save operation..  thus you can have change 1 overlay the changes done in change 2.
you have NO idea what the other advisors/participants might depend on, or the order in which they will execute.

You can't modify the item in an advisor - the interface discourages it. it works today, but noone guarantees it will in the future.

Use a participant to do that. You can create new workItems in a participant like this:

IWorkItem aWorkItem = IWorkItemServer.createWorkItem2(wIType);

// Set the values
// Save with additional parameters to alert this participant to ignore to avoid recursion
Set<string> additionalParams = new HashSet<string>();
additionalParams.add("I WAS HERE");
fWorkItemServer.saveWorkItem3(aWorkItem, null, null,
        additionalParams);
</string></string>

I think adding a

          Object o = operation.getOperationData();
           if (!(o instanceof DeliverOperationData)) {
            return;
          }

at the very beginning of the participant should serve the same purpose (because I only need to process things on a deliver operation). This condition is always true for a save instance, correct? (We will always return from this if block on a save operation)

No it does not. If you create a work item in a participant it will trigger work item save operational behavior for that work item. The object will be a work item.

So if you write a participant that, on creation of a work item, creates new work items (with links), the participant will trigger for the new work items and could kill the system by creating new work items and so forth. This is one of the few reasons the Additional Parameters are used for.

I understand what the message is: Participants are always triggered on creations of workitems/saving workitems. So for the multiple triggers operation.getOperationData() will always be an instance of DeliverOperationData? i.e operation.getOperation() instance of DeliverOperationData and operation.getOperation() instance of ISaveParameter can be true at the same time? that's my question.

Now if that's true then I'm confused as to why we have a choice of picking preconditions for separate Operations (project -> Process configuration -> Team configuration -> Operation behaviour). Because we can be distinct about what participants/advisors are called for different operations . Are those operations only executed for actions done through their corresponding client (I.e for e.g saving a workItem through the client and not the server(now that's even more confusing because saveWorkItem has "(server)" in brackets next to it))?

you never mentioned that your participant was for a Deliver operation.

if you only handle delivers, then your code is ok. because you won't be called for a workitem save operation

Yes, the deliver got me as well 8)

As long as you don't trigger another deliver in the operation (I am not even sure that is supported, we tried that once and it blew us out of the water with an error in the transaction) you should be fine.