[rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets

[Ruslan Zakirov]

On Mon, Jun 11, 2012 at 10:45 AM, Robert Wysocki
<robert.wysocki at contium.pl> wrote:
> Dnia 2012-06-09, sob o godzinie 22:50 +0400, Ruslan Zakirov pisze:
>>
>>
>> On Sat, Jun 9, 2012 at 10:17 PM, Scotto Alberto <al.scotto at reply.it>
>> wrote:
>>         Much better, following KISS rule: we could simply use hidden
>>         CFs to store temporary values!
>>         This way it's much cleaner, isn't it?
>>
>>
>>
>> Have you seen Attributes class/table in RT. It's designed for such
>> things. Store anything developer like tied to any RT object.
>>
>
> Actually few days ago I posted my solution for parking tickets that uses
> two extra CF's and also asked in the same post is there any way to avoid
> those. Unfortunately I didn't get any answer then, now I have one.

Sorry. Didn't notice that.

I'm not sure why you need additional data storage. I see putting Due
date on hold in the following way:

1) When status is changed from initial/active to some that marked as
"on hold", we just unset Due date. We can not keep old value in the
Due field as it will mess sorting of tickets.

2) When status is changed from "on hold" to any active, we
re-calculate Due date.

Re-calculation is hard to make sane. RT out of the box opens tickets
on replies, so reply and activation from "on hold" events match. This
case is very simple, we treat it as any other reply.

It becomes questionable when people disable "auto open" on some
replies. There are several interesting timelines that may happen:

1) reply ... on hold ... no replies ... activation
2) reply ... on hold ... reply(ies) ... activation

In first case due date can be calculated from reply plus time ticket
was on hold. Second case is harder and I'm still not sure how to treat
it.

So my question is how do you want this to work? If you have sane
ideas, I would love to know.

> Regards,
>
> --
> Robert Wysocki
> administrator systemów linuksowych
> Contium S.A., http://www.contium.pl



-- 
Best regards, Ruslan.