Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
Hi all,
I'm looking for a way to close a current gap in the I10.2 implementation.
I have a node item type (requirement) that contains a SourceTrace Field (a "trace" not a "link" - meaning that any update to the memberrevision of the trace will be propagated to the Item). This in general works fine.
What I'd like to have chance to "react" on these updates by
1. flagging the node item as suspect
2. sending an e-mail to the stakeholders
Unfortunately the Update is done by some "background magic" and therefore no event is fired during the update of the item.
As a result I cannot use a IM trigger based on the usual :
compare: field (old value)<>field (new value)
schema.
As a second though i tried a differnt approach: I wrote a SI triggerscript (see attachment ) that uses the IM "viewsourcetraces" command to get all referenced Items for this member and i then i can process these IDs.
I started with a POST trigger, but in that case, the trigger was fired a a moment when the member revision was already changed, but the source trace was not updated yet, so the "viewsourcetraces" command always resulted in a empty list.
So i used a pre trigger as I need both the OLD revision of the member, to get the traced Items.
This works fine, for the e-mail submission, as a readonly IssueBean is no problem.
But if try to open the Items for performing a significant edit (e.g. add a comment that would trigger the suspect flagging), I cannot get the IssueDeltaBean from the server.
Anybody any ideas?
One thing that has always bugged me in the SI triggers is that we only get access to the siServerBean rather than the imServerBean, meaning we cannot get to any of the useful IssueBean/IssueDeltaBean functionality that imServerBean allows.
Instead what I end up doing in my SI triggers is using API calls to run IM viewissue and IM editissue commands.
The benefit (as well as risk) of using these API calls is that they can complete outside of the normal IM PRE/POST trigger restrictions so you can still make an IM editissue call to change values in fields even in a POST trigger.
Unfortunately we don't use sourceTrace fields so I'm not sure it applies directly to your question, but we do make use of Time Entry so I ended up using the API commands to duplicate some of the IssueDeltaBean functionality in the "time entry changed" event context.
I've attached a js file with those API commands.
PTC, this would be much simpler if we could access imServerBean from the SI trigger context... is there any RFC for this?
Matt