Have a look at [#13]. I planned to implement such a feature for 1.1. If you want to write something similar, send me a mail, so we can coordinate the work.

Cheers, Dimitrij

Yes, we would like such a system as well.

The way that Bugzilla and Trac do it is that every time a change is made to the ticket, the reporter, owner, QA Contact, and people on the CC list are sent an email with the changes.

For example, if I change the status to duplicate and add a comment, it would send an email showing the old and new status, along with the comment.

Bugzilla also does Trac one better in that it allows users to set which emails they want to get. For example, I could set it so that I don’t get emails for changes I myself made.

It’s always annoyed me that Trac sends me emails for self-made changes, so maybe Retrospectiva doesn’t even need to make it an option: just do the right thing and not send them.

I previously had a few discussions about this issue. My plan was to implement a subscription system.

Everyone should be able to manually subscribe/unsubscribe to tickets to receive/stop receiving notification about its changes. Additionally the ticket form should have a “Subscribe” check box so posters/commenters could subscribe directly while posting/commenting.

There’s only one single problem with this approach! Sending multiple emails can not be done on the run, it establishes the requirement for Retrospectiva being able to handle background job queues. The processing could be done simply by cron or by more sophisticated solutions (e.g. backgroundrb), but both have their disadvantages.

The development of 1.1 is going to start soon and this feature will be definitely a part of it, but I would like to hear more opinions/suggestions/brainstorms/ideas on the background processing issue before.

Dimitrij

I don’t think you need to send multiple emails. Just set multiple recipients and let the SMTP server take care of it. I believe most SMTP servers can handle up to about 100 recipients before complaining, so this could be an effective solution for the immediate future, until Retrospectiva starts getting thousands of people in the CC list.

For background processing, check out ar_mailer, I think it’s the best solution because it requires very little code change to get working.

Regarding the subscription system, I think that’s find for CC list, but I think the ticket owner and reporter should be automatically subscribed. That’s how most bug trackers work and that’s what I’d like Retro to do for our team. I don’t want people forgetting to subscribe to the bug and not getting notifications.

… let the SMTP server take care of it …

That’s not that easy, believe me! Every email MUST be sent individually (due to technical and legal restrictions), therefore background processing facilities are required.

For background processing, check out ar_mailer…

AR_MAILER requires cron, some people have already expressed their concerns about a cron dependency.

…reporter should be automatically subscribed…

Again, there will be a ‘Subscribe’ checkbox for the reporter/commenter which will be checked by default (so nobody can forget to subscribe to a ticket). The assigned user (owner) will be subscribed automatically (until he manually works it over).

That’s not that easy, believe me! Every email MUST be sent individually (due to technical and legal restrictions)

I’m interested: legal restrictions?

I’m with Luke and Nicholas – I would think that the legal issues would lie with the user who abused the system, not with you. There are thousands of systems out there that send multiple emails via SMTP.

I’ve just started using Retrospectiva (switching from Trac), and the Trac CC field is an absolutely essential feature in my experience. As a project lead, I should be able to determine who sees a ticket. I can’t count on my developers to subscribe manually to tickets, or to check ticket changes every day. And working in an agile shop, my developers should be able to do the same thing. Trac’s CC implementation is great, IMO: users can easily add or remove names to a ticket.

I’d be willing to work on this feature. If you want, I could even run the multiple email issue by my attorney and see what issues are involved. Drop me a line if you’re interested.

Hi Jon!

Trac CC field is an absolutely essential feature in my experience

In mine as well so I’m happy to announce that the feature is already in progress and will be hopefully available in the trunk by the end of this week.

Implemented in [130]