I wonder if in this case it might be better for initial configuration to
send by default in both cases, but mitigate this by providing an
appropriate direct link to help users adjust the behaviour. I'm trying
to weigh up whether it would be a pity for a user to miss emails that
were actually wanted against annoyance at any perceived spamming.
Cheers,
Gary
On 26/09/12 10:40, Branko Čibej wrote:
This is something that should IMO be configurable. I suggest sane
defaults are:
* if ticket is changed via the Web UI, do not send notification;
* if its changed via e-mail, do send notification (that's essentially
an e-mail receipt).
However, both cases should be user-configurable, preferably per-project
and per ticket (workflow) type and eventually possibly even per workflow
transition.
-- Brane
On 26.09.2012 11:34, Gary Martin wrote:
Hi,
I thought that this ticket might be worth discussing here if anyone
has any interest in it: https://issues.apache.org/bloodhound/ticket/210
Essentially it arises from a complaint that a user might not want to
receive a notification email when they have made a change to a ticket.
Cheers,
Gary
On 26/09/12 10:21, Apache Bloodhound wrote:
#210: Cleverer ticket CC behaviour
--------------------------+--------------------
Reporter: mbooth | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: trac core | Version: 1.0
Resolution: | Keywords:
--------------------------+--------------------
Comment (by mbooth):
Probably the notification system wants re-working to expose
notification
settings to users instead of them being globally enforced.
Something like
(but maybe not as complex as) what Bugzilla does:
http://fedorapeople.org/~mbooth/BugzillaEmail.png
