Sent this to a colleague yesterday so thought you might want to try it out.

  • It will close the Parent Ticket when the last child is closed
  • parent / children do not have to be part of a process but can be
  • It does not reopen the parent if a child gets reopened.
  • It must exist in every queue where children can exist. It fires when the children are saved
  • You can import it from this kpkg file: http://www.itninja.com/media/documents/Ticket-Rule-68.kpkg


Answer Summary:
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity



Hey GillySpy, this is exactly what I am trying to do. Been looking all over the interwebz for it. I cannot seem to build the logic in my head. I do not see anywhere to download the .ZIP you speak of. Is this a process you could share with me?

Answered 10/23/2012 by: JordanSPE
White Belt

  • I wouldn't mind looking at this either.
  • Sorry guys, this was temporarily lost in the migration process but can now be found here: http://www.itninja.com/media/documents/Ticket-Rule-68.kpkg
  • What do we do with the .kpkg file? I'm new to this
    • You import it as a resource: Settings>Resources>Import K1000 Resources
  • This doesn't seem to work for my KACE or even in MYSQL. it VERY much dislikes the <change_ID> field
    • In response to myself in the future: <CHANGE_ID> must actually be populated with a change ID which is generated when a change is the made to the ticket, so the ticket rule must be tested by manually entering a change id from the HD_TICKET_CHANGE list or by putting it in a test queue and actually updating a ticket.
Please log in to comment
This content is currently hidden from public view.
Reason: Removed by user request
For more information, visit our FAQ's.


The <change_ID> is only available on saving (or run now) not in the View search result.

Also if you have modified the status names in the ques, you will be better off using S.State in the update query than the S.Name.


Answered 01/08/2014 by: gbarvang
Senior Yellow Belt

Please log in to comment