Want to update ref_num

[Mayur Malhotra]

Hello ,

 

There is a requirement to update ref_num as and when end user changes the type field value(want to give to analyst) values Incident, Problem, Request in Cr object.

So I have used Spell macro with trigger on update of type field.

I have used function 'send_wait(0, this, "call_attr", "ref_num", "set_val", varref_num, "SURE_SET");

 

Currently, we are prefixing the IN for incident and SR for Request, as and when user change the type field from incident to request, we need to change the IN to SR. I have used the function gsub for replacing IN to SR or viceversa.

But I am getting error "Error setting 'Can't modify attr after initial check in' " on changing the type value from drop down in CR object forms i.e. Incident, Problem, Request. like System not allowing us to update the ref_num using send_wait function.

 

Please guide.

 

Thanks

Mayur

[Jon_Israel]

Hi Mayur,

Technically we dont support a mechanism of changing a ticket from one type to another - it can only be done via a customization, which I am assuming you have in place.   That said, the reason why the system does not allow you to change the refnum value of a ticket is because it may be used as a reference in other areas of the product, thus if it were changed, it could leave a dangling reference in the database.  Once an initial check-in is done at the first save of a ticket, the code will not allow you to change that refnum value.

I am not sure of a way around that.

Jon I.

[Mayur Malhotra]

Hi Jon,

 

Thanks for the update.

I was assuming that all the references are being taken care by Persid rther than ref_num of cr object. If its not like the case, then I would also like to know which tables it can affect so that we can change them as well.

 

Thanks

[Jon_Israel]

I am not sure of which tables or other product integrations can reference the refnum off hand.  You are correct that most things do reference tickets by way of a Persid.   I will try to find out some more info for you, but I dont think it would be something that we would be able to change, especially since we dont support the customization that allows you to change tickets from one type to another.  That falls outside of the ITIL standards - they say that you would generate one ticket type FROM another ticket type, but you wouldnt CHANGE a ticket from one type to another.

Jon

[Jon_Israel]

Hi Mayur,

So after some discussion and some more research on my side I now understand why the guardrail was put in place.  Refnum is used in things like notifications, and by maileater for updating a ticket.  So for example, if you have a request that is SR1234, and an outgoing notification was sent to the end user, then that ticket was changed to an incident so the refnum becomes IN1234, and the end user replies to that email after that change is made, if maileater is picking up that response, it wouldnt be able to update the ticket because it wouldnt find SR1234 anymore since it changed to IN1234.  

Additionally for integrations with outside products, typically it would reference the refnum as that is what is exposed many times for outside integrations to pick up on.  So those outside integrations would break as well.

So the only option is to create a new ticket from the existing one, OR get rid of the prefixes, so that the refnum doesnt need to change when you change the ticket type.

Hope this helps,

Thanks,
Jon

[Tammy Zadell]

I just wanted to add that even if he removes the prefixes, the ticket can't be updated via an email reply after it has been converted because you can't specify more than one object to be updated in the mail rule. 

 

See this post:  https://communities.ca.com/thread/241784585-maileater-filter-syntax-help

And here's the idea that I submitted:  https://communities.ca.com/ideas/235736982-maileater-rules-to-update-any-object-or-multiple-objects

 

Tammy

[Jon_Israel]

AHH yes - thank you Tammy , you are correct.  Thanks for mentioning this, I remember you posted the idea for that!!

Jon

[Mayur Malhotra]

Thanks Chris for all the clarifications. I accepted this helpful and Its not recommended to change it.

Thanks once again.

 

Thanks

Mayur Malhotra

[Legacy User]

hi,

 

depending on SDM schema:

ref_num STRING WRITE_NEW REQUIRED { UI_INFO "AUDITLOG" ; } ;

ref_num can be modified only on creation stage, as a workaround I recommend to publish your own attribute and use it in your decided way

 

Regards,

cdtj