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.