Forking a new ticket from a correspondance

RT Users
1

Hello,

We are currently implementing RT as a technical support tracker and find it
very nice and flexible. Furthermore, development seems rather active. There
are however some issues we were wondering about.

  • Is it possible to fork a new ticket from a correspondance. Sometimes, a
    requestor will use a previous message (or ticket-stub) to submit a new
    request. It would then be desirable to fork a new ticket from this
    crrespondance instead of adding it to the previous ticket. Sort of an inverse
    merge.

  • Additionnaly, is it possible to delete an action or correspondance from a
    ticket. In the example above deleting the correspondance (or at least
    disabling it) in the previous ticket would be helpfull to alleviate clutter.

I took a look at the FAQ and bug report (for wishlist items) and couldn’t find
anything on this.

Thank you,

Mathieu
./ Mathieu Dub�-Dallaire, B.Eng. _______________________________
| Application Consultant / Consultant en applications |
| Opal-RT Technologies tel: (514) 935-2323 |
| 1751 Richardson, suite 2525 fax: (514) 935-4994 |
| Montr�al (Qu�bec) Canada, H3K 1G6 |
|__ mathieu.dube-dallaire@opal-rt.com _ http://www.opal-rt.com __|

2
  • Is it possible to fork a new ticket from a correspondance. Sometimes, a
    requestor will use a previous message (or ticket-stub) to submit a new
    request. It would then be desirable to fork a new ticket from this
    crrespondance instead of adding it to the previous ticket. Sort of an inverse
    merge.

We’ve been bitten by this before as well. We have some people that will
reply to a long resolved (months ago) ticket with all their new issues.

It would be nice if there was a status type “closed” (for lack of a better
example) that would automatically force correspondence referencing the
closed ticket to a brand new ticket and not touch the old one. Status
like “resolved” would still work as they do now, i.e. reopen the existing
ticket.

Bill

3

At 10:24 Uhr -0800 5.4.2002, bill@daze.net wrote:

It would be nice if there was a status type “closed” (for lack of a better
example) that would automatically force correspondence referencing the
closed ticket to a brand new ticket and not touch the old one. Status
like “resolved” would still work as they do now, i.e. reopen the existing
ticket.

I don’t think this would work, since the user might actually supply
information related to the old ticket. And how would you decide
whether to “close” or to “resolve” a ticket?
IMO, this forking has to be done manually. For example, there could
be a link “Make this a new ticket” next to each item of
correspondence.

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

4

At 10:24 Uhr -0800 5.4.2002, bill@daze.net wrote:

It would be nice if there was a status type “closed” (for lack of a better
example) that would automatically force correspondence referencing the
closed ticket to a brand new ticket and not touch the old one. Status
like “resolved” would still work as they do now, i.e. reopen the existing
ticket.

I don’t think this would work, since the user might actually supply
information related to the old ticket. And how would you decide
whether to “close” or to “resolve” a ticket?

Thinking about it (its ~2am atm, so this takes a bit for me right now),
its actually a simple time-based problem.

If a ticket is resolved, and new correspondence comes in on that ticket,
you have two possibilities on what the requestor intends. Firstly, if the
correspondence comes in within a short time of it being resolve, then its
most likely to be related to the original correspondence.

The other possibility is if the correspondence comes in a good time after
the ticket was resolve, in which case the likelihood is that the requestor
has simply replied to an old mail with a new issue.

This time-based behaviour would be easy to code up, however the 2.0.x
series of RT does make it slightly difficult to create a new ticket
transparently to the user and avoid adding correspondence on the
original ticket (if applicable as described above).

RT, The Next Generation, looks to have the possibility of Scrips being
executed before the ticket id is assigned (hrm, Scrips assigning the
ticket id), so this behaviour would be even easier to implement.

When you come down to it however, it is a user education issue of ensuring
that the lesson of ‘Do not reply to old issues with new ones, as the
tracking system will hate you’ is rammed into their minds sufficiently.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations
5

Hello,

We are currently implementing RT as a technical support tracker and find it
very nice and flexible. Furthermore, development seems rather active. There
are however some issues we were wondering about.

  • Is it possible to fork a new ticket from a correspondance. Sometimes, a
    requestor will use a previous message (or ticket-stub) to submit a new
    request. It would then be desirable to fork a new ticket from this
    crrespondance instead of adding it to the previous ticket. Sort of an inverse
    merge.

  • Additionnaly, is it possible to delete an action or correspondance from a
    ticket. In the example above deleting the correspondance (or at least
    disabling it) in the previous ticket would be helpfull to alleviate clutter.

I took a look at the FAQ and bug report (for wishlist items) and couldn’t find
anything on this.

Thank you,

Mathieu
./ Mathieu Dub�-Dallaire, B.Eng. _______________________________
| Application Consultant / Consultant en applications |
| Opal-RT Technologies tel: (514) 935-2323 |
| 1751 Richardson, suite 2525 fax: (514) 935-4994 |
| Montr�al (Qu�bec) Canada, H3K 1G6 |
|__ mathieu.dube-dallaire@opal-rt.com _ http://www.opal-rt.com __|