General Technical Discussions for Service

Get Involved. Join the Conversation.

Topic

    Adam Darbyshire
    Expired incidents in custom processes
    Topic posted October 6, 2014 by Adam DarbyshireRed Ribbon: 250+ Points 
    162 Views, 2 Comments
    Title:
    Expired incidents in custom processes
    Content:

    Hi Everyone,

    I'm trying to make a custom process that will trigger on a new incident created based on the queue of the expired incident it replaces.

    1. If expired incident queue = x
    2. move new incident to queue x

     

    I have some code at the moment but it is based on scraping the text 'Incident created due to reply to expired incident' out of the incident threads, which is far from ideal.

    I saw someone at one point mention that there was a $incident->expired variable that could be used to access the old incident data however I can't for the life of me find that old link.

     

    Does anyone know how to access expired incident data in custom processes without having to scrape text?

     

    Cheers

    Adam

    Version:
    Nov13

    Comment

     

    • Allan Schrum

      Looking at the code it seems that this message is inserted by techmail when processing a response and finding that the incident is already closed (and closed for certain period of time). Thus the new incident is created and a note is added that the incident was created due to being expired (using INC_CREATED_DUE_REPLY_MSG message base entry). There does not seem to be a specific flag that is set for this use case.

      Scraping text seems to be the only solution. However, this seems like a good product improvement to submit to the Idea Lab. Ideas submitted by customers get significant visibility.

      Regards,

      -Allan

    • Sebastiaan Draaisma

      Old topic but I will just add the info here for others to use.

      I will attach a report that will show the new & original incident.

      The report has 2 filters. One that filters on threads.entry_type which for INC_CREATED_DUE_REPLY_MSG is always a note. The second filters on the account that created the note which is always account id 1 (administrator).

      The report uses a custom script on 2 semi hidden columns (5 pixels width and play with borders to make it "hidden") where a regular expression is being tested on the thread and key. The key value comes from a report variable that will get the correct string through:

      substr(msg_lookup(25040),1,(instr(msg_lookup(25040),'%')) - 1)

      Because the report retrieves the correct string from the message base, this report should work on any OSVC language id and customized message base entries.

      The aditional information is retrieved from the database through a ROQL query and can easily be expanded. A similar solution with some aditional PHP would allow you to assign the new incident to the original queue, agent and other fields of interest.