Thus during its lifecycle a ticket has to go through several stages. Most of these stages are irrelevant to the reporter of the ticket. He doesnt want to be overwhelemed by email notifications for each and every change to the ticket. Our managers used to get complains from clients who were ticket reporters about these notifications. We needed a solution.

One option was to turn off the the reporter notification completely other option was to modify trac’s default behaviour. The first option was not a good one as the reporters needed some kind of notification when a ticket was created, closed or reopened.

I searched Trac-hacks plugin list to find out something suitable. I couldnot find anything therefore i decided to tweak the Trac myself. It was not at all difficult as Trac has a plugin architecture and I found an api which could solve my problem. I just needed to add and modify few lines.That was it our problem was solved.I named it “FlexibleReporterNotification” plugin.

I have posted the solution at trac-hacks site so that someone needing similar solution may find it useful. It works on Trac 0.11.

Plugin url :- http://trac-hacks.org/wiki/FlexibleReporterNotificationPlugin

OS:-Windows 2003

Email client: – Fetchmail

Email2trac version: – 0.30

Others: – cygwin

Through this blog I intend to share our experience of configuring email2trac plugin on windows 2003. We had to make few changes in the original email2trac.py file in order to get it working.

We configured this plugin one eventful night a couple of months back. A normal trac plugin takes around 30-40 minutes at max to configure, but this one plugin took one whole night (around 6-7 hrs.). We started off with downloading the plugin and following the install instructions. After completing the instruction set we tried to test the plugin, the test failed we could not create tickets from email. We revisited the instructions to figure out if we had missed out something. We had followed the instructions quite well.

After playing around with the configuration files and revisiting the entire setup it was time to look at the code itself (email2trac.py). It took us a couple of hours to understand the code and its flow. Few things in the code did not make sense to us therefore we commented out those added few lines of ours and email2trac was working for us. Following are the things we commented out from email2trac.py

1) Blacklisting section.

2) Attachment Encoding.

3) Check for syslog.

4) Normalization of the file name for the attachment.

Due to the commenting of the above mentioned sections attachment path was not being generated correctly. To overcome this problem we added the following lines at the end of attachments definition after fd.close (line number 1073.)

attachmentPath = self.PROJECTPATH + “/attachments/ticket/” + str(ticket['id']) + “/” + url_filename

shutil.copy2 (temppath, attachmentPath)

Although this fix made the email2trac functional on our trac system, we are still struggling with attachments. We are able to send in zipped files in but the MS office documents get clobbered. We are still working on this and hopefully will resolve it soon at that point I will post another blog here.

In my view if any one wants to implement email2trac on windows they should be willing to make their hands dirty. There is not enough documentation available for this plugin. It is still a UNIX based program which can be made to work on windows with some hacks. Just as in our case we broke away from the program flow to make it work for us.

Following links are helpful in setting up this plugin on windows.

https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracInstallation/Windows

http://functionalelegant.blogspot.com/search/label/Trac