[Feature Request] Related Tickets

[pk4]

It seems to make a lot of sense to add the concept of related tickets.

In other helpdesk software, there is the concept of a "master ticket" and related slave tickets (one possible solution).

It seems like this design concept would help with the "which way to merge" discussion as well (even make it moot?)
If you had the "related tickets", then you could easily add an option to display the ticket with all of the related ticket messages merged in (or not). In this case, the merge could just be establishing a ticket relationship and closing/hiding/something the merged ticket. Then both sides of the merge would remain totally searchable.

Thoughts?

[Darryl Plunkie]

Could the ticket be tagged - either with a keyword or another ticket number - and you can see related tags in some manner?
Hmmm, just thinking, that wouldn't show the parent-child relationship, but you could tag one of them Master in addition to the situation/keyword/ticket number. This would allow two reps who receive calls simultaneously to both create a ticket, and the Supervisor/Team Lead deem one of them (with the most applicable information) as the master. New tickets could then have the same tag and when the problem is rectified you could easily see all tickets relating to that tag, check their checkboxes, and do a mass close of them.

Would that work for anyone else?

[joegeck]

Hey guys,

I'm going to go ahead and address each of these separately. First,

It seems to make a lot of sense to add the concept of related tickets.

In other helpdesk software, there is the concept of a "master ticket" and related slave tickets (one possible solution).

It seems like this design concept would help with the "which way to merge" discussion as well (even make it moot?)
If you had the "related tickets", then you could easily add an option to display the ticket with all of the related ticket messages merged in (or not). In this case, the merge could just be establishing a ticket relationship and closing/hiding/something the merged ticket. Then both sides of the merge would remain totally searchable.

Thoughts?

pk4, I'm going to take a guess that you're Paul K. and submitted this already as a request to JIRA, CHD-616

Not sure if you've been following up on that one, but Hildy@WGM closed that as a dupe and decided it better fits a slightly different ongoing request. So for pk4 or anyone who stumbles on this thread, the feature request that our developers are going to consider implementing instead is:

When merging tickets the original masks should still forward to the new ticket
http://www.wgmdev.com/jira/browse/CHD-174

Read up on that page for the game plan and you'll see that this will serve the overall goal of simply maintaining access to all merged tickets.


And secondly,

Could the ticket be tagged - either with a keyword or another ticket number - and you can see related tags in some manner?
Hmmm, just thinking, that wouldn't show the parent-child relationship, but you could tag one of them Master in addition to the situation/keyword/ticket number. This would allow two reps who receive calls simultaneously to both create a ticket, and the Supervisor/Team Lead deem one of them (with the most applicable information) as the master. New tickets could then have the same tag and when the problem is rectified you could easily see all tickets relating to that tag, check their checkboxes, and do a mass close of them.

Would that work for anyone else?

As was suggested earlier I think the developers are leaning towards implementing CHD-174 . That's not to say this won't work. In fact this is radically different enough where others in the Cerb4 community might prefer a system like this. Could be instead of or an addition to the existing plan, who knows?

So this goes out to the community who follows up on this thread, if you like this idea please head over to the following URL and vote up / comment Darryl's suggestion:

http://www.wgmdev.com/jira/browse/CHD-792

[peter_mcc]

Hi

I'm not sure the original poster wanted to merge all the tickets - just to show that they were related (like related bugs in Jira).

At least that's how I'd be interested to see it work!

peter