Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to Learn more.

Passing information from Test result to Defect during Defect Creation


Passing information from Test result to Defect during Defect Creation


I am attempting to setup some defect item automation when it is created from a test session via test result editor. I would like to use "Create Related" in Test Result Editor to create a defect. In createing a defect, I would like to setup fields in the defect item based on it being generated from a Test Session.

Is there a way to pass information from the test result to the newly posted defect item that was created via Create Related?

Is there a way to do this via Custom Action? I've run set command via custom action and I don't see any MKSSI_ISSUE0.

It seems that the defect item can be updated after it has been created via defectDeltaBean.getRelatedTestResultBeans(). But this requires a second trigger to run sometime after defect has been created.

There needs to be a getNewRelatedTestResultBeans() function.


...Or is there a way to create a delta bean from testresult trigger and getAddRelatedItems() ?


Hello Mark,

I please contact Integrity Technical Support to have them investigate this.

If there is a current solution, I'm sure the entire community would appreciate you posting the findings here.


Kind Regards,
Kael Lizak

Senior Technical Support Engineer
PTC Integrity Lifecycle Manager

Hello Michael,

The only delta that can be created/operated on in a test result trigger is via postNewIssue. The new issue cannot be modified, it can only be created.

After discussing with tech support and experimenting I came up with following:

  1. use postNewIssue in new test result trigger. This will create a "blank" item with state=Unspecified when the test result is saved. The test result is related to this new item. Editability and relevancy rules are applied to this item when state=unspecified.
  2. An hourly trigger will query these "blank" items and set them up based on test results/test session information.
  3. The user can see that an item has been created.
  4. The user can edit the item, causing a delta bean trigger to execute, that will setup the item based on the test result/test session information

My concern now is the following statement in 10.5 release:

"164188, 939183 You cannot call the postNewIssue() function from a "Test Result is Changed" trigger.

Note: Calling postNewIssue() from this trigger now generates an error in the server logs stating the function is not supported when called from this trigger. See the PTC Integrity Event Trigger Java Documentation for more details"


Hi Mark,

we have a similar use case:

All our Test sessions are related to a "Device Description" Item that holds the detailed Hardware and Software Setup Information of the tested device used in the Session (where a "device" is one specific combination of several electronic units each with individual Hard and Software).

To increase productivity the Test engineer should be able to enter defects with minimum effort, so they are asked only for the defect description as a mandatory field. Any other valuable information is anyhow already given by the test result's context (test case + device description )

To avoid extra effort for the developer analyzing the defect, the context data from the device description shall be available directly in the defect (not via the "route" : defect -> result -> test session -> device description)

We solved this using a 2 step approach:

1. create defects by test engineers using "create related Item" in the Test Result Editor

2. a schedule trigger (hourly) queries for "defects with testresults but without a related device description". For all found defects, the trigger script retrieves the required data via the "route" : defect -> result -> test session -> device description and copy the requested information into the defect.

The script looks somehow like this:

// Main execution block... 

function main() {
logDebug("Try to copy "+ sourcefield+ "from TestSession linked via 1st TestResult to " + targetfield); 
//get Items to process from query 
var issues = args.getIssues(); 
for (var i = 0; i < issues.length; i++) { 
//get new "writeable" target Item 
var issueDeltaBean = serverBean.getIssueDeltaBean(issues[i]); 
logDebug("processing Item " + issueDeltaBean.getID() ); 
//get the result objects 
var currentItemsTestResults = issueDeltaBean.getRelatedTestResultBeans(); 
if (currentItemsTestResults != null && currentItemsTestResults.length > 0){ 
// choose the 1st Result 
// get the Test Session from the Result; the Results in the Array are in reverse order, so we need to fetch the last to get the 1st 
var testSessionBean = currentItemsTestResults[currentItemsTestResults.length-1].getSessionBean(); 
if (testSessionBean != null){ 
// get the requested value from the TestSession 
var value = new java.lang.String(testSessionBean.getFieldValue(sourcefield)); 
value = value.replace("[","");
value = value.replace("]","");
value = value.trim();
if (value != null){ 
var msg = new java.lang.String("Automatically copied value " + value + " from "+ sourcefield + " in TestSession "+testSessionBean.getID() +" related via 1st TestResult to " + targetfield + "in Item " +issueDeltaBean.getID()); 
// edit the target 
try { 
issueDeltaBean.setFieldValue(targetfield, value ); 
// optional log this operation in the items itself 
if (commentfield != null){ issueDeltaBean.setFieldValue(commentfield, msg );}
catch (e) { logDebug(e); }

HTH Matthias


Hello Matthias,

That is very similar.

The difference is that I am attempting to bypass the whole "create related" process, show the user that a Defect has been created, and not require waiting for schedule trigger to process the defect.

Currently, the Defect item gets created when test result is saved. If the user edits it, then it is processed the same as the schedule trigger.

Ideally, the test result relationship field would be uneditable, and the defect would be fully processed when test result is saved.