On Mon, Jun 11, 2012 at 10:45 AM, Robert Wysocki <[email protected]> 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 <[email protected]> >> 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.
