Hi Jens,
I haven't used a QBR in a trigger script yet, so let me see if I can help you with some pseudocode of the original trigger script using just the IBPL.
//load the issueDeltaBean for the request (where the rule is firing)
requestDeltaBean = bsf.lookupBean( "imIssueDeltaBean" )
//load the backing items on that request (we use getNewIBPLFieldIssueIDs because its a multivalue field)
setBackingItemIDs = requestDeltaBean.getNewIBPLFieldIssueIDs("backing item field name")
//as an FYI, the data type returned from getNewIBPLFieldIssueIDs() will always come back as a Set if there are multiple values selected, however if there is only one value selected it sometimes comes as a Set and sometimes comes as a plain integer, you can use the below code to figure it out at runtime and force it into a set. Also remember to check for NULL if the field could be blank to avoid null pointer exception
if(setBackingItemIDs.getClass().getName().equals("java.lang.Integer")){
//add it into a set so the loop works
} else {
//already a set so we're good
}
//loop over the backing item IDs with for/while/etc
//for each ID in the setBackingItemIDs
//grab the backing item bean
//(you can use the readonly issue bean here for performance, but deltaBeans will work as well)
backingItemDeltaBean = beanServer.getIssueDeltaBean(ID)
//get the fields you need from the backing item
stringModuleName = backingItemDeltaBean.getFieldValue("Module Name Field")
stringDeveloperName = backingItemDeltaBean.getFieldValue("Developer Field")
//make the new task
newTaskDeltaBean = beanServer.postNewIssue("Task item type")
//add it to any relationship fields between request and task
//store the new values in it
newTaskDeltaBean.setFieldValue("Module Field on Task", stringModuleName)
newTaskDeltaBean.setFieldValue("Developer Field on Task", stringDeveloperName)
//end loop
//trigger continues to do whatever else you need
The overall key to making this work is the getNewIBPLFieldIssueIDs() call. It is very powerful in that it allows you to store data in fields on the backing item, then retrieve that data in your trigger processing. This means that if the data will only be used by triggers, you don't need to try to do FVAs (which don't work for multi-value fields and don't flow through multiple relationship levels). In fact, we have a backing item which represents an "employee" that has an IBPL backed by the "employee" item on it. This allows us to iterate over all the items in the chain using repeated getNewIBPLFieldIssueID() calls and produce some useful results.
Hope that helps,
Matt
