"extended" constraints?

[JensN.]

Hi @all,

i'm using Integrity 10.2 ChangeManagement. I have 3 different item-types: one request, one task and one backing item. The backing item will hold at least two fields: "modulename" (short text) and "developer" (userfield). The request will hold an ibpl-field based at the backing item, where the user could choose modulenames (multivalue). If the request comes into a new state, a task item should be generated for each selected modulename. The task also holds some fields: modulename (short text) and developer (also ibpl based at the backing item). So far all of this works by a trigger. But now comes my question: how can i assign each task to the developer, which is set to the module in the backing item? With constraints i could filter the ibpl-field in the task according to the packagename, so i couldnt choose the wrong user. But i also couldnt preselect the userfield. But thats what i want. Is this possible without a trigger?

Thanks, Jens

[mrump]

Hi Jens,

IMHO ....no; You will need a (pre-)trigger to set the assigend User.

One thing you could try is to make the assigned user field mandatory in your new state. I assume this would preselect the only available User when you interactively edit the item in the GUI.

HTH Matthias

[matt_giltaji]

Hi Jens & Matthias,

I agree with Matthias, you will definitely need a trigger in order to set any values, and this could be part of the trigger which creates those items.

However if you make the assigned user field mandatory in the initial state and you trigger does not populate the assigned user field when creating the item in that state, then your trigger will error out due to the mandatory field missing a value. To resolve that, either leave the assigned user optional in the initial state or make sure that the trigger is adding a value to it.

Hope that helps,

Matt

[JensN.]

Hi,

thanks to you both for your answers. Because working with three relationships in one trigger is to heavy to me i wanted to work on this challenge in another way. So i put a qbr-field into the request. This qbr-field now holds all correlations that i need as a table.

modulename A goes to username B

modulename B goes to username C

modulename C goes to username A

modulename D goes to username C

But how can i use this in my trigger? I didnt find a (good) explanation how to use data from a qbr-Field in a trigger. Can you help me?

Thanks and regards, Jens

[matt_giltaji · Accepted solution]

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