Feature Request: Split Ticket

Just been reading:
http://www.ukuug.org/events/linux2002/papers/html/rt/#section_10

The author mentions that whilst RT helpfully allows us to merge tickets, it is not possible to split a ticket into two. That’s true: and it is annoying. My various clients/managers have problems inserting one ticket per issue, but for some bizzare reason seem to think two to ten items in a ticket is helpful (‘be grateful we’re using RT at all’ is the implication: one woman actually started handing me sticky notes and called them ‘tickets’…)

Anyway, is this something others find?

My current solution is to manuall create one ticket per issue mentioned in that initial ticket, and to make them all dependencies of that initial request. But it takes a while. I can imagine an interface linked from a ‘split’ button that would have the original ticket and a ‘more’ and ‘less’ button to add (and then remove) textarea fields containing the original ticket text; when that form is submitted it would create one ticket per textarea, and all created tickets would have the same priorities/etc, and optinoally all depend on the initial ticket.

Lee Goddard
Internet Application Analysis/Development
European Aviation Safety Agency
Administrative Directorate

E: Lee.Goddard@EASA.EU.int
T: +49 221 89990 3221
F: +49 221 89990 3721
W: www.easa.eu.int
:: Ottoplat 1, D-50679 Köln, Germany

Goddard Lee wrote:

Just been reading:
http://www.ukuug.org/events/linux2002/papers/html/rt/#section_10

The author mentions that whilst RT helpfully allows us to merge tickets, it is not possible to split a ticket into two. That’s true: and it is annoying. My various clients/managers have problems inserting one ticket per issue, but for some bizzare reason seem to think two to ten items in a ticket is helpful (‘be grateful we’re using RT at all’ is the implication: one woman actually started handing me sticky notes and called them ‘tickets’…)

Anyway, is this something others find?

Have you checked out Fork? Perhaps this can help you.

http://www.ukuug.org/events/linux2002/papers/html/rt/#section_10

Max

The author mentions that whilst RT helpfully allows us to merge
tickets,
it is not possible to split a ticket into two. That’s true: and it is
annoying. My various clients/managers have problems inserting one
ticket
per issue, but for some bizzare reason seem to think two to ten items
in a
ticket is helpful (‘be grateful we’re using RT at all’ is the
implication:
one woman actually started handing me sticky notes and called them
’tickets’…)

Anyway, is this something others find?

http://lists.bestpractical.com/pipermail/rt-users/2005-February/028697.h
tml

ticket is helpful (‘be grateful we’re using RT at all’ is the
implication:

Don’t you hate that!

one woman actually started handing me sticky notes and called them
’tickets’…)

Fancy.

Anyway, is this something others find?

Yes.

Goddard Lee wrote:

Anyway, is this something others find?

Sorry, My clipboard must have stuck with the link that I read from you!
Here’s the link to Fork. Sorry about that.

http://page.mi.fu-berlin.de/~pape/rt3screenshots/

Max

ticket is helpful (‘be grateful we’re using RT at all’ is the
implication:

Don’t you hate that!

More than you can imagine…

one woman actually started handing me sticky notes and called them
’tickets’…)

Fancy.

She was clearly insane, so I left the company.

Anyway, is this something others find?

Yes.

Nice to know :slight_smile:

Goddard Lee wrote:

Anyway, is this something others find?

On the one hand, I can think of times when it would be useful to split or
"clone" the current ticket. On the other hand, I’m not sure how you would
decide what information to carry over into the second ticket. You would need
a whole new user interface to help you decide – like a Jumbo page, but with
checkboxes indicating which fields to carry over.

Without such a user interface, you’ll end up deleting/modifying entries in
the split ticket so much that it would be easier to make a new blank ticket
in the first place and fill it in.

For computer help, call xHELP (x4357 or 713-348-4357)
On the web: http://helpdesk.rice.edu/
Rick Russell
Helpdesk Supervisor, Client Services
IT/Academic & Research Computing
Rice University
Voice: 713.348.5267 Fax: 713.348.6099
OpenPGP/GnuPG Public Key at ldap://certificate.rice.edu
761D 1C20 6428 580F BD98 F5E5 5C8C 56CA C7CB B669

rickr.vcf (560 Bytes)

signature.asc (252 Bytes)

From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Rick Russell

Goddard Lee wrote:

Anyway, is this something others find?

On the one hand, I can think of times when it would be useful
to split or “clone” the current ticket. On the other hand,
I’m not sure how you would decide what information to carry
over into the second ticket. …

Example: I get a ticket requesting "Can users log in to the wiki and RT
using LDAP?"
I usually have to add two dependencies there. I’d like to see a 'SPLIT’
button on this ticket’s page, which when clicked would reveal by
DOM-Magic ™ a further textarea element, containing the same text as
the first textarea element did when the page was loaded. At the same
time, the split button would be replaced with MORE and FEWER buttons, to
add/remove these, rather like the Advanced Search in Thunderbird.

Submitting the form would create as many tickets as there are text
areas; they’d all be created with the same properties.

I would like an option to chain dependencies sequentially, or to link
dependencies all to the original ticket.

I do still think the original ticket needs to be kept, so the request
can be answered in the user-expected form.

lee

Just as an aside, Thunderbird 1.5 with Enigmail said the signature on
this message failed verification.

OpenPGP Security Info

Error - signature verification failed

gpg command line and output:
C:\Program Files\GNU\GnuPG\gpg.exe --charset utf8 --batch --no-tty
–status-fd 2 --verify
gpg: Signature made 01/22/06 00:18:12 using DSA key ID C7CBB669
gpg: BAD signature from “Rick Russell (Rice) rickr@rice.edu

Rick Russell wrote:

Must pay attention to where messages are going.

Sorry.

Graham