Split Ticket

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets. Then the support staffer doing the split
can edit the subject and content on each to divide
the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

Does anyone have a hack for that?

Does anyone have thoughts about the ideal version of
that feature?

Thanks in advance,

Tony Aiuto

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets.

Thats a fairly nifty and possibly damn useful suggestion.

the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

Personally I’m not that keen on popups, and I’d ensure that the original
ticket was listed as a parent for the newly-created tickets, but, its
workable.

Does anyone have a hack for that?

Not yet, but theres a few presentations coming up that I’ve already seen,
so I think its hackable in a few minutes.

Does anyone have thoughts about the ideal version of
that feature?

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

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets.

‘Funny coincidence’, we (staff@math…) were talking
about nearly the same Idea a few days ago, but so far
only about ‘copying the currently viewed ticket into a
new one’. So the ‘staffer’ would have to do this a few
more times in cases of ‘more multi multi-issue’-tickets.

My Idea (no realisation yet) was so far just to
duplicate the workings of the button for 'new ticket’
and I did hope it will be possible to get/insert
all the necessary parts into the new ticket…
(And than hit ‘back’ often enough, and do it again).

Can somebody knowledeable give me hint whether this
is a good direction to start (and by this also start
top learn how adapt RT to our local needs :slight_smile:

Stucki

Christoph von Stuckrad * * |nickname |stucki@math.fu-berlin.de
Freie Universitaet Berlin |/_*|‘stucki’ |Tel(days):+49 30 838-75 459|
Fachbereich Mathematik, EDV|\ |if online|Tel(else):+49 30 77 39 6600|
Arnimallee 2-6/14195 Berlin
* |on IRCnet|Fax(alle):+49 30 838-75454/

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets.

‘Funny coincidence’, we (staff@math…) were talking
about nearly the same Idea a few days ago, but so far
only about ‘copying the currently viewed ticket into a
new one’. So the ‘staffer’ would have to do this a few
more times in cases of ‘more multi multi-issue’-tickets.

My Idea (no realisation yet) was so far just to
duplicate the workings of the button for 'new ticket’
and I did hope it will be possible to get/insert
all the necessary parts into the new ticket…
(And than hit ‘back’ often enough, and do it again).

Can somebody knowledeable give me hint whether this
is a good direction to start (and by this also start
top learn how adapt RT to our local needs :slight_smile:

How much can one do with backend manipulation, instead of using the
frontend?

Seems a lot of info is stored within the SQL tables, but is everything
there to actually insert data via other methods, yet still allow the
frontend to read the new data/modifications?

I know I’d rather code SQL queries than try and break RT :slight_smile:

Andy.

Hello,–On Dienstag, 29. Oktober 2002 9:55 Uhr -0500 Tony Aiuto tony@ics.com wrote:

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets. Then the support staffer doing the split
can edit the subject and content on each to divide
the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

I would like to follow up with an extended szenario of this I have in mind:

It would be nice, if you not only can split a ticket but “fork” it in the
following way:

For a given ticket, have a button (or sth. equivalent) to create a number n
of child tickets on which the original ticket depends. This child tickets
might start wih the same data of the original ticket, but that should be
extendable.

The original ticket will be set to stalled and the created tickets to new.

If all of the created tickets are resolved, the original ticket’s status
should automatically change to “open” again and so reappear in the list of
the owner, who can then decide whether it is resolved now or not.

If some correspondance is added to one of the resolved child tickets not
only the child ticket should be reopened but also the original parent
ticket.

As Stucki (stucki@math.fu-berlin.de) has written in another followup in
this thread, we could spend some time here to contribute to this issue, if
there were some hints, in which directions to go.
My scenario do not only affect data-representation or -presentation but
buisiness logic, so I am not sure how to find the correct hooks for
patching.

Any tips?

Best Regards,
Dirk.

Dr. Dirk Pape (Leiter des Rechnerbetriebs)
FB Mathematik und Informatik der FU-Berlin
Takustr. 9, 14195 Berlin
Tel. +49 (30) 838 75143, Fax. +49 (30) 838 75190

I need a feature that will let me split a ticket into
N tickets. … copy all the data from the original ticket
into the new tickets. Then … edit the subject and content
on each to divide the problems. Ideally, if you ask to split
into 3 tickets, you should get 3 popup dialogs which present
the subject and text of the original so that you can edit them
down as a single process.

[dirk]
I would like to follow up with an extended szenario of this I have in mind:
It would be nice, if you not only can split a ticket but “fork” it in the
following way:
For a given ticket, have a button (or sth. equivalent) to create a number n
of child tickets on which the original ticket depends. This child tickets
might start wih the same data of the original ticket, but that should be
extendable.

The original ticket will be set to stalled and the created tickets to new.

Yes. I think that’s useful as well. Sometimes it’s simply
independent requests in one ticket, and it’s a split.
Other times it’s a few related things that all must be completed
before the requestor is happy.

If all of the created tickets are resolved, the original ticket’s status
should automatically change to “open” again and so reappear in the list of
the owner, who can then decide whether it is resolved now or not.

If some correspondance is added to one of the resolved child tickets not
only the child ticket should be reopened but also the original parent
ticket.

That sounds like it would work.

As Stucki (stucki@math.fu-berlin.de) has written in another followup in
this thread, we could spend some time here to contribute to this issue, if
there were some hints, in which directions to go.
My scenario do not only affect data-representation or -presentation but
buisiness logic, so I am not sure how to find the correct hooks for
patching.

As my original post said, I need this feature. Some intial
replies pointed me at a Clone feature posted in the list
last year some time. Thank you for that pointer, but it did
not really do what I needed, so I’ve been implementing it myself.

Here’s where I am in the design/implementation

I’ve added an OnSplit condition. This is important for me
because I want to send an email saying. “We split your
request into several parts. This is the Ticket # for
this new part…”. This has deep interactions with
the transaction history.
- we don’t want a split to trigger an OnCreate condition.
That would send the wrong mail in most cases.
- I want the newly created tickets to have a
create event in the history, otherwise all the
places in the code which check for Create events
have to check for Create or Split. That ripple
would be bad.
- I would like the original ticket to have a
transaction record which says 'Split into ticket M’
and the new ticket to have one which says 'Split from
ticket N". The OnSplit event should only be fired
from the context of the new ticket.
I’m playing with several ways to do this, none of which I’m
particularly happy with yet. What I’m about to try
is adding new transaction types for Split & Fork, mostly
so that there are good markers in the history.

The question now is if there should be two distinct conditions
for Split/Fork, or if one suffices. Either way, there is
probably something special about the condition, because a
split will cause a transaction in both the original and new
ticket histories. I only want on condition to be triggered.
I welcome philosophical input on this issue.

Rather than popup-dialogs (as I said in my first post), I’m
building a Split.html page. It will display the ticket
subject and the content of the creation transaction.
Below that it displays them again, as editable fields,
but labeled to indicate that they belong to the new ticket.

You change the subject and content as appropriate and press
submit. You get the page again, but with the addition
of the split out ticket (non-editable) and the links to
the original or split ticket. This should make it fairly
easy to to a bunch of splits in a row.

I think I could incorporate Dirk’s suggestion on the
same page. Instead of ‘Submit’ there would be separate
buttons for ‘Split’ and ‘Fork’.

Any other ideas and suggestions would be welcome.

-tony

I’d suggest a different way of thinking about it. We have an idea for the
concept of “birthing” tickets – that is, taking a parent ticket and "birthing"
a child ticket which already has some info in it (ie, who is the parent). I
can imagine that some of the default info might be the same, like “subject” and
maybe even text.

Basically, I can imagine that happening by combining the features of
"comment"ing on a message and creating a new ticket – you click a “birth a new
ticket” button from one of the parts of a ticket (links?), and you get the
"create a new ticket" screen, where the queue, initial body, subject, parent
and requestor are already filled in for you (which you can modify).

My imagination is much better than my perl skills, unfortunately. The people
who’ve actually developed for RT can illuminate whether or not my idea is pure
fantasy or a good framework.

-Sheeri Kritzer
Systems Administrator
University Systems Group
Tufts University
617-627-3925
sheeri.kritzer@tufts.edu

Quoting “Chr. von Stuckrad” stucki-rt-users@math.fu-berlin.de:> On Tue, Oct 29, 2002 at 09:55:22AM -0500, Tony Aiuto wrote:

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets.

‘Funny coincidence’, we (staff@math…) were talking
about nearly the same Idea a few days ago, but so far
only about ‘copying the currently viewed ticket into a
new one’. So the ‘staffer’ would have to do this a few
more times in cases of ‘more multi multi-issue’-tickets.

My Idea (no realisation yet) was so far just to
duplicate the workings of the button for 'new ticket’
and I did hope it will be possible to get/insert
all the necessary parts into the new ticket…
(And than hit ‘back’ often enough, and do it again).

Can somebody knowledeable give me hint whether this
is a good direction to start (and by this also start
top learn how adapt RT to our local needs :slight_smile:

Stucki


Christoph von Stuckrad * * |nickname |stucki@math.fu-berlin.de
Freie Universitaet Berlin |/_*|‘stucki’ |Tel(days):+49 30 838-75 459|
Fachbereich Mathematik, EDV|\ |if online|Tel(else):+49 30 77 39 6600|
Arnimallee 2-6/14195 Berlin
* |on IRCnet|Fax(alle):+49 30 838-75454/


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets. Then the support staffer doing the split
can edit the subject and content on each to divide
the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

Why not just create N tickets, and each of them just says what should
be done, and have original ticket depends on those N tickets? The
link feature of RT is good enough. Once you’ve done this, it’s just
one click away to see the original ticket from children tickets, and
vice versa.

plasma

PC home �q�l�H�c�A�ӽнЦ�: http://www.pchome.com.tw
PC home Online �����a�x�G�|���Ĥ@�A�x�W�̤j���J�f����

Sheeri Kritzer wrote:
I’d suggest a different way of thinking about it. We have an idea for
the concept of “birthing” tickets – that is, taking a parent ticket and
"birthing" a child ticket which already has some info in it (ie, who is
the parent). I can imagine that some of the default info might be the
same, like “subject” and maybe even text.

That’s about what my implementation is evolving towards. When you
split/fork a ticket you get a clone of the first ticket but
with a potentially new subject and text of the creation
transaction. The original ticket is a parent of the copy.
There is also a “split” transaction type, which shows
up in the parent to mark that this happened.

plasma,

I’ve done that. However, it’s a pain in the ass when someone makes a ticket
with 5 items in it to create 4 other tickets, pare things down, and change the
parent ticket. It’s the same # of clicks if you “birth” a ticket, but the
information would be passed down already so you don’t have to copy/paste and
remember the parent ticket #, change the owner, click the queue, etc.

-Sheeri Kritzer
Systems Administrator
University Systems Group
Tufts University
617-627-3925
sheeri.kritzer@tufts.edu

Quoting plasma plasmaball@pchome.com.tw:

Here is my version 1 hack for doing a split ticket like I asked
about a few week ago. Some people seemed interested in such
a feature so I’m making it available.

I’m not totally happy with the implementation yet, but I think
it’s stable enough for people to use.

If someone can’t deal with the uuencoded file, I can email it
to them.

-Tony Aiuto

begin 664 split.tar
M<W!L:70OM```````````````````````````````````````````````````````````` M`````````````"`@-#`W-34`("`@(#0S-``@("`@-S8U`"`@("`@("`@("`@ M,"`@-S4V,C(T-C$V,B`Q,#,U-@`@-0`````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````!U<W1A<B`@`'1O;GD` M````````````````````````````````````=&]N>0`````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````!S<&QI="]214%$344M<W!L:71T:6-K970````` M```````````````````````````````````````````````````````````` M````````````````````````````````````(#$P,#8T-``@("`@-#,T`"`@ M("`W-C4`("`@("`@("`W-#(W("`W-38R,C0V,38R(#$S-S`R`"`P```````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````'5S=&%R("``=&]N>0````````````````````````````````````!T M;VYY```````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````I3<&QI="!4:6-K M970*"E=E9"!.;W8@(#8@,3$Z,#4Z,3`@15-4(#(P,#(*"E1O;GD@06EU=&\* M=&]N>4!I8W,N8V]M"@H*1&5S8W)I<'1I;VX*"E1H:7,@:7,@82!S970@;V8@ M;6]D:69I8V%T:6]N<R!T;R!S=7!P;W)T(&$@<W!L:70@=&EC:V5T"F-A<&%B M:6QI='D@:6X@4E0N("!4:&4@9V]A;"!I<R!T;R!P<F]V:61E(&$@<VEM<&QE M('=A>0IT;R!F;W)K(&]F9B!A(&-H:6QD(&]F(&$@=&EC:V5T('=H:6-H(&-O M;G1A:6YS(&]N;'D*82!P;W)T:6]N(&]F('1H92!O<FEG:6YA;"X@("!4:&ES M(&ES('1O(&%I9"!T:&4@<W5P<&]R=`IT<FEA9V4@<&5O<&QE('=H96X@8W5S M=&]M97)S('-E;F0@;75L=&EP;&4L('5N<F5L871E9`IR97%U97-T<R!I;B!A M('-I;F=L92!E;6%I;"P@86YD('=E('=A;G0@=&AE(&%B:6QI='D*=&\@8VQO M<V4@;W5T('!O<G1I;VYS(&]F('1H92!R97%U97-T(&EN9&5P96YD86YT;'D* M;V8@=&AE(&]T:&5R<RX*"@HM(%1H92!4:6-K970@9&ES<&QA>2!P86=E(&=E M=',@82!N97<@;W!T:6]N("=&;W)K+U-P;&ET)PHH22!D;VXG="!K;F]W('=H M870@;F%M92!I<R!B971T97(@>65T+"!O<B!E=F5N(&EF('1H97)E"G-H;W5L M9"!B92!T=V\@9&EF9F5R96YT('1H:6YG<RD*"BT@5&AE('-P;&ET('!A9V4@ M<VAO=W,@>6]U"B`@=&AE(&]R:6=I;F%L('1I8VME="!S=6)J96-T(&QI;F4* M("!F;W(@96%C:"!C:&EL9"!O9B!T:&ES('1I8VME="!I="!S:&]W('1H870@ M8VAI;&0G<R!S=6)J96-T(&%N9`H)=&AE('1E>'0@;V8@=&AE(&-R96%T:6]N M(&UE<W-A9V4*("!"96QO=R!T:&%T(&ET(&1I<W!L87ES('1H92!O<FEG:6YA M;"!T:6-K970@<W5B:F5C="!A;F0*"71E>'0@87,@961I=&EA8FQE(&9I96QD M<RX*"BT@>6]U(&5D:70@=&AE('-U8FIE8W0@86YD('1E>'0@9&]W;B!T;R!T M:&4@9&5S8W)I<'1I;VX@;V8*"6%S('-I;F=L92!I<W-U92!A;F0@<')E<W,@ M<W5B;6ET+@H*+2!A(&YE=R!T:6-K970@9V5T<R!C<F5A=&5D(&%S(&$@8VAI M;&0@;V8@=&AE('!A<F5N=`H@('1H92!P87)E;G0@9V5T<R!A("=S<&QI="!I M;G1O)R!T<F%N<V%C=&EO;B<*"BT@=&AE(')E<75E<W1O<B!G971S(&%N(&5M M86EL(&9O<B!T:&4@;F5W(&-H:6QD+"!B=70@:70*("!E>'!L86EN<R!T:&%T M('1H92!O<FEG:6YA;"!W87,@<W!L:70@86YD('=H870@=&AI<PH@(&-H:6QD M(&-O;G1A:6YS+@H*+2!W92!G;R!B86-K('1O('1H92!S<&QI="!P86=E(&]N M('1H92!O<FEG:6YA;"!T:6-K970@<V\@>6]U"B`@8V%N('%U:6-K;'D@<W!L M:70@;V9F(&%N;W1H97(@:7-S=64N"@H*"E=A<FYI;F=S"@I4:&ES(&ES(&$@ M=V]R:R!I;B!P<F]G<F5S<RX@("!)(&]N;'D@<&%S<V5D(&ET(&%R;W5N9"!B M96-A=7-E"F]T:&5R('!E;W!L92!S965M960@9V5N=6EN96QY(&EN=&5R97-T M960@:6X@=&AE(&9E871U<F4N("!)"G=E;&-O;64@;W1H97(@:61E87,@86)O M=70@:&]W(&ET('-H;W5L9"!W;W)K(&)E='1E<BX*"E1H:7,@:7,@86X@:6YV M87-I=F4@:&%C:RX@($ET(&ES(&YO="!J=7-T(&$@9F5W(&YE=R!P86=E<RX* M270@<F5Q=6ER97,@82!N97<@5')A;G-A8W1I;VX@='EP92P@86YD('-O;64@ M8V]D92!T:&%T"DD@<F5A;&QY(&1O;B=T(&QI:V4@:6X@5&EC:V5T+G!M(&%N M9"!4<F%N<V%C=&EO;BYP;2X@(%1H90IC;V1E(&-O=6QD(&)E(&UU8V@@<VEM M<&QI9FEE9"!B>2!A9&1I;F<@86X@861D:71I;VYA;"!F:65L9`IT;R!T:&4@ M5&EC:V5T(')E8V]R9"P@8G5T($D@9&ED;B=T('=A;G0@=&\@870@=&AI<R!T M:6UE+@H*22!T:&EN:R!)(&AA=F4@:70@86QL(&AE<F4L(&)U="!)(&UA>2!N M;W0N("!)9B!Y;W4@9FEN9`IS;VUE=&AI;F<@:7,@;6ES<VEN9RP@<&QE87-E M(&-O;G1A8W0@;64@:6UM961I871L>2!A;F0*22=L;"!T<GD@=&\@9FEN9"!I M="X*"E1H97-E('!A=&-H97,@87)E('1O(%)4(#(N,"XQ-"X@("!)9B!Y;W4@ M87)E(&EN<W1A;&QI;F<*=&\@82!D:69F97)E;G0@=F5R<VEO;BP@>6]U('-H M;W5L9"!I;G-P96-T('1H92!P871C:"!F:6QE<PIC87)E9G5L;'D@8F5F;W)E M(&%P<&QY:6YG+@H*"DEN<W1A;&QA=&EO;@H*5&AE(&%R92`V('-T97!S('1O M(&EN<W1A;&QA=&EO;BX@("!9;W4@<F5A;&QY('-H;W5L9"!B92!U<VEN9PIA M(')E=FES:6]N(&-O;G1R;VP@<WES=&5M(&]N('EO=7(@:6YS=&%L;&%T:6]N M(2`@5&AE<F4@=VEL;`IB92!M;V1I9FEC871I;VYS('1O(#,@9FEL97,*"@EL M:6(O4E0O5&EC:V5T+G!M"@EL:6(O4E0O5')A;G-A8W1I;VXN<&T*"5=E8E)4 M+VAT;6PO5&EC:V5T+T5L96UE;G1S+U1A8G,*"@DQ+B!E9&ET(&%D9%]O;F-L M;VYE+G!L('1O('!O:6YT('1O('EO=7(@:6YS=&%L;&%T:6]N"@D))2!P97)L M(&%D9%]O;F-L;VYE+G!L"@DR+B!C9"!L:6(O4E0@86YD(&%P<&QY('1I8VME M="YP871C:"!A;F0@=')A;G-A8W1I;VXN<&%T8V@*"3,N(&-O<'D@4W!L:70N M:'1M;"!T;R!796)25"]H=&UL+U1I8VME=`H)-"X@8V0@5V5B4E0O:'1M;"!A M;F0@87!P;'D@=V5B<G1P871C:&5S"@D)=&AI<R!W:6QL('!A=&-H(%1I8VME M="]%;&5M96YT<R]486)S"@DU+B!#<F5A=&4@82!N97<@=&5M<&QA=&4@(E-P M;&ET5&EC:V5T(B!F;W(@=&AE(&YO=&EF:6-A=&EO;@H)("`@;V8@<W!L:70N M("!4:&4@9FEL92!S<&QI=%]T96UP;&%T92YS86UP;&4@:7,@=VAA="!)('5S M92X*"2`@(%=E('5S92`G8V%S92<@<F%T:&5R('1H86X@)W1I8VME="<@8F5C M875S92!W92!A<F4@;6EG<F%T:6YG"@D@("!F<F]M($-L87)I9GD@86YD(&]U M<B!C=7-T;VUE<G,@87)E('5S960@=&\@:70N"@D@("!.;W1E('1H92!E>'1R M96UE;'D@8W)A9G0@=7-E(&]F"B`@("`)"2)[)%1I8VME="T^365M8F5R3V8M M/DYE>'0M/E1A<F=E=$]B:BT^4W5B:F5C='TB"@D@("!T;R!P=6QL(&EN('1H M92!S=6)J96-T(&9R;VT@=&AE('!A<F5N="!T:6-K970N"@D@("!4:&ES(&ES M(&]N92!O9B!T:&4@=6=L:65S('1H870@;6%K97,@;64@=V%N="!T;R!A9&0* M"2`@(&$@)W!A<F5N="!T:6-K970G(&9I96QD('1O('1H92!T:6-K970@<F5C M;W)D+@H)-BX@061D(&$@4V-R:7`@;&EK92`@3VY#;&]N92].;W1I9GE!;&Q7 M871C:&5R<R]3<&QI=%1I8VME=`H*268@:70@:7,@;F]T(&]B=FEO=7,@:&]W M('1O(&1O('1H97-E('1H:6YG<RP@=&AE;B!Y;W4*<F5A;&QY('-H;W5L9"!N M;W0@8F4@:6YS=&%L;&EN9R!T:&ES('!A=&-H+@H*268@>6]U('=A;G0@=&\@ M=&%K92!A(&QO;VL@9FER<W0L(&)E9F]R92!M=6-K:6YG(&%R;W5N9"!W:71H M"G1H92!B87-E(%)4(&-O9&4Z(&1O('-T97!S(#,@86YD(#0@9FER<W0L(&UA M:V4@<V]M92!T:6-K970*82!C:&EL9"!O9B!A;F]T:&5R('=I=&@@=&AE(&5X M:7-T:6YG(&QI;FMS(&-A<&%B:6QI='DL(&=O"G1O('1H92!S<&QI="!P86=E M+B!O;B!T:&4@;W)I9VEN86P@=&EC:V5T(&%N9"!S964@:&]W(&ET(&QO;VMS M+@I)9B!Y;W4@=&AI;FL@:70@=VEL;"!S97)V92!Y;W4L('1H96X@9&\@=&AE M(')E<W0L(&]T:&5R=VES90IR979E<G0@5&EC:V5T+T5L96UE;G1S+U1A8G,* M"@I#<F5D:71S"@I?:79A;BP@=VAO('!O<W1E9"!A($-L;VYE(')O=71I;F4@ M=&\@<G0M9&5V96P@;&%S="!Y96%R+@IH='1P.B\O;&ES=',N9G-C:RYC;VTO M<&EP97)M86EL+W)T+61E=F5L+S(P,#$M075G=7-T+S`P,34U,BYH=&UL"F%N M9"!'<F%N="!-:6QL97(L('=H;R!P;VEN=&5D(&UE('1O(&ET+@H*0G)U8V4@ M0V%M<&)E;&PL($-H<FES=&]P:"!V;VX@4W1U8VMR860L($1I<FL@4&%P92!A M;F0@4VAE97)I($MR:71Z97(*=VAO('!R;W9I9&5D('-U9V=E<W1I;VYS(&]N M('1H92!R="UU<V5R<R!L:7-T('=H:6-H(&AE;'!E9`IM92!S:&%P92!T:&ES M"@H*5&]N>2!!:75T;PIT;VYY0&EC<RYC;VT*```````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````!S<&QI="]3<&QI M="YH=&UL
MM(#$P,#8T-``@("`@-#,T`"`@("`W-C4`("`@("`@("`V,C8S("`W-38R,C,V M-C(Q(#$R-#0R`"`P```````````````````````````````````````````` M
M`````````````````````````````‘5S=&%R("=&]N>0`````````````` M``````````````````````!T;VYY```````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````#PA+2T@4W!L:70N:'1M;`HM+3X*/"8@+T5L96UE;G1S+TAE861E M<BP@5&ET;&4@/3X@(E1I8VME="`C(BXD5&EC:V5T+3Y)9"`N(B`B+B14:6-K M970M/E-U8FIE8W0@)CX*"CPF("]4:6-K970O16QE;65N=',O5&%B<RP@5&EC M:V5T(#T^("14:6-K970L(&-U<G)E;G1?=&%B(#T^("=4:6-K970O4W!L:70N M:'1M;#]I9#TG+B14:6-K970M/FED("8^"@H\9F]R;2!-151(3T0]4$]35"!! M0U1)3TX](E-P;&ET+FAT;6P_06-T:6]N/41O4W!L:70F:60]/"4D5&EC:V5T M+3YI9"4^(CX*"CQT86)L93X*/'1R/CQT9#Y/<FEG:6YA;"!3=6)J96-T/"]T M9#X\=&0^/"4D5&EC:V5T+3Y3=6)J96-T?&@E/CPO=&0^/"]T<CX*/"$M+0H\ M='(^/'1D/FYE=R!O<FEG:6YA;"!S=6)J96-T.CPO=&0^/'1D/CQI;G!U="!N M86UE/2)S=6)J96-T(B!V86QU93TB/"4D5&EC:V5T+3Y3=6)J96-T?&@E/B(@ M4TE:13TB-3`B/CPO=&0^/"]T<CX*+2T^"CQT<CX\=&0^)FYB<W`[/"]T9#X\ M=&0^/&AR/CPO=&0^/"]T<CX*"B4@=VAI;&4@*&UY("1,:6YK(#T@)%1I8VME M="T^365M8F5R<RT^3F5X="D@>PHE"6UY("1M96UB97(@/2`D3&EN:RT^0F%S M94]B:CL*"0D\='(^/'1D/CQA(&AR968](CPE)%)4.CI796)0871H)3XO5&EC M:V5T+T1I<W!L87DN:'1M;#]I9#T\)21M96UB97(M/DED)3XB/E1I8VME="`\ M)21M96UB97(M/DED)3X\+V$^/"]T9#X*"0D\=&0^/&(^/"4D;65M8F5R+3Y3 M=6)J96-T)3X\+V(^/"]T9#X\+W1R/@H*)0D);7D@)'1R(#T@4E0Z.E1R86YS M86-T:6]N<RT^;F5W*"14:6-K970M/D-U<G)E;G15<V5R*3L*)0D))'1R+3Y, M:6UI="@@1DE%3$0@/3X@)U1I8VME="<L(%9!3%5%(#T^("1M96UB97(M/FED M*3L*)0D))'1R+3Y,:6UI="@@1DE%3$0@/3X@)U1Y<&4G+"`@(%9!3%5%(#T^ M("=#<F5A=&4G*3L*)0D);7D@)&EE;6%I;"`]("1T<BT^3F5X="T^365S<V%G M92T^3F5X=#L*"0D\='(^/'1D/B9N8G-P.SPO=&0^/'1D/CPE)&EE;6%I;"T^ M0V]N=&5N="4^/"]T9#X\+W1R/@HE('T@(`H\='(^/'1D/B9N8G-P.SPO=&0^ M/'1D/CQH<CX\+W1D/CPO='(^"CQT<CX\=&0^3F5W('1I8VME=#PO=&0^/'1D M/@H\:3YE9&ET('-U8FIE8W0@86YD('1E>'0@9&]W;B!T;R!T:&4@<VEN9VQE M('!R;V)L96T@>6]U('=A;G0@=&AE(&YE=R!C:&EL9"!4:6-K970@=&\@=')A M8VL\+VD^/"]T9#X\+W1R/@H*/'1R/CQT9"!A;&EG;CTB<FEG:'0B/G-U8FIE M8W0\+W1D/@H@("`@/'1D/CQI;G!U="!N86UE/2)S=6)J96-T,2(@=F%L=64] M(CPE)%1I8VME="T^4W5B:F5C='QH)3XB(%-)6D4](C4P(CX\+W1D/CPO='(^ M"CQT<CX\=&0@86QI9VX](G)I9VAT(CYT97AT/"]T9#X*("`@(#QT9#X\=&5X M=&%R96$@;F%M93TB8V]N=&5N=#$B('=R87`](G9I<G1U86PB(&-O;',](C<P M(B!R;W=S/2(Q-2(^/"4D:6YI=&EA;$5M86EL+3Y#;VYT96YT?&@E/CPO=&5X M=&%R96$^/"]T9#X\+W1R/@H*/"]T86)L93X*"CPF("]%;&5M96YT<R]3=6)M M:70L($QA8F5L(#T^("=3<&QI="!4:&4@5&EC:V5T)RP@0V%P=&EO;B`]/B`B M0F4@<W5R92!T;R!E9&ET('1H92!S=6)J96-T(&%N9"!T97AT(&9O<B!T:&ES M(&YE=R!C:&EL9"P@=&AE;B`B+"!C;VQO<B`]/B`B(SDY,S,S,R(@)CX*"@H\ M+V9O<FT^"@H*/"5!4D=3/@HD:60@/3X@=6YD968*)$-R96%T92`]/B!U;F1E M9@HD4VAO=TAE861E<G,@/3X@=6YD968*)$-O;&QA<'-E9"`]/B!U;F1E9@H\ M+R5!4D=3/@H*/"5)3DE4/@IU<V4@4E0Z.E1R86YS86-T:6]N<SL*=7-E($U) M344Z.D5N=&ET>3L*"FUY("@D;&EN:VED+"`D;65S<V%G92P@)'1I9"P@)%1I M8VME="P@)&EN:71I86Q%;6%I;"P@0$%C=&EO;G,I.PH*)%1I8VME="`](&YE M=R!25#HZ5&EC:V5T*"1S97-S:6]N>R=#=7)R96YT57-E<B=]*3L*"G5N;&5S M<R`H)&ED*2!["B`@("!!8F]R="@G3F\@=&EC:V5T('-P96-I9FEE9"<I.PI] M"@HD5&EC:V5T(#T@3&]A9%1I8VME="@D05)'4WLG:60G?2D["G5N;&5S<R`H M)%1I8VME="T^0W5R<F5N=%5S97)(87-2:6=H="@G4VAO=U1I8VME="<I*2![ M"@E!8F]R="@B3F\@<&5R;6ES<VEO;B!T;R!V:65W('1I8VME="(I.PI]"@IU M;FQE<W,@*"14:6-K970M/D-U<G)E;G15<V5R2&%S4FEG:'0H)T-R96%T951I M8VME="<I*2!["@E!8F]R="@B3F\@<&5R;6ES<VEO;B!T;R!S<&QI="!T:6-K M970B*3L*?0H*(R!43T1/("T@=&AE<F4@<')O8F%B;'D@<VAO=6QD(&)E(&]T M:&5R(')I9VAT<R!P<F]T96-T:6]N<R!H97)E+`HC(&)U="!))VT@;F]T('-U M<F4@=VAA=`H*"FEF("AD969I;F5D("1!4D=3>R=!8W1I;VXG?2`F)B`D05)' M4WLG06-T:6]N)WT@97$@)T1O4W!L:70G*2!["@H);7D@)%%U975E(#T@;F5W M(%)4.CI1=65U92@D<V5S<VEO;GLG0W5R<F5N=%5S97(G?2D["0H)=6YL97-S M("@D475E=64M/DQO860H)%1I8VME="T^475E=64I*2!["@D@("`@06)O<G0H M)U%U975E(&YO="!F;W5N9"<I.PH)?0H@("`@"@EU;FQE<W,@*"11=65U92T^ M0W5R<F5N=%5S97)(87-2:6=H="@G0W)E871E5&EC:V5T)RDI('L*"2`@("!! M8F]R="@G66]U(&AA=F4@;F\@<&5R;6ES<VEO;B!T;R!C<F5A=&4@=&EC:V5T M<R!I;B!T:&%T('%U975E+B<I.PH)?0H@("`*"6EF("AD969I;F5D("1!4D=3 M>R=S=6)J96-T,2=]("8F("1!4D=3>R=S=6)J96-T,2=](&YE("<G*2!["@D) M;7D@*"1N97=#:&EL9"P@)'1R;V)J:60L("1M<V<I.PH)"2,@)%)4.CI,;V=G M97(M/G=A<FYI;F<H(D1O4W!L:70@,R(I.PH)"2@D;F5W0VAI;&0L("1T<F]B M:FED+"`D;7-G*2`]("14:6-K970M/E-P;&ET*"=3<&QI="<L("1!4D=3>R=S M=6)J96-T,2=]+"`D05)'4WLG8V]N=&5N=#$G?2D["@E]"@DC("125#HZ3&]G M9V5R+3YW87)N:6YG*")$;U-P;&ET(#0B*3L*"7!U<V@H0$%C=&EO;G,L(")4 M:6-K970@<W!L:70@9G)O;2`C)$%21U-[)VED)WTB*3L*"2,@)$%21U-[)VED M)WT@/2`D5&EC:V5T+3YI9#L*?0H*(R!'871H97(@<W5B:F5C="!A;F0@:6YI M=&%L(&UE<W-A9V4@9G)O;2!O<FEG:6YA;"!T:6-K970*"FUY("1T<F%N<V%C M=&EO;G,@/2!25#HZ5')A;G-A8W1I;VYS+3YN97<H)%1I8VME="T^0W5R<F5N M=%5S97(I.PHD=')A;G-A8W1I;VYS+3Y,:6UI="@@1DE%3$0@/3X@)U1I8VME M="<L(%9!3%5%(#T^("14:6-K970M/FED*"DI.PHD=')A;G-A8W1I;VYS+3Y, M:6UI="@@1DE%3$0@/3X@)U1Y<&4G+"`@(%9!3%5%(#T^("=#<F5A=&4G*3L* M)&EN:71I86Q%;6%I;"`]("1T<F%N<V%C=&EO;G,M/DYE>'0M/DUE<W-A9V4M M/DYE>'0["@H\+R5)3DE4/@H*```````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````````````<W!L:70O=V5B M<G1P871C:&5S```````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`"`Q,#`V-#0`("`@(#0S-@("@-S8U"@("@(“@,3Q-2@-S4V,C(S M-C$S-BQ,SV-@@,```````````````````````````````````````````
MM``````````````````````````````!U<W1A<B`@`'1O;GD````````````` M````````````````````````=&]N>0`````````````````````````````` M
MM
MM```````````J*BH@5&EC:V5T+T5L96UE;G1S+U1A8G,),C`P,B\Q,"\R.2`Q M-CHU-SHQ.`DQ+C$*+2TM(%1I8VME="]%;&5M96YT<R]486)S"3(P,#(O,3$O M,#$@,38Z,34Z-#8**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`X,RPY,2`J*BHJ"B`@ M"2`@('1I=&QE(#T^("=/<&5N)PH@(`D@('T["B`@("`@('T*("!]"BT@"BT@ M"B`@"B`@"B`@:68@*&1E9FEN960@)'-E<W-I;VY[)W1I8VME=',G?2D@>PHM M+2T@.#,L.34@+2TM+0H@(`D@("!T:71L92`]/B`G3W!E;B<*("`)("!].PH@ M("`@("!]"BL@("`@(&EF("@D5&EC:V5T+3Y#=7)R96YT57-E<DAA<U)I9VAT M*"=#<F5A=&54:6-K970G*2D@>PHK("`@("`@("`@)&%C=&EO;G,M/GLG4W!L M:70G?2`]('L**R`@("`@("`@("`@("`@("`@<&%T:"`@/3X@(E1I8VME="]3 M<&QI="YH=&UL/VED/2(N)&ED+`HK("`@("`@("`@("`@("`@("!T:71L92`] M/B`G1F]R:R]3<&QI="<**R`@("`@("`@('T["BL@("`@('T*("!]"B`@"B`@ M"B`@:68@*&1E9FEN960@)'-E<W-I;VY[)W1I8VME=',G?2D@>PH````````` M
MM
MM
MM
MM
MM````````````````````````````````````````````````````````<W!L M:70O861D7V]N8VQO;F4N<&P````````````````````````````````````` M
M"`Q,#`V-#0`("`@(#0S-``@("`@-S8U`"`@("`@("`@,C8T-2`@ M-S4V,C(T,3,U,"`Q,S(U-@`@,``````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````!U<W1A<B`@`'1O;GD````` M````````````````````````````````=&]N>0`````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````C(2]U<W(O8FEN+W!E<FP@+7<*(PH*<&%C:V%G92!2 M5#L*=7-E('-T<FEC=#L*=7-E('9A<G,@<7<H)%9%4E-)3TX@)$AA;F1L92`D M3F]B;V1Y("13>7-T96U5<V5R("1I=&5M*3L*"G5S92!L:6(@(D5$250@+VAO M;64O<V5R=F5R<R]R=#(O;&EB(CL*=7-E(&QI8B`B141)5"`O:&]M92]S97)V M97)S+W)T,B]E=&,B.PH*(U1H:7,@9')A9W,@:6X@(%)4)W,@8V]N9FEG+G!M M"G5S92!C;VYF:6<["G5S92!#87)P.PH*=7-E(%)4.CI(86YD;&4["G5S92!2 M5#HZ57-E<CL*=7-E(%)4.CI#=7)R96YT57-E<CL*"B-C;VYN96-T('1O('1H M92!D8@HD4E0Z.DAA;F1L92`](&YE=R!25#HZ2&%N9&QE*"125#HZ1&%T86)A M<V54>7!E*3L*)%)4.CI(86YD;&4M/D-O;FYE8W0H*3L*"@HC4'5T('1O9V5T M:&5R(&$@8W5R<F5N="!U<V5R(&]B:F5C="!S;R!W92!C86X@8W)E871E(&$@ M57-E<B!O8FIE8W0*;7D@)$-U<G)E;G15<V5R(#T@;F5W(%)4.CI#=7)R96YT M57-E<B@I.PH*"B-N;W<@=&AA="!W92!B;V]T<W1R87!P960@=&AA="!L:71T M;&4@8FET+"!W92!C86X@=7-E('1H92!S=&%N9&%R9"!25"!C;&D*(R!H96QP M97)S("!T;R!D;R!W:&%T('=E(&YE960*"G5S92!25#HZ26YT97)F86-E.CI# M3$D@('%W*$-L96%N16YV($QO861#;VYF:6<@1$)#;VYN96-T(`H)"0D@("!' M971#=7)R96YT57-E<B!'971-97-S86=E0V]N=&5N="D["@HC0VQE86X@;W5T M(&%L;"!T:&4@;F%S=&EE<R!F<F]M('1H92!E;G9I<F]N;65N=`I#;&5A;D5N M=B@I.PH*(TQO860@971C+V-O;F9I9RYP;2!A;F0@9')O<"!P<FEV<PI,;V%D M0V]N9FEG*"D["@HC0V]N;F5C="!T;R!T:&4@9&%T86)A<V4@86YD(&=E="!2 M5#HZ4WES=&5M57-E<B!A;F0@4E0Z.DYO8F]D>2!L;V%D960*1$)#;VYN96-T M*"D["@H*)$-U<G)E;G15<V5R+3Y,;V%D0GE.86UE*"=25%]3>7-T96TG*3L* M"B,@>WM[(%-C<FEP0V]N9&ET:6]N<PH*;7D@0%-C<FEP0V]N9&ET:6]N<R`] M("@*"0D@("`@("`@>PH)"0E.86UE(#T^("=/;D-L;VYE)RP*"0D)1&5S8W)I M<'1I;VX@/3X@("=7:&5N(&$@=&EC:V5T(&ES(&-R96%T960@8GD@8VQO;FEN M9R<L"@D)"45X96--;V1U;&4@/3X@)T%N>51R86YS86-T:6]N)RP*"0D)07!P M;&EC86)L951R86YS5'EP97,@/3X@("=#;&]N92<L"@D)("`@("`@('TL"@D) M("`@("`@*3L*"B,@?7U]"G!R:6YT(")#<F5A=&EN9R!38W)I<$-O;F1I=&EO M;G,N+BXB.PH*=7-E(%)4.CI38W)I<$-O;F1I=&EO;CL*9F]R("1I=&5M("A` M4V-R:7!#;VYD:71I;VYS*2!["B`@("!M>2`D;F5W7V5N=')Y(#T@;F5W(%)4 M.CI38W)I<$-O;F1I=&EO;B@D0W5R<F5N=%5S97(I.PH@("`@;7D@)')E='5R M;B`]("1N97=?96YT<GDM/D-R96%T92@E)&ET96TI.PH@("`@<')I;G0@)')E M='5R;BXB+B(["GT*"G!R:6YT(")D;VYE+EQN(CL*"B125#HZ2&%N9&QE+3Y$ M:7-C;VYN96-T*"D["@H*,3L*"@`````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````!S<&QI="]T<F%N<V%C=&EO;BYP871C:``` M```````````````````````````````````````````````````````````` M````````````````````````````````````````(#$P,#8T-``@("`@-#,T M`"`@("`W-C4`("`@("`@("`T,#0Q("`W-38R,C0Q-S,P(#$T,#$T`"`P```` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M’5S=&%R(”=&]N>0`````````````````````````````````` M!T;VYY````````````````````````````````````````````````````
MM
MM`````````````````````````````````````````````````"HJ*B!4<F%N M<V%C=&EO;BYP;0DR,#`R+S$P+S,Q(#$X.C0W.C(U"3$N,0HM+2T@5')A;G-A M8W1I;VXN<&T),C`P,B\Q,2\P,2`Q-#HU,CHS-PHJ*BHJ*BHJ*BHJ*BHJ*BH* M*BHJ(#@Q+#@Y("HJ*BH*("`@("`@?0H@("`@("`@("`@"B`@("`@("-L971S M(&-R96%T92!O=7(@=')A;G-A8W1I;VX*("`@("`@;7D@)&ED(#T@)'-E;&8M M/E-54$52.CI#<F5A=&4H5&EC:V5T(#T^("1A<F=S>R=4:6-K970G?2P*("`) M("`@("`@("`@("`@("`@("`@("`@("`@("!4:6UE5&%K96X@/3X@)&%R9W-[ M)U1I;65486ME;B=]+`HA(`D)"0D@(%1Y<&4@/3X@)&%R9W-[)U1Y<&4G?2P* M("`)"0D)("!$871A(#T^("1A<F=S>R=$871A)WTL"B`@"0D)"2`@1FEE;&0@ M/3X@)&%R9W-[)T9I96QD)WTL"B`@"0D)"2`@3VQD5F%L=64@/3X@)&%R9W-[ M)T]L9%9A;'5E)WTL"BTM+2`X,2PY-R`M+2TM"B`@("`@('T*("`@("`@("`@ M(`H@("`@("`C;&5T<R!C<F5A=&4@;W5R('1R86YS86-T:6]N"BL@("`@(",@ M=&AI<R!H86-K97)Y(&ES('1O('-W:71C:"!T:&4@9&%T86)A<V4@='EP92!F M<F]M(&-L;VYE('1O(&-R96%T90HK("`@("`C($ET(&ES(&1E8F%T86)L92!I M9B!T:&ES(&ES(&)E='1E<B!T:&%N(&QE879I;F<@:70@:6X@=&AE(&1A=&%B M87-E"BL@("`@(",@86YD(')E<&QA8VEN9R!I;G-T86YC97,@=VAI8V@@<V5A M<F-H(&9O<B!T:&4@=&EC:V5T<R!W:71H(&%N"BL@("`@(",@;W(@8VQA=7-E M(&]V97(@0W)E871E(&%N92!#;&]N92X**R`@("`@;7D@)'1T>7!E(#T@)&%R M9W-[)U1Y<&4G?3L**R`@("`@:68@*"`D='1Y<&4@)B8@)'1T>7!E(&5Q("=# M;&]N92<I('L**R`))'1T>7!E(#T@)T-R96%T92<["BL@("`@('T*("`@("`@ M;7D@)&ED(#T@)'-E;&8M/E-54$52.CI#<F5A=&4H5&EC:V5T(#T^("1A<F=S M>R=4:6-K970G?2P*("`)("`@("`@("`@("`@("`@("`@("`@("`@("!4:6UE M5&%K96X@/3X@)&%R9W-[)U1I;65486ME;B=]+`HA(`D)"0D@(%1Y<&4@/3X@ M)'1T>7!E+`H@(`D)"0D@($1A=&$@/3X@)&%R9W-[)T1A=&$G?2P*("`)"0D) M("!&:65L9"`]/B`D87)G<WLG1FEE;&0G?2P*("`)"0D)("!/;&1686QU92`] M/B`D87)G<WLG3VQD5F%L=64G?2P**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`U,S@L M-30S("HJ*BH*+2TM(#4T-BPU-30@+2TM+0H@("`@("!]"B`@("`@(`H@("`@ M("!I9B`H)'-E;&8M/E1Y<&4@97$@)T-R96%T92<I>PHK(`EI9B@D<V5L9BT^ M3VQD5F%L=64I('L**R`)"7)E='5R;B@B5&EC:V5T('-P;&ET(&9R;VT@(BXD M<V5L9BT^3VQD5F%L=64I.PHK(`E]"B`@"7)E='5R;B@B5&EC:V5T(&-R96%T M960B*3L*("`@("`@?0H@("`@("!E;'-I9B`H)'-E;&8M/E1Y<&4@/7X@+U-T M871U<R\I('L**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`U-38L-38Q("HJ*BH*+2TM M(#4V-RPU.#@@+2TM+0H@(`D@("(@=&\@(BXD<V5L9BT^3F5W5F%L=64@*3L* M("`@("`@("!]"B`@("`@(`HK("`@("`C(%1H:7,@8V]D92!O;FQY(&UA:V5S M('-E;G-E(&EF('=E(&%C='5A;&QY(&AA=F4@(D-L;VYE(B!A<R!A('1R86YA M8W1I;VX**R`@("`@:68@*"1S96QF+3Y4>7!E(&5Q("=#;&]N92<I("`@('L* M*R`)<F5T=7)N*")4:6-K970@8VQO;F5D(&9R;VT@(BXD<V5L9BT^3VQD5F%L M=64I.PHK("`@("!]"BL@("`@(&EF("@D<V5L9BT^5'EP92!E<2`G1F]R:R<I M("`@('L**R`):68H)'-E;&8M/DYE=U9A;'5E*2!["BL@"0ER971U<FXH(E1I M8VME="!F;W)K960@:6YT;R`B+B1S96QF+3Y.97=686QU92D["BL@"7T**R`) M<F5T=7)N*")4:6-K970@9F]R:V5D(&9R;VT@(BXD<V5L9BT^3VQD5F%L=64I M.PHK("`@("!]"BL@("`@(&EF("@D<V5L9BT^5'EP92!E<2`G4W!L:70G*2`@ M("!["BL@"6EF*"1S96QF+3Y.97=686QU92D@>PHK(`D)<F5T=7)N*")4:6-K M970@<W!L:70@:6YT;R`B+B1S96QF+3Y.97=686QU92D["BL@"7T**R`)<F5T M=7)N*")4:6-K970@<W!L:70@9G)O;2`B+B1S96QF+3Y/;&1686QU92D["BL@ M("`@('T*("`@("`@:68@*"1S96QF+3Y4>7!E(&5Q("=#;W)R97-P;VYD)RD@ M("`@>PH@(`ER971U<FXH(D-O<G)E<W!O;F1E;F-E(&%D9&5D(BD["B`@("`@ M('T*```````````````````````````````````````````````````````` M
MM
MM
MM
MM
M``````````````````````````````````````````!S<&QI="]T:6-K970N
M<&%T8V@`````````````````````````````````````````````````````
M````````````````````````````````````````````````````````(#$P
M,#8T-@("`@-#,T`"`@("`W-C4`("`@("`@(#$R,C4S("`W-38R,C0Q-C<V M(#$S,#`W`"`P```````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````'5S=&%R("=&]N>0M!T;VYYM```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````"HJ*B!4:6-K970N<&T),C`P,B\Q,"\R.2`Q-CHR-3HQ,@DQ+C$*+2TM M(%1I8VME="YP;0DR,#`R+S$Q+S`V(#$U.C4U.C$U"BHJ*BHJ*BHJ*BHJ*BHJ M*@HJ*BH@,34W+#$V,B`J*BHJ"BTM+2`Q-3<L,38T("TM+2T*("`@($U)345/ M8FH@+2T@82!-24U%.CI%;G1I='D@;V)J96-T('=I=&@@=&AE(&-O;G1E;G0@ M;V8@=&AE(&EN:71I86P@=&EC:V5T(')E<75E<W0N"B`@"B`@("!+97EW;W)D M4V5L96-T+3QI9#X@+2T@86X@87)R87D@;V8@:V5Y=V]R9"!I9',@9F]R('1H M870@:V5Y=V]R9"!S96QE8W0**R`@($-R96%T951Y<&4@+2T@=6YD968@9F]R M(&YO<FUA;"!C<F5A=&4L(&]T:&5R=VES92!M87D@8F4@)T-L;VYE)PHK("`@ M0VQO;F5D240@+2T@:60@;V8@=&EC:V5T('=E(&-L;VYE9"!F<F]M(&EF($-R M96%T951Y<&4@/2!#;&]N90H@(`H@(`H@(%)E='5R;G,Z(%1)0TM%5$E$+"!4 M<F%N<V%C=&EO;B!/8FIE8W0L($5R<F]R($UE<W-A9V4**BHJ*BHJ*BHJ*BHJ M*BHJ"BHJ*B`Q.3,L,3DX("HJ*BH*+2TM(#$Y-2PR,#(@+2TM+0H@(`D)1'5E M(#T^('5N9&5F+`H@(`D)4W1A<G1S(#T^('5N9&5F+`H@(`D)34E-14]B:B`] M/B!U;F1E9BP**R`)"4-R96%T951Y<&4@/3X@)T-R96%T92<L"BL@"0E#;&]N M961)1"`]/B!U;F1E9BP*("`)"4!?*3L*("`*("`@("`@;7D@*"1%<G)3='(L M("11=65U94]B:BP@)$]W;F5R+"`D<F5S;VQV960I.PHJ*BHJ*BHJ*BHJ*BHJ M*BH**BHJ(#,Y,2PT,#(@*BHJ*@H@(`EP=7-H($!N;VY?9F%T86Q?97)R;W)S M+"`D:VUS9R!U;FQE<W,@*"1K=F%L*3L*("`@("`@?0H@(`HA("`@("`*("`@ M("`@"B`@("`@("-!9&0@82!T<F%N<V%C=&EO;B!F;W(@=&AE(&-R96%T90H@ M("`@("!M>2`H)%1R86YS+"`D37-G+"`D5')A;G-/8FHI(#T@"B$@"21S96QF M+3Y?3F5W5')A;G-A8W1I;VXH(%1Y<&4@/3X@(D-R96%T92(L"B`@"0D)("`) M5&EM951A:V5N(#T^(#`L(`H@(`D)"2`@"4U)345/8FH]/B1A<F=S>R=-24U% M3V)J)WTI.PH@("`@("`*("`@("`@(R!,;V=G:6YG"BTM+2`S.34L-#(S("TM M+2T*("`)<'5S:"!`;F]N7V9A=&%L7V5R<F]R<RP@)&MM<V<@=6YL97-S("@D M:W9A;"D["B`@("`@('T*("`*(2`@("`@:68H)&%R9W-[)T-L;VYE9$E$)WTI M('L*(2`)(R!I9B!W92!W97)E(&-R96%T960@8GD@8VQO;FEN9R!W92!M=7-T M(&UA:V4@82!L:6YK"B$@"2,@<VAO=VEN9R!O=7(@<&%R96YT+@HA(`DC($ET M(&UI9VAT('-E96T@8F5T=&5R('1O('!U="!T:&ES(&-O9&4@:6X@=&AE(%-P M;&ET(&9U;F-T:6]N"B$@"2,@=VAI8V@@8V%L;',@=&AI<RP@8G5T('=E('=A M;G0@=&AE(&QI;FL@:6X@<&QA8V4@8F5F;W)E"B$@"2,@=&AE(&-R96%T92!T M<F%N<V%C=&EO;B!H87!P96YS+"!S;R!T:&%T('1H92!T96UP;&%T90HA(`DC M(&UA>2!F;VQL;W<@=&AE(&QI;FL@86YD('!R:6YT('1H:6YG<R!F<F]M('1H M92!O<FEG:6YA;"!M97-S86=E"B$@"2,@4&5R:&%P<R!T:&4@8F5S="!W87D@ M:7,@=&\@861D(&$@9FEE;&0@=&\@=&AE(&1A=&%B87-E"B$@"B$@"2,@5V4@ M8W)E871E('1H92!L:6YK(&1I<F5C=&QY('1O('1H92!$0B!R871H97(@=&AA M;B!C86QL"B$@"2,@061D3&EN:RP@8F5C875S92!W92!D;VXG="!W86YT(&%N M(&5X=')A('1R86YS86-T:6]N(&-R96%T960*(2`);7D@)&QI;FL@/2!25#HZ M3&EN:RT^;F5W*"1S96QF+3Y#=7)R96YT57-E<BD["B$@"6UY("@D;&EN:VED M*2`]("1L:6YK+3Y#<F5A=&4H5'EP92`]/B`G365M8F5R3V8G+`HA(`D)"2`) M"4)A<V4@/3X@)'-E;&8M/FED+`HA(`D)"0D)5&%R9V5T(#T^("1A<F=S>R=# M;&]N961)1"=]*3L*(2`@("`@?0HA(`H@("`@("`*("`@("`@(T%D9"!A('1R M86YS86-T:6]N(&9O<B!T:&4@8W)E871E"B`@("`@(&UY("@D5')A;G,L("1- M<V<L("14<F%N<T]B:BD@/2`*(2`))'-E;&8M/E].97=4<F%N<V%C=&EO;B@@ M5'EP92`]/B`D87)G<WLG0W)E871E5'EP92=]+`H@(`D)"2`@"51I;65486ME M;B`]/B`P+"`**R`)"0D)3VQD5F%L=64@/3X@)&%R9W-[)T-L;VYE9$E$)WTL M"B`@"0D)("`)34E-14]B:CT^)&%R9W-[)TU)345/8FHG?2D["B`@("`@(`H@ M("`@("`C($QO9V=I;F<**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`V,#`L-C`U("HJ M*BH*+2TM(#8R,2PW,S@@+2TM+0H@("`@("!R971U<FX@*#`L("=$96QE=&EN M9R!T:&ES(&]B:F5C="!W;W5L9"!V:6]L871E(')E9F5R96YT:6%L(&EN=&5G M<FET>2XG+@H@(`D@("`@)R!4:&%T7"=S(&)A9"XG*3L*("!]"BL@(R!]?7T* M*R`**R`C('M[>R!S=6(@0VQO;F4**R`**R`]:&5A9#(@0VQO;F4**R`**R!# M;&]N97,@86X@97AI<W1I;F<@=&EC:V5T(&%N9"!I=',@8W)E871E('1R86YS M86-T:6]N.R!R971U<FYS('1H92!N97<@5&EC:V5T"BL@;V)J96-T+@HK(`HK M($%R9W5M96YT<R!A<F4**R`)<V5L9B`M(%1I8VME=`HK(`ES=6)J96-T("T@ M;W9E<G)I9&4@<W5B:F5C="`H;W!T:6]N86PI"BL@"6-O;G1E;G0@+2!O=F5R M<FED92!I;FET:6%L(&UE<W-A9V4@8V]N=&5N="`H;W!T:6]N86PI"BL@"BL@ M4F5T=7)N<SH@;F5W(%1I8VME="P@5')A;G-A8W1I;VX@3V)J96-T+"!%<G)O M<B!-97-S86=E"BL@"BL@/6-U=`HK(`HK('-U8B!#;&]N92!["BL@("!M>2`D M<V5L9B`]('-H:69T.PHK("`@;7D@)&YE=W-U8FIE8W0@/2!S:&EF=#L**R`@ M(&UY("1C;VYT96YT(#T@<VAI9G0["BL@"BL@("!M>2`D4F5Q=65S=&]R(#T@ M6R!M87`@)%\M/D5M86EL+"!`>R`D<V5L9BT^4F5Q=65S=&]R<RT^271E;7-! M<G)A>5)E9B!](%T["BL@("!M>2`D0V,)/2!;(&UA<"`D7RT^16UA:6PL($![ M("1S96QF+3Y#8RT^271E;7-!<G)A>5)E9B!](%T["BL@("!M>2`D061M:6Y# M8PD](%L@;6%P("1?+3Y%;6%I;"P@0'L@)'-E;&8M/D%D;6EN0V,M/DET96US M07)R87E2968@?2!=.PHK(`HK("`@=7-E(%)4.CI4<F%N<V%C=&EO;G,["BL@ M("!M>2`D=')A;G-A8W1I;VYS(#T@4E0Z.E1R86YS86-T:6]N<RT^;F5W*"1S M96QF+3Y#=7)R96YT57-E<BD["BL@("`D=')A;G-A8W1I;VYS+3Y,:6UI="@@ M1DE%3$0@/3X@)U1I8VME="<L(%9!3%5%(#T^("1S96QF+3YI9"@I*3L**R`@ M("1T<F%N<V%C=&EO;G,M/DQI;6ET*"!&245,1"`]/B`G5'EP92<L("`@5D%, M544@/3X@)T-R96%T92<I.PHK("`@;7D@)&%T=&%C:&UE;G0@/2`D=')A;G-A M8W1I;VYS+3Y.97AT+3Y-97-S86=E+3Y.97AT.PHK(`HK("`@:68H(61E9FEN M960H)&YE=W-U8FIE8W0I*2!["BL@("`@("1N97=S=6)J96-T(#T@)'-E;&8M M/E-U8FIE8W0["BL@("!]"BL@"BL@("!I9B@A9&5F:6YE9"@D8V]N=&5N="DI M('L**R`))&-O;G1E;G0@/2`D871T86-H;65N="T^0V]N=&5N=#L**R`@('T* M*R`**R`@('5S92!-24U%.CI%;G1I='D["BL@("!M>2`D34E-14]B:B`]($U) M344Z.D5N=&ET>2T^8G5I;&0H($1A=&$@/3X@)&-O;G1E;G0L"BL@("`@(&UA M<"![("]>*%M<=UPM72LZ*5QS*B@N*BDD+SL@)#$@/3X@)#([('T@<W!L:70H M+UQN+RP@)&%T=&%C:&UE;G0M/DAE861E<G,@*0HK("`@*3L**R`**R`@(&UY M("1C;&]N92`](%)4.CI4:6-K970M/FYE=R@D<V5L9BT^0W5R<F5N=%5S97(I M.PHK("`@;7D@*"1T:60L("1T<F]B:FED+"`D;7-G*2`]("1C;&]N92T^0W)E M871E*`HK(`D)475E=64@("`@("`@("`@(#T^("1S96QF+3Y1=65U92P**R`) M"5)E<75E<W1O<B`@("`@("`]/B`D4F5Q=65S=&]R+`HK(`D)0V,@("`@("`@ M("`@("`@(#T^("1#8RP**R`)"4%D;6EN0V,@("`@("`@("`]/B`D061M:6Y# M8RP**R`)"4]W;F5R("`@("`@("`@("`]/B`D<V5L9BT^3W=N97(L"BL@"0E3 M=6)J96-T("`@("`@("`@/3X@)&YE=W-U8FIE8W0L"BL@"0E);FET:6%L4')I M;W)I='D@/3X@)'-E;&8M/DEN:71I86Q0<FEO<FET>2P**R`)"49I;F%L4')I M;W)I='D@("`]/B`D<V5L9BT^1FEN86Q0<FEO<FET>2P**R`)"5!R:6]R:71Y M("`@("`@("`]/B`D<V5L9BT^4')I;W)I='DL"BL@"0E3=&%T=7,@("`@("`@ M("`@/3X@)'-E;&8M/E-T871U<RP**R`)"51I;657;W)K960@("`@("`]/B`P M+`HK(",)"51Y<&4@("`@("`@("`@("`]/B`D<V5L9BT^5'EP92P**R`)"41U M92`@("`@("`@("`@("`]/B`D<V5L9BT^1'5E+`HK(`D)(T-R96%T960@("`@ M("`@("`]/B`D<V5L9BT^0W)E871E9"P**R`)"2-#<F5A=&]R("`@("`@("`@ M/3X@)'-E;&8M/D-R96%T;W(L"BL@"0E-24U%3V)J("`@("`@("`@/3X@)$U) M345/8FHL"BL@"0E#<F5A=&54>7!E"3T^("=#;&]N92<L"BL@"0E#;&]N961) M1`D]/B`D<V5L9BT^:60H*2P**R`)"2D@;W(@<F5T=7)N(#`["BL@("!R971U M<FX@*"1C;&]N92P@)'1R;V)J:60L("1M<V<I.PHK('T**R`**R`C('U]?0HK M(`HK(",@>WM[('-U8B!3<&QI=`HK(`HK(#UH96%D,B!3<&QI=`HK(`HK(%-P M;&ET<R!A;B!E>&ES=&EN9R!T:6-K970@86YD(&ET<R!C<F5A=&4@=')A;G-A M8W1I;VX[(')E='5R;G,@=&AE"BL@;F5W(%1I8VME="!I9"X**R`**R!!<F=U M;65N=',@87)E"BL@"7-E;&8@+2!4:6-K970**R`)='EP92`M(%-P;&ET?$9O M<FL**R`)<W5B:F5C="`M(&]V97)R:61E('-U8FIE8W0@*&]P=&EO;F%L*0HK M(`EC;VYT96YT("T@;W9E<G)I9&4@:6YI=&EA;"!M97-S86=E(&-O;G1E;G0@ M*&]P=&EO;F%L*0HK(`HK(%)E='5R;G,Z(&YE=R!4:6-K970L(%1R86YS86-T M:6]N($]B:F5C="P@17)R;W(@365S<V%G90HK(`HK(#UC=70**R`**R!S=6(@ M4W!L:70@>PHK(`EM>2`D<V5L9B`]('-H:69T.PHK(`EM>2`D='EP92`]('-H M:69T.PHK(`EM>2`D;F5W<W5B:F5C="`]('-H:69T.PHK(`EM>2`D8V]N=&5N M="`]('-H:69T.PHK(`HK(`EM>2`H)&-L;VYE+"`D=')O8FII9"P@)&US9RD@ M/2`D<V5L9BT^0VQO;F4H)&YE=W-U8FIE8W0L("1C;VYT96YT*3L**R`):68@ M*&1E9FEN960H)&-L;VYE*2D@>PHK(`HK(`D)(T%D9"!A('1R86YS86-T:6]N M(&9O<B!T:&4@8W)E871E"BL@"0EM>2`H)%1R86YS+"`D37-G+"`D5')A;G-/ M8FHI(#T**R`)"0DD<V5L9BT^7TYE=U1R86YS86-T:6]N*"!4>7!E(#T^("1T M>7!E+`HK(`D)"0D)5&EM951A:V5N(#T^(#`L"BL@"0D)"0E.97=686QU92`] M/B`D8VQO;F4M/FED*3L**R`**R`)"2,@3&]G9VEN9PHK(`D);7D@)&QO9U-T M<B`](")4:6-K970@(B`N("1S96QF+3Y)9"`N("(@(B`N("1T>7!E("X**R`) M"0D)"2(@:6YT;R!T:6-K970@(B`N("1C;&]N92T^:60["BL@"0DD4E0Z.DQO M9V=E<BT^:6YF;R@D;&]G4W1R*3L**R`)?0HK(`ER971U<FX@*"1C;&]N92P@ M)'1R;V)J:60L("1M<V<I.PHK('T**R`*("`C('U]?0H@(`H@(",@>WM[(%)O M=71I;F5S(&1E86QI;F<@=VET:"!W871C:&5R<RX*```````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````!S<&QI="]S<&QI=%]T96UP;&%T92YS86UP;&4````````` M```````````````````````````````````````````````````````````` M````````````````````````````(#$P,#8T-``@("`@-#,T`"`@("`W-C4` M("`@("`@("`R,3(T("`W-38R,C0R,S,S(#$T-C<W`"`P```````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````````````'5S M=&%R("``=&]N>0!T;VYY````
MM
MM
M`````````````````````````````````````%-U8FIE8W0Z(%-U<’!O<G0@
M8V%S93H@>R14:6-K970M/E-U8FIE8W1]"@I792!H879E(’-P;&ET('EO=7(@
M;W)I9VEN86P@<F5Q=65S="!R96=A<F1I;F<"B@("B>R14:6-K970M/DUE
M;6)E<D]F+3Y.97AT+3Y487)G971/8FHM/E-U8FIE8W1](@H
:6YT;R!M=6QT
M:7!L92!P87)T<RX@($$@;F5W(&-A<V4@=VET:"!T:&4@<W5B:F5C=H*("@
M(")[)%1I8VME=“T^4W5B:F5C=”@I?2(“FAA<R!B965N(&%U=&]M871I8V%L
M;'D@96YT97)E9”!I;G1O(&]U<B!D871A8F%S92!U;F1E<B!T:&4
8V%S92!N
M=6UB97(@6WLD<G1N86UE?2C>R14:6-K970M/FED?5TN("!0;&5A<V4@=7-E M('1H:7,@8V%S92!N=6UB97(@:68@>6]U(&YE960@=&\*<F5F97(@=&\@=&AI M<R!R97!O<G0N("!!('-U<'!O<G0@96YG:6YE97(@9G)O;2!)0U,@<VAO=6QD M(&)E(&EN"G1O=6-H('=I=&@@>6]U('-O;VX@869T97(@>6]U(')E8V5I=F4@ M=&AI<R!M86EL+B@4VAO=6QD(‘EO=2!N;W09V5T(&$@<F5S<&]N<V4@=VET
M:&EN(#@@8G5S:6YE<W,@:&]U<G,L(’!L96%S92!E<V-A;&%T92!T:&ES(&ES
M<W5E"G1O(’-U<’!O<G1M86YA9V5R0&EC<RYC;VTL(&]R(&-A;&P@
#8Q-RD@
M-C(Q+3P-CL(’!R97-S(#@=&\@8F4*9&ER96-T960@=&\@=&AE(')E8V5P M=&EO;FES="!A;F0@<F5Q=65S="!T;R!S<&5A:R!T;R!T:&4@<W5P<&]R=IM
M86YA9V5R+@H5&AE<F4@:7,@;F@;F5E9"!T;R!R97!L>2!T;R!T:&ES(&UE
M<W-A9V4@<FEG:‘0@;F]W+B@(%!L96%S90II;F-L=61E('1H92!S=')I;F<Z M"@H@("@("@("@("@("@(%M[)’)T;F%M97T@(WLD5&EC:V5T+3YI9’U=
M"@II;B!T:&4@<W5B:F5C="!L:6YE(&]F(&%L;"!F=71U<F4@8V]R<F5S<&]N
M9&5N8V4@86)O=70@=&AI<R!I<W-U92X
5&@9&@<V\L('EO=2!M87D@<F5P
M;'D@=&@=&AI<R!M97-S86=E+@H5&AA;FL@>6]U+`I4:&4@24-3(%1E8VAN
M:6-A;"!3=7!P;W)T(%1E86T
"DUE<W-A9V4@9F]R('1H:7,@;F5W(&-A<V4Z
M"BTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T*>R14<F%N<V%C=&EO;BT^
M0V]N=&5N="@I?0H`````````````````````````````````````````````
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM

`
end

Date: Wed, 6 Nov 2002 12:13:36 -0500
From: Tony Aiuto tony@ics.com
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] Split Ticket

Here is my version 1 hack for doing a split ticket like I asked
about a few week ago. Some people seemed interested in such
a feature so I’m making it available.

I’m not totally happy with the implementation yet, but I think
it’s stable enough for people to use.

Tthanks Tony for this addon.

I have edited Split.html to look more RT’ish. Only problem I have is
that I don’t like the rowspan=20 in the following piece:

Problem is that one doesn't know in advance into how many parts the ticket is going to be split but more than 20 seems unlikely and I haven't seen any side effects sofar.

Split.html (4.45 KB)

Hello,

I liek to follow-up on this:–On Dienstag, 29. Oktober 2002 9:55 Uhr -0500 Tony Aiuto tony@ics.com wrote:

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets. Then the support staffer doing the split
can edit the subject and content on each to divide
the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

it would be a dream if the following scenario would be supported on
splitting:

a simple way to create n tickets out of one ticket so that the former
ticket depends on the n newly created ones, the former ticket can then be
set to stalled, the new ones to new.

If it happens that all of the child tickets are resolved, the former
ticket’s status should change automatically to open and can be manually
resolved.

afterwards, if one of the resolved child ticket’s status change again, the
parent tickets status should change to open again.

How could that be achieved? If anybody has an outline, which is consistent
with RT’s development, I might have some ressources to contribute.

Regards,
Dirk

I need a feature that will let me split a ticket into N
tickets. We often get bug reports that are 2 or more
separate issues. What I would like to do is copy
all the data from the original ticket into the new
tickets. Then the support staffer doing the split
can edit the subject and content on each to divide
the problems. Ideally, if you ask to split into
3 tickets, you should get 3 popup dialogs which
present the subject and text of the original
so that you can edit them down as a single process.

it would be a dream if the following scenario would be supported on
splitting:

a simple way to create n tickets out of one ticket so that the former
ticket depends on the n newly created ones, the former ticket can then be
set to stalled, the new ones to new.

The split ticket patch I sent around a week or two ago copies
status of the original parent. I think making them ‘new’ might
be a good idea as well. I guess I can make that tunable through
config.pm.

As far as making the parent stalled. I wonder about that.
Is it really stalled, or is it just a function over the
child statuses. That is, if all the children are ‘new’, then
it is ‘new’. If at least one is open, then it’s open. If
one is stalled, then it is stalled. Is there a "right"
answer to this question, or even a “good enough” answer,
or should it be a site tunable parameter?

If it happens that all of the child tickets are resolved, the former
ticket’s status should change automatically to open and can be manually
resolved.

Hmm, where to put this functionality? Should that be a Scrip Action
fired by “OnStatus” of the child or should it be code within
Ticket.pm itself? It is really sort of a global Condition.
I change state, but that causes a condition my parent cares
about to be true, so my parent wants a Scrip to trigger.

afterwards, if one of the resolved child ticket’s status change again, the
parent tickets status should change to open again.

I would do this with Scrips. We could easily make an Action for
"OpenParentTicket". You would fire that on whatever condition you
think is right. I would only open the parent if the status
changes to open or new from not open or new, but some people might want
it on any status change, or perhaps on a queue change.

How could that be achieved? If anybody has an outline, which is consistent
with RT’s development, I might have some ressources to contribute.
Dirk

Have you tried my split ticket patch? I would be happy to
make parts of it tuneable. Would you like to investigate
and work on how to change parent status to open when the
children get resolved? Especially w.r.t what features RT 3
has that might help.

-tony

As far as making the parent stalled. I wonder about that.
Is it really stalled, or is it just a function over the
child statuses. That is, if all the children are ‘new’, then
it is ‘new’.

One or all new making parent new might be discussed. I’m not
sure parent should be new since you have taken it and done
something with it !

Option 1 :

Isn’t there (couldn’t one create) a status “pending on child”?
It corresponds to my view of “stalled”, so I’d use that; the
ticket is in effect stalled pending resolution of children.

From that point of view, the algorithm is simple: stalled as
long as all children are not resolved, then either resolved or
open again depending on whether one need to take an action.
That would, I think, either be an option when you split up the
ticket, or just “open” again, so it can be closed.

Option 2 :

From another point of view, the “representative of global
state”:

If at least one is open, then it’s open.

Seems right.

If one is stalled, then it is stalled.

That depends on what you mean by stalled (and it conflicts with
the line above).

I would say “if all are stalled then parent is stalled”.

Example : one ticket stalled pending resolution of a sibling
ticket . . . I say the parent is open.

This point of view could be summarized as :

if all children identical, then parent same status

if all children (X or resolved or dead), parent = X

if one child open, than parent open.

Are there more than “stalled” remaining ?

Anyway, I prefer Option 1.

I have implemented something like this in RT1.

I did not make a “split ticket” with a parameter, as suggested
earlier IIRC, but a single “new ticket from this one”, which
clones the ticket date the way I want it to and then shows the
parent text, letting me copy-n-paste a chosen part into the
windown below to become the text of the new ticket. I think
that is better than trimming down the same text n times, each
time leaving a different part, but YMMV.

#include <std_disclaim.h> Lorens Kockum

Hello Tony,

The split ticket patch I sent around a week or two ago copies
status of the original parent. I think making them ‘new’ might
be a good idea as well. I guess I can make that tunable through
config.pm.

I could not try the patch yet due to lack of time, sorry. So my diskussion
of your question will remain theoretical:

As far as making the parent stalled. I wonder about that.
Is it really stalled, or is it just a function over the
child statuses. That is, if all the children are ‘new’, then
it is ‘new’. If at least one is open, then it’s open. If
one is stalled, then it is stalled. Is there a "right"
answer to this question, or even a “good enough” answer,
or should it be a site tunable parameter?

My guess is that making the status a (static) function of the child
statuses will not reflect all possible split-fork-usages. One main strength
of RT is imo its flexibility to support extermely different workflows (with
ACLs, pseudogroups and conditions and scrips).

Hence I would think in triggers (conditions) and actions (scrips)

eg. On trigger:StatusChange action:SetParentStatus with template:

in the template of the scrip-action - if possible - a function might be
implemented, which can read the parameters of all child tickets.

That was for the fork-semantics, I asked for. For my scenario the function
would best be

if new status(changedChild) = stalled
then status(parent):= stalled
else status(parent):= open;

For the split semantics (put a ticket to several queues) I’d like

eg. On trigger:StatusChange action:SetReferencesStatus with
template:

but in my view of the usage scenario there would be no function (hence I
would not use this action).

For completion there should be an action for all kinds of references
(SetParentStatus, SetChildStatus, SetRefersToStatus, SetReferredToByStatus,
SetDependsOnStatus, SetDependedOnByStatus) to flexibly implement different
semantics/scenarios.

If it happens that all of the child tickets are resolved, the former
ticket’s status should change automatically to open and can be manually
resolved.

Hmm, where to put this functionality? Should that be a Scrip Action
fired by “OnStatus” of the child or should it be code within
Ticket.pm itself? It is really sort of a global Condition.
I change state, but that causes a condition my parent cares
about to be true, so my parent wants a Scrip to trigger.

s. a. for my suggestion. Though I am not sure, if it is implementable in RT.

afterwards, if one of the resolved child ticket’s status change again,
the parent tickets status should change to open again.

I would do this with Scrips. We could easily make an Action for
"OpenParentTicket". You would fire that on whatever condition you
think is right. I would only open the parent if the status
changes to open or new from not open or new, but some people might want
it on any status change, or perhaps on a queue change.

ack.

How could that be achieved? If anybody has an outline, which is
consistent with RT’s development, I might have some ressources to
contribute. Dirk

Have you tried my split ticket patch? I would be happy to
make parts of it tuneable. Would you like to investigate
and work on how to change parent status to open when the
children get resolved? Especially w.r.t what features RT 3
has that might help.

Yes, I will try to help with that but I can start with it in two weeks.

Bye,
Dirk.

Hello Tony,

The split ticket patch I sent around a week or two ago copies
status of the original parent. I think making them ‘new’ might
be a good idea as well. I guess I can make that tunable through
config.pm.

I could not try the patch yet due to lack of time, sorry. So my diskussion
of your question will remain theoretical:

As far as making the parent stalled. I wonder about that.
Is it really stalled, or is it just a function over the
child statuses. That is, if all the children are ‘new’, then
it is ‘new’. If at least one is open, then it’s open. If
one is stalled, then it is stalled. Is there a "right"
answer to this question, or even a “good enough” answer,
or should it be a site tunable parameter?

My guess is that making the status a (static) function of the child
statuses will not reflect all possible split-fork-usages. One main strength
of RT is imo its flexibility to support extermely different workflows (with
ACLs, pseudogroups and conditions and scrips).

Hence I would think in triggers (conditions) and actions (scrips)

eg. On trigger:StatusChange action:SetParentStatus with template:

in the template of the scrip-action - if possible - a function might be
implemented, which can read the parameters of all child tickets.

That was for the fork-semantics, I asked for. For my scenario the function
would best be

if new status(changedChild) = stalled
then status(parent):= stalled
else status(parent):= open;

For the split semantics (put a ticket to several queues) I’d like

eg. On trigger:StatusChange action:SetReferencesStatus with
template:

but in my view of the usage scenario there would be no function (hence I
would not use this action).

For completion there should be an action for all kinds of references
(SetParentStatus, SetChildStatus, SetRefersToStatus, SetReferredToByStatus,
SetDependsOnStatus, SetDependedOnByStatus) to flexibly implement different
semantics/scenarios.

If it happens that all of the child tickets are resolved, the former
ticket’s status should change automatically to open and can be manually
resolved.

Hmm, where to put this functionality? Should that be a Scrip Action
fired by “OnStatus” of the child or should it be code within
Ticket.pm itself? It is really sort of a global Condition.
I change state, but that causes a condition my parent cares
about to be true, so my parent wants a Scrip to trigger.

s. a. for my suggestion. Though I am not sure, if it is implementable in RT.

afterwards, if one of the resolved child ticket’s status change again,
the parent tickets status should change to open again.

I would do this with Scrips. We could easily make an Action for
"OpenParentTicket". You would fire that on whatever condition you
think is right. I would only open the parent if the status
changes to open or new from not open or new, but some people might want
it on any status change, or perhaps on a queue change.

ack.

How could that be achieved? If anybody has an outline, which is
consistent with RT’s development, I might have some ressources to
contribute. Dirk

Have you tried my split ticket patch? I would be happy to
make parts of it tuneable. Would you like to investigate
and work on how to change parent status to open when the
children get resolved? Especially w.r.t what features RT 3
has that might help.

Yes, I will try to help with that but I can start with it in two weeks.

Bye,
Dirk.