-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 14.09.2012 15:19, Christopher Nelson wrote:
> http://www.edgewall.org/docs/branches-0.12-stable/epydoc/trac.ticket.api.ITicketChangeListener-class.html
>
>
shows me the syntax/interface for a ticket change listener but doesn't
> give me a lot of context for when it is called,
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):
...
> what I can safely do in a listener, etc. I'm running into a problem
> in my listener that only shows up on large datasets in our test
> environment but not in the small dataset in my development
> environment and I'd like to understand timing and context so I know
> where to look for my problem. Is there some tutorial or other
> documentation that will tell me how listeners interact with the
> system and with each other? For example, if my listener saves a
> ticket, does it get called again recursively so I have to be
> reentrant? Does another call get deferred until this call ends?
> 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.
> Here's what I'm trying to do: when a field related to scheduling
> tickets changes, do a minimal schedule recalculation. So, if the
> estimate for a ticket change from 8 hours to 16, any following work
> will start a day later or this task will start a day earlier. In
> the latter case, I'll do all my calculations then have a new start
> date for the ticket that the listener got invoked for. When I save
> that change -- inside the listener -- what happens?
I've been reading your questions and explanation already for a while
here. Now I'm forced to disclose some of my personal opinions. 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.
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).
Sincerely,
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlBTdJAACgkQ31DJeiZFuHee9gCfePgP/faygyF9FeyTtbhOLpEg
5JUAnirJKENqy1QIMtbS8lFjaFq2qDns
=Hn7V
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
