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
