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)?

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 eventChild tickets might include:- IT setup of the roomIT setup of the equipmentfacilities setup of the roomcateringetc.

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.

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.

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?