Prevent notification to self/user preferences
Endre Bakka
The notification system has been bugging the h*** out of me, so I figured
I would have a look at it. The first thing I wanted to add was the ability
to turn off notification on changes made by self (#2247).
The site-wide notification options found in trac.ini should IMO be abonded
as soon as possible and be replaced with user preferences. I therefore
added a "Notification" panel under Settings, where I put a prevent
notification to self checkbox.
However, to access this information I need the req which is not available
in the TicketNotifyEmail class (as far as I can see), so I will have to
change the interface so that it is (e.g. add req to the constructor). Is
that ok or is there a better way to do this?
- Endre
Noah Kantrowitz
and will probably be a pretty significant rewrite (you aren't the only
one frustrated by the current notifications framework). Really anything
less than that will just compound the problem by ending up with an even
more complex version of the existing system.
--Noah
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac...@googlegroups.com
> To unsubscribe from this group, send email to trac-dev-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
>
Endre Bakka
> and will probably be a pretty significant rewrite (you aren't the only
> one frustrated by the current notifications framework). Really anything
> less than that will just compound the problem by ending up with an even
> more complex version of the existing system.
Well, I partly agree. But at the same time, if the change doesn't contain
any cross-dependencies with other modules, then I see no reason not to add
it now. The module scheduled for a rewrite will become more complex, yes,
but it will only contain the functionality you want in the new module
anyway. Also, it serves as a reminder to what needs to be implemented, and
in many cases the code, or at least part of it, can be reused as well.
Now, the main problem in my suggested solution is that I add a user
preference stored as a session variable that the ticket module needs
access to. This is a coupling that might be unwanted and is why I posted a
question in the first place.
An alternative is of course to add a global setting to trac.ini (e.g.
notify_on_own_changes) in which case only 4 lines of code is needed in
get_recpients (well, you also need some tests). But as I wanted to avoid
using a global settings, I figured I would try a user preference instead.
Has there been given any thought to how user preferences should be stored?
- Endre
rupert....@gmail.com
* http://trac-hacks.org/wiki/AccountManagerPlugin
* user mgt api: http://trac.edgewall.org/ticket/2456
* nick as login: http://trac.edgewall.org/ticket/3737
Endre Bakka
> * http://trac-hacks.org/wiki/AccountManagerPlugin
> * user mgt api: http://trac.edgewall.org/ticket/2456
> * nick as login: http://trac.edgewall.org/ticket/3737
Interesting, but these are mainly meant for the administrator. I was
thinking about preferences the user sets himself, e.g.:
always_notify_owner, always_notify_reporter and always_notify_updater
should be set on a user-basis (actually, I think this should be set on a
ticket basis as suggested in #6217, but it was the best example I could
think of).
- Endre
Jani Tiainen
This could be that database entry that is identified by some unique key.
There is already existing, though very rudimentary, user preferences
table in Trac that is identified by simple (hash?) key. By coupling this
key with login it would give lot of oppurtunities.
What would be really useful in future: (Not sure does this exists
anywhere written, but I just write it here)
Checkbox on ticket/wiki that says "Notify me if something changes". Then
you would get e-mail about changes. Simple but effective and there
wouldn't be need for distinguish creator or some arbitary listener. It
would remove need for that cc litter in tickets, also it would prevet
removing someone elses e-mail from cc-list. Also it would be easier to
change your interests in preferences page where you could easily remove
yourself from items you're following and in the first place.
This would also prevent e-mail address gathering. Now anyone who can
access Trac tickets can pretty easily extract bunch of e-mail addresses
just by going through tickets since there wouldn't be necessary to
expose any listening e-mail addresses (at least for normal users who
wouldn't see list of listeners at all).
Just my 0.02€...
--
Jani Tiainen
rupert....@gmail.com
> > there is:
> > *http://trac-hacks.org/wiki/AccountManagerPlugin
> > * user mgt api:http://trac.edgewall.org/ticket/2456
> > * nick as login:http://trac.edgewall.org/ticket/3737
>
> Interesting, but these are mainly meant for the administrator. I was
> thinking about preferences the user sets himself, e.g.:
> always_notify_owner, always_notify_reporter and always_notify_updater
> should be set on a user-basis (actually, I think this should be set on a
> ticket basis as suggested in #6217, but it was the best example I could
> think of).
on a ticket basis it would be overkill i guess. but set the preference
at the same place where i can set the username and the email address
would make a lot of sense imo. account manager plugin allows to reset
the password, a nick would allow to set the user name independet from
a unrememberable login-uid. is user mgt an api for writing plugins
that could provide such a functionality, or i got this wrong?
rupert.
Endre Bakka
I strongly disagree - after all, that is what the cc field is used for:
notification on a ticket-to-ticket basis. But instead of having to add
your name to a cc list, you check off a checkbox. It might be overkill for
owners and reporters, but hey, if the framework is already there, why not
give owners and reporters the chance to change notification on a
ticket-to-ticket basis as well.
> at the same place where i can set the username and the email address
> would make a lot of sense imo. account manager plugin allows to reset
> the password, a nick would allow to set the user name independet from
> a unrememberable login-uid. is user mgt an api for writing plugins
> that could provide such a functionality, or i got this wrong?
You might be right, I haven't looked closely at the code.
- Endre
Jeffrey Hulten
RSS feeds for notification. Just another data point to consider.
--
Jeffrey Hulten
Sent from my iPhone
rupert....@gmail.com
somebody else too it would be perfect. we use the owner to define
"main responsible", and the cc to define "these people should help" -
but this is done by a planning person.
rupert.
Endre Bakka
> somebody else too it would be perfect. we use the owner to define
> "main responsible", and the cc to define "these people should help" -
> but this is done by a planning person.
You're right, we do need an elegant way of adding and removing others as
well. This could be done by (ab)using the cc field. A user can change his
own notification on a ticket through using the checkboxes, while other
users that are notified (but not owner or reporter), is shown in the cc
field.
I guess in your particular case, a co-owner field could be interesting
(but maybe overkill) as well?
- Endre
Malcolm J Harwood
> >> > on a ticket basis it would be overkill i guess. but set the preference
> >> I strongly disagree - after all, that is what the cc field is used for:
> >> notification on a ticket-to-ticket basis. But instead of having to add
> >> your name to a cc list, you check off a checkbox.
That's actually something frequently requested at work (as currently removing
yourself from the cc list means you get added to the "people who've changed
this ticket" list and continue to get the email anyway). So being able to
reliably set notification on a per-ticket basis would be great. :-)
On Friday 16 November 2007, Endre Bakka wrote:
> > oh, of course you are right. if there is a wise possibility to add
> > somebody else too it would be perfect. we use the owner to define
> > "main responsible", and the cc to define "these people should help" -
> > but this is done by a planning person.
> You're right, we do need an elegant way of adding and removing others as
> well. This could be done by (ab)using the cc field. A user can change his
> own notification on a ticket through using the checkboxes, while other
> users that are notified (but not owner or reporter), is shown in the cc
> field.
> I guess in your particular case, a co-owner field could be interesting
> (but maybe overkill) as well?
Also something we've had requested - multiple owners for the same ticket (so
that the ticket shows up in reports that are restricted by $USER). Abusing
the cc field doesn't give us that part.
Jeffrey Hulten
On Nov 16, 2007, at 3:59 PM, Malcolm J Harwood <mjhlis...@liminalflux.net
>
>
> That's actually something frequently requested at work (as currently
> removing
> yourself from the cc list means you get added to the "people who've
> changed
> this ticket" list and continue to get the email anyway). So being
> able to
> reliably set notification on a per-ticket basis would be great. :-)
>
Alternately I would like to turn that feature off and only send email
to the person who made the edit instead of all people who edited it.
Is this possible and I just missed something?
>> I guess in your particular case, a co-owner field could be
>> interesting
>> (but maybe overkill) as well?
>
> Also something we've had requested - multiple owners for the same
> ticket (so
> that the ticket shows up in reports that are restricted by $USER).
> Abusing
> the cc field doesn't give us that part.
>
>
From a software/IT audit perspective this troubles me. I want there
to be one responsible party at all times. We use special users to
represent departments where work has not been assigned to an
individual yet.
Thoughts?
Endre Bakka
> to the person who made the edit instead of all people who edited it.
> Is this possible and I just missed something?
No, that particular configuration is not possible AFAIK. Adding a hack
only requires a line or two in get_recipipents though. The notification
system doesn't make sense at all, and is not flexible enough.
>> Also something we've had requested - multiple owners for the same
>> ticket (so
>> that the ticket shows up in reports that are restricted by $USER).
>> Abusing
>> the cc field doesn't give us that part.
>
> From a software/IT audit perspective this troubles me. I want there
> to be one responsible party at all times. We use special users to
> represent departments where work has not been assigned to an
> individual yet.
I agree - that's why I suggested an extra co-owners field instead of one
with multiple owners - to differentiate between people involved and the
one who is responsible.
- Endre
Jani Tiainen
>> Alternately I would like to turn that feature off and only send email
>> to the person who made the edit instead of all people who edited it.
>> Is this possible and I just missed something?
>
> No, that particular configuration is not possible AFAIK. Adding a hack
> only requires a line or two in get_recipipents though. The notification
> system doesn't make sense at all, and is not flexible enough.
That we all agree?
>>> Also something we've had requested - multiple owners for the same
>>> ticket (so
>>> that the ticket shows up in reports that are restricted by $USER).
>>> Abusing
>>> the cc field doesn't give us that part.
>> From a software/IT audit perspective this troubles me. I want there
>> to be one responsible party at all times. We use special users to
>> represent departments where work has not been assigned to an
>> individual yet.
>
> I agree - that's why I suggested an extra co-owners field instead of one
> with multiple owners - to differentiate between people involved and the
> one who is responsible.
Currently tickets have three participants "reporter", "owner" and cc-field.
Ticket will contain one or more participants (owner + co-owner). At
least one (but not limited to) participant must be responsible
participant (owner(s)). Top of that we can have listeners (cc-field).
Does "participants" differ from "listeners"? Who takes care of demotions
and promotions to/from responsible part?
Having two "owner" and "co-owner" fields sounds more like extra
functionality that shouldn't be really part of Trac. You can achieve
same thing with filtering template and adding those new fields.
--
Jani Tiainen
Endre Bakka
> cc-field.
>
> Ticket will contain one or more participants (owner + co-owner). At
> least one (but not limited to) participant must be responsible
> participant (owner(s)). Top of that we can have listeners (cc-field).
>
> Does "participants" differ from "listeners"? Who takes care of demotions
> and promotions to/from responsible part?
Participants would be those expected to fix the problem. Listeners would
be those with an interest in an issue and who would like to notified when
it is resolved e.g. Participants are usually added by others, listeners
usually add themselves.
> Having two "owner" and "co-owner" fields sounds more like extra
> functionality that shouldn't be really part of Trac. You can achieve
> same thing with filtering template and adding those new fields.
I also thought of just adding a new field, but that complicates the
notfication bit somewhat as you would have no way of saying that those in
the new field should be notified. Or am I wrong?
- Endre