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<[email protected]> wrote:
>
> On Jul 23, 7:57 am, "oximoron" <[email protected]> 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 [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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
