Roundup Tracker - Issues

Issue 2550906

Title: Do not e-mail me about my own actions, at least optionally
Type: behavior Severity: normal
Components: Mail interface Versions: 1.5
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: Ivan Pozdeev, pefu, rouilj
Priority: Keywords: Effort-Medium

Created on 2016-04-18 22:14 by Ivan Pozdeev, last changed 2019-10-06 23:39 by rouilj.

msg5533 Author: [hidden] (Ivan Pozdeev) Date: 2016-04-18 22:14
Followup of .

> I don't want to receive such notifications ('cuz I'm quite aware of my
own actions as it is)
> and don't see a setting in "Your Details" to control this.

The replying user also mentioned that "the community has elected to get
the notifications" though I couldn't find anything relevant (and thus
the rationale behind this).

The use cases for current SoA I can think of are only:
* If I'm really, REALLY worried about someone hijacking my account.
While this makes _some_ sense for a high-privilege-high-stakes account,
no so much for a regular one.
* If I have some automated processing system at my client side.

Of course, I can filter these out, but it's not very convenient
(specifically, the only tell that shows if it's me or not is my user
name in the From: header).

The main reason is: virtually no-one else does this. Even the venerable
Request Tracker.
msg5534 Author: [hidden] (pefu) Date: 2016-04-19 05:07
Hello Ivan,

In the config.ini of a Roundup tracker instance you have a section
called "[nosy]".  This section contains (beside others) the following
global configuration option:

# Send nosy messages to the author of the message.
# Allowed values: yes, no, new, nosy -- if yes, messages
# are sent to the author even if not on the nosy list, same
# for new (but only for new messages). When set to nosy,
# the nosy list controls sending messages to the author.
# Default: no
messages_to_author = no

If I understood your message msg5533 correctly then you are speaking
about a tracker instance where this option has been configured as "yes"
and you want a personal per user option to turn this behaviour off
again?  Is this right?

Best regards, Peter Funk.
msg5535 Author: [hidden] (pefu) Date: 2016-04-19 05:24
I just had a closer look and discovered that the option
"messages_to_author" is set to "yes" at least in the "devel", "jinja2"
and "responsive" templates shipped with Roundup.  

A per user option wouldn't be so hard to implement:  The code 
dealing with this is located in roundup/ method
nosymessage() at line 312.  It currently reads::

     # possibly send the message to the author, as long as they aren't
     # anonymous
     if (good_recipient(authid) and
         (self.db.config.MESSAGES_TO_AUTHOR == 'yes' or
          (self.db.config.MESSAGES_TO_AUTHOR == 'new' and not oldvalues) or
          (self.db.config.MESSAGES_TO_AUTHOR == 'nosy' and authid in
          self.get(issueid, whichnosy)))):
        add_recipient(authid, sendto)

It would be possible here to check whether the user class of the db
instance in question has an additional boolean attribute 
(we have to select a name for it) and test this instead of the global
flag self.db.config.MESSAGES_TO_AUTHOR 

There are some tests in test/ which must to be modified
also, if this is going to implemented by someone.

Best Regards, Peter Funk.
msg5767 Author: [hidden] (rouilj) Date: 2016-07-06 02:59
Assuming this is controlled by a user option:

 receive_own_messages = default, yes, no, new

so the user can choose to:

  default - get the tracker default (i.e. current operation)
  yes - always get email
  no - never get email
  new - get email if starting a new issue

new can be useful if you are/will be interacting via email.
It sends an email with a subject line set so you can reply
to the issue.

msg5770 Author: [hidden] (rouilj) Date: 2016-07-06 22:03
This isn't that different from:

so it could be done by a reactor in theory. I think the code at the
vacation url just copies (what was at the time) the function Then modifies it to exclude the people on

That seems like a lot of code to duplicate and it will be out of date
if there are other updates to nosymessage.

However it has the distinct advantage that it decouples the core code
from the tracker schema. I think this is required.

If we want to support this somehow in the core, Maybe all we need to
do is add:

   nosymessage(..., include_author=None )

and set that value to False if:

   the user chooses no or if the user choses new and there is no
   old_data passed to the reactor.

or set it to True if the default value is chosen and change code
accordingly. None would be the default case.

Alternatively maybe some registration method could be used to register
a "user_email_preferences" action to call a function that will return
none, true or false indicating: default, yes, no respectively?

(We could pass a callable as include_author with a defined argument
list and have the code do the right thing based on argument type.)

Also the whole nosymessage() mechanism really does need to be redesigned to
allow templating (even basic % format templating could help).


   issue %{issue}s has changed ....


and to make it more flexible.

So I am changing this to medium effort. Even without
templating/redesign it's a bit more than I thought initially.
msg6703 Author: [hidden] (rouilj) Date: 2019-10-06 23:39
With the ability to add a nosy_filer as part of issue2551018, I think 
this can be closed as it gives the ability to reformat the nosy message.

This is different from being able to pass a format in, but I think we 
have a different issue for that.
Date User Action Args
2019-10-06 23:39:32rouiljsetstatus: open -> closed
resolution: accepted
messages: + msg6703
2016-07-06 22:03:24rouiljsetkeywords: + Effort-Medium, - Effort-Low
messages: + msg5770
2016-07-06 02:59:21rouiljsetnosy: + rouilj
messages: + msg5767
2016-07-04 22:23:41rouiljsetkeywords: + Effort-Low
2016-04-19 05:24:58pefusetmessages: + msg5535
2016-04-19 05:07:41pefusetstatus: new -> open
nosy: + pefu
messages: + msg5534
versions: + 1.5
2016-04-18 22:15:11Ivan Pozdeevsettitle: Do not e-mails me about my own actions, at least optionally -> Do not e-mail me about my own actions, at least optionally
2016-04-18 22:14:43Ivan Pozdeevcreate