Hi, We've implemented something that is simple and should work in most common cases. You can try it from our repository. Note that it needs a DB upgrade.
https://github.com/bestpractical/rt-extension-sla On Tue, Jun 19, 2012 at 9:39 AM, Robert Wysocki <[email protected]> wrote: > Dnia 2012-06-12, wto o godzinie 18:24 +0400, Ruslan Zakirov pisze: >> >> Sorry. Didn't notice that. >> >> I'm not sure why you need additional data storage. > > Additional storage in form of CF's in my solution is merely a product of > the lack of time. I needed it to work and the simplest way was then for > me to code it like this. > Now I see some other options; I belive that if I move the scrip-part of > the code to module code I won't have the need for additional storage any > more. > >> 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. > > That sounds good. > >> 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. > > In our case we decided that in the event of re-activating ticket after > it was parked for some time we change it's status to "open". So we > really don't care about what other scrips do to tickets' status - our > logic goes the other way. > >> This >> case is very simple, we treat it as any other reply. > > We shoudn't change status to "open" if reply wasn't from one of the > requestors - ticket should stay parked. > >> 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. > > In our logic there's no place for ticket activation when there was no > reply from one of the requestors. > In other words if someone will activate a parked ticket "by hand" > recalculation won't happen. > > Best regards, > > -- > Robert Wysocki > administrator systemów linuksowych > Contium S.A., http://www.contium.pl > > -- Best regards, Ruslan.
