Here is a bare bones example of how to implement this interface. There are several plugins on trac-hacks that implement this as well so you can see how a real world plugin would work.
=============== start plugin ======== from trac.core import * from trac.ticket import ITicketChangeListener class TicketListenerPluginExample(Component): """ The 'Hello World' of using the ITicketChangeListener interface """ implements(ITicketChangeListener) # ITicketChangeListener Interface def ticket_created(self, ticket): self.log.info('Ticket created: %r' % ticket) def ticket_changed(self, ticket, comment, author, old_values): self.log.info('Ticket modified: %r' % ticket) def ticket_deleted(self, ticket): self.log.info('Ticket deleted: %r' % ticket) ============ end plugin =================== On Thu, Jul 23, 2009 at 9:05 AM, yoheeb<yoh...@gmail.com> wrote: > > On Jul 23, 7:57 am, "oximoron" <oximo...@alinto.com> wrote: >> Sorry to bother you again. >> >> I come back a last time with this problem. If no solution is found this >> time, I'll try another path.. >> >> The solution to implement the interface 'ITicketActionController' and >> overriding the function 'ticket_created' from the class >> 'ITicketChangeListener' >> (http://trac.edgewall.org/browser/trunk/trac/ticket/api.py) seems to be the >> best & easier way to achieve what I want. >> >> After having read docs on trac and its architecture >> (http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture), I'm sad to >> say that I won't be able to implement this interface by myself. I need help >> with that. >> >> And as this new feature should only be available for one project, I guess I >> have to put this new function in the project dir of trac. >> But where? (I don't understand the deployment of trac on the server) >> >> Thanks for your help and sorry to have brought that up. >> >> Kenny > > I think you just need to wrap it as a plugin, and stick it in the > plugins directory for the project. > > Your call to subprocess might need the "shell" argument, sometimes > that's needed, depends on the environment. If you don't actually need > to wait for the process to complete, or care if it fails, you probably > should run it as a NO_WAIT Popen type call, subprocess waits for the > child to complete. something like: > > Popen(["/bin/mycmd", "myarg"]) > or even Popen(["/bin/mycmd", "myarg"], env={"PATH": "/usr/bin"}) if > you need a specific user environment for the command > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---