On Fri, Sep 14, 2012 at 2:16 PM, Steffen Hoffmann <[email protected]> wrote: > On 14.09.2012 15:19, Christopher Nelson wrote: > A full-text search over Trac sources yields only one place, > trac.ticket.api, where ITicketChangeListener is mentioned (plus one > occurrence in trac.ticket.tests.model - a unit test). > > But note: > trac.ticket.api.TicketSystem. > > A closer look at trac.ticket.model.Ticket reveals the core logic,that is > executed in appropriate methods there like so: > > class Ticket(object): > ... > > def delete(self, db=None): > ... > > for listener in TicketSystem(self.env).change_listeners: > listener.ticket_deleted(self) > > def get_change(self, cnum=None, cdate=None, db=None): > ...
Yes, I've seen some of that before. But looking that close and deep didn't really provide the context I was looking for. >> ... >> When do other listeners get called for the change my listener saves? > > You'll see by now: They're executed right after altering the ticket data > in the db. Straight from that springs the advice to not alter tickets in > ticket change listeners, at least not in such a way, that a change will > trigger another change and that another one and ... > > It'll be done ticket by ticket, but by re-spawning you could end up > applying side-effects for a ticket that is actually waiting to get > altered directly too. Yeah. That's both clear and kind of icky for me. ;-) If my listener is a singleton, I can test a global "alreadyRescheduling" flag on entry, skip rescheduling if set, or set, reschedule, and clear otherwise. I realize that may be a bit weak. >... > I've been reading your questions and explanation already for a while > here. Now I'm forced to disclose some of my personal opinions. I'm happy to have the feedback from someone who groks Trac a lot better than I do. > Take with a grain of salt, and listen to others as well. > > Doing automatic ticket changes for your PM stuff will not work well, if > at all. Doing regular ticket changes each re-scheduling would leave a > changes entry and change comment for each action to each ticket, and > your tickets history will quickly grow beyond usable limits. A valid point (and one already raised by a co-worker) but I'm still experimenting. If that's true, a listener that does: * recompute schedule * update tickets can easily morph to: * recompute schedule * update another table > I conclude, that you'll likely need to > * mess directly with PM-related ticket field values and spare the > planning history > * do it in a dedicated table outside of Trac db tables 'ticket' and > 'ticket_custom' (preferred). I think that the history is important and I'm not averse to an custom table. > ... Thanks for the feedback. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
