[rt-users] Split Ticket

[Dirk Pape]

Hello Tony,

--On Montag, 18. November 2002 10:21 Uhr -0500 Tony Aiuto <tony at ics.com> 
wrote:

> 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:<function>

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:<function>

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.