Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Re-Open Ticket at Future Date Mod Idea

I think it would be awesome to have a mod that would allow a tech to close a ticket, with a field for a date that the ticket should be automatically re-opened.

Here's where we would use this, although there are probably a lot of uses:
A user requests event set up help for an event in three months. Rather than leave the ticket open for three months (messes with stats, clutters ticket views), the tech could close the ticket, fill in a "re-open date". On that date, the ticket would magically re-appear in the user's queue.

Thanks for any ideas you may have! 

Thanks!

-Stead
Eugene, OR

Comments

  • What sort of use case would you envision for this?

    Why have the ticket re-open instead of having a new one opened (via API and cron)?
  • I think the most common case would be when an end-user opens up a help ticket for a certain task that requires follow up at a much later date. Currently, we close the ticket and it's off our plate. Unless we make a calendar entry, the task is easily forgotten.

    An example might be the event set up in the original post, or a software install that can't happen until the user purchases the software. Instead of having the ticket hanging out for a few weeks open, or closing the ticket and forgetting to follow up, the ticket could be closed and then open itself back up for follow up.

    I do like the method you suggested as well about cron & using the API to create a new ticket. The one area that this might be tricky is that it would mess with statistics. I think this would essentially double the tickets that had a follow up needed. One for the original ticket, and one for the newly created ticket.

    For the sake of simplicity, having a date box on the ticket close would seem like a good solution in our environment, but perhaps not others. It would still require some sort of cron and API to look for tickets marked for follow up, and then check if the date was current or in the past, then re-open the ticket.

    Thanks!
  • We run across the situation like "An example might be the event set up in the original post, or a software install that can't happen until the user purchases the software." and close the tickets also.  We've trained staff to not open a ticket until something is actionable. The onus is on the staff to open a ticket when they are actually ready for us to do the work.  It's a culture change rather than a systematic one. 

    But over all I can see a use case for this type of thing.  Back in 1.6 I had a pending mod, but it never became as robust as I wanted to make it.  I'm still hoping that the devs will implement a pending status and all the minor things that entails. :)
  • I was reading through the use-case for this idea above and think it is has its challenges. If a ticket is or needs to be re-opened after being closed then in my opinion it was not really resolved in the first place. For the alternative scenario where an issue gets created for an item in the future then the concept which should be implemented is a separate field similar to that used when I was at a very large company. The ticket should be created using a category with an appropriate SLA so it doesn't get flagged. If this is a ticket for way out in the future and a client is then responsible for responding with additional details then a secondary status field should be used and updated. We used to use "Response with" as a field to track this (sounds very similar to the Pending field above). Using the time where the response was with YOU and not your client that is what the SLA is then calculated from.


    The third option which I think is OSTickets greatest opportunity for improvement is defined ticket types/ categories. I initially build a Linking and Categorization mod for 1.6 but have ran out of time to port it. I would propose that OSticket for items like events should have a client facing calendar which can be enabled or disabled. When an event is created in the calendar then the customer can create one or more tickets for various items related to the event and set the "open date" for those items. to me this would be a great and clean way of implementing a fix for items like events.The real point of drawing attention to my old linking mod is that the "proper" way of implementing this is to have one master ticket for the event itself and child tickets for the various tasks....but I digress.
  • We run across the situation like "An example might be the event set up in the original post, or a software install that can't happen until the user purchases the software." and close the tickets also.  We've trained staff to not open a ticket until something is actionable. The onus is on the staff to open a ticket when they are actually ready for us to do the work.  It's a culture change rather than a systematic one.  But over all I can see a use case for this type of thing.  Back in 1.6 I had a pending mod, but it never became as robust as I wanted to make it.  I'm still hoping that the devs will implement a pending status and all the minor things that entails. :)
    The software example above is a great example of why tickets in certain scenarios, read opened in categories, needs to have master and child relationships alongside a dependant pending status. In a certain ticket category we should be able to trigger certain task ticket to be created for a better use of resources.and more appropriate ticket count. 

    I could see this concept being relevant to just about anyone.  Ex:
    for softwware purchase there would be an approve and order task ticket and an install task ticket set to pending status until the approve and order request is completed. Both of these would sit under the master ticket for the users request.

    Using the previous example of an event:
    Master ticket for the event
    Child tickets might include:
    - IT setup of the room
    IT setup of the equipment
    facilities setup of the room
    catering
    etc.
    reporting concepts would need to be modified for a setup like this but would be pretty easy to bend you mind around. reports for number of events would be generated based on the master ticket counts and total man hours or time spent on the event would be calculated based on the time spend on the combination of all child tickets. Same reporting concepts would apply to the software example above.
  • Thanks for your posts, Rich_C! I agree with you - a ticket status of Pending seems much more appropriate rather than just closed.

    The child ticket system sounds interesting to us. We run into your exact example.

    I'll noodle on how we might train our staff to enter tickets for actionable events only, as that could solve it probably fairly easily.

    Thanks!
  • I am currently trying to find some documentation on the plugins and how they should be developed....once I can find some info I can start my migration process. I'm also hoping that using the plugin architecture it will make this newer (better) faster dev release of OSticket more manageable for me to keep up with my mods.
  • Awesome! Sounds like a great addition! Thanks Rich!
  • Another use case where it could be useful is orders management: ticket "ticks" as long as the order is ready. Then it gets "paused" while supplier sends the goods. When goods arrive, ticket is unpaused and continues ticking.
    Even better, there could be different queues (2 days for pre-order, 14 days for shipment, then another 2 days to check the goods and install 'em). But maybe this would require too many modifications to current core?
Sign In or Register to comment.