AnsweredAssumed Answered

SDM-Creating ticket with CI vis SOAP-All tickets in GUI after show the same CI

Question asked by J_W on Mar 15, 2019
Latest reply on Mar 15, 2019 by J_W

Verified in SDM 14.1 and 17.1.  Multi-tenanted. Conventional architecture.


There is a support ticket open on this to check for a product defect but we need to verify our code and possible workarounds.


I have never seen this behavior and since we can reproduce it all environments on both versions, I hope someone else has seen it.


Steps to reproduce:


Application setup:

  • Multi-tenanted (we do not have a non-tenanted environment available)
  • CI's available for the tenants to test
  • Service account with SOAP permissions and tested.
  • SID for createRequest()


1.  Create ticket in SDM using the createRequest() method.




<soapenv:Envelope xmlns:soapenv="" xmlns:ser="">
            <!--1 or more repetitions:-->
            <string>This is CI test 1</string>
            <string>What is up with these CIs?</string>
            <!--1 or more repetitions:-->
            <!--1 or more repetitions:-->


2.  Verify the ticket is created with CI by opening in GUI. 

3.  Verify that the CI is NOT in the affected_rc field for the record in the MDB. (Note:  If you have made the CI field visible in your search results / list form, the CI will not be displayed here either).

4.  Change to Edit mode.  Save the ticket without making any changes.

--> The CI is now saved to the MDB and visible in the list form.

5.  Create a new Request via the GUI.

---> The CI field is populated with the same CI you used to create the first ticket via SOAP.  This is before you enter any information in the ticket and regardless of the tenant relationship to the CI.

--> Remove the CI, complete the ticket, and save it.  The CI is still displayed in the view mode.

6.  Open ANY existing ticket, active or inactive, that didn't have a CI and the same CI from the SOAP is displayed.


This behavior can be cleared by creating another request via SOAP, but send an empty string for the




We have tried using just affected_resource (without .name) with the CI's UUID, but it has no effect.


Any suggestions?