Last modified: 2013-09-04 11:53:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35880, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33880 - $wgUsersNotifiedOnAllChanges should not send e-mail to user who made the edit.
$wgUsersNotifiedOnAllChanges should not send e-mail to user who made the edit.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
1.17.x
All All
: Unprioritized minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-22 15:14 UTC by Mark Clements (HappyDog)
Modified: 2013-09-04 11:53 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mark Clements (HappyDog) 2012-01-22 15:14:27 UTC
You can add a user to the $wgUsersNotifiedOnAllChanges array, and that user receives an e-mail for each change made to the wiki - including their own.

Expected behaviour: They receive a notification for each change *except* their own.
Comment 1 Sam Reed (reedy) 2012-01-23 15:04:40 UTC
r109826
Comment 2 Mark Clements (HappyDog) 2012-01-23 15:18:40 UTC
Wow - fast work!  Thanks, Reedy!
Comment 3 Michael Jennings 2012-09-18 00:21:03 UTC
This is quite unfortunate in my opinion.  The variable name clearly states that the user(s) should be notified of ALL changes, not just OTHERS' changes.

This "fix" should be reverted, IMHO, or the behavior made modifiable.
Comment 4 Mark Clements (HappyDog) 2012-09-18 11:09:35 UTC
To be honest, I can't conceive of a situation where you would ever want an address in this list to receive their own edits.

The two use-cases I can see for this feature are:

1) Admin users, who want to see all edits made to the wiki.  Clearly they don't want to see their own as they already know about them.

2) Mailing lists/IRC bots/etc. which won't make edits and are therefore unaffected by this change.

If you can come up with a use case then I'm happy for someone to modify the setting to allow for both scenarios, but if only one scenario is supported then skipping the person who made the edit is definitely the most sensible approach.  

Please do not revert!
Comment 5 Alexandre Emsenhuber [IAlex] 2012-09-18 11:30:28 UTC
You can work arround this by creating another account, setting the same e-mail address as your one and using it in $wgUsersNotifiedOnAllChanges.
Comment 6 Michael Jennings 2012-09-19 16:04:38 UTC
(In reply to comment #4)
> To be honest, I can't conceive of a situation where you would ever want an
> address in this list to receive their own edits.

Maybe you can't.  That doesn't mean no one else can either.  :-)

> The two use-cases I can see for this feature are:
> 
> 1) Admin users, who want to see all edits made to the wiki.  Clearly they don't
> want to see their own as they already know about them.

I assure you, I do.  :-)

> If you can come up with a use case then I'm happy for someone to modify the
> setting to allow for both scenarios, but if only one scenario is supported then
> skipping the person who made the edit is definitely the most sensible approach. 

The most sensible approach is always, in my opinion, that of least surprise.  A variable named "users notified of ALL changes" should either do what its name says it does or be renamed (to $wgUsersNotifiedOnEveryoneElsesChanges, perhaps).

The optimal solution may be to have a per-user setting for "notify me of my own edits" and allow both watchlists and $wgUsersNotifiedOnAllChanges to respect this setting.
Comment 7 Mark Clements (HappyDog) 2012-09-19 21:11:48 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > To be honest, I can't conceive of a situation where you would ever want an
> > address in this list to receive their own edits.
> 
> Maybe you can't.  That doesn't mean no one else can either.  :-)

True.  But as it is you who are arguing the case for inclusion, I would have thought that you would have been able to provide at least one such example!

> > The two use-cases I can see for this feature are:
> > 
> > 1) Admin users, who want to see all edits made to the wiki.  Clearly they don't
> > want to see their own as they already know about them.
> 
> I assure you, I do.  :-)

Why?  Perhaps if you explained your use-case (and, perhaps, why the workaround in comment 5 is insufficient) then you might have a chance of convincing others of that there was some basis to your request.

> > If you can come up with a use case then I'm happy for someone to modify the
> > setting to allow for both scenarios, but if only one scenario is supported then
> > skipping the person who made the edit is definitely the most sensible approach. 
> 
> The most sensible approach is always, in my opinion, that of least surprise.  
> A variable named "users notified of ALL changes" should either do what its name
> says it does or be renamed (to $wgUsersNotifiedOnEveryoneElsesChanges,
> perhaps).
> 

If you are arguing that the variable should be renamed, then please log a new bug for that.  I expect, for backwards-compatibility reasons, it will be closed as WONTFIX, but no harm trying.  It won't be me who decides, and I don't have a strong opinion on this.

> The optimal solution may be to have a per-user setting for "notify me of my own
> edits" and allow both watchlists and $wgUsersNotifiedOnAllChanges to respect
> this setting.

I think there is a case for two new UI settings:

* E-mail me about changes to all pages (not just my watchlist)
* E-mail me about every single change (not just the first)

In either case, you should not be e-mailed your own changes, and it would need to be something that could be enabled/disabled for the wiki via a config setting (you wouldn't want it enabled on something the size of Wikipedia, for example!).

However, this is also something that should be logged as a new bug (if it hasn't been already).
Comment 8 Michael Jennings 2012-09-26 20:38:35 UTC
(In reply to comment #7)
> True.  But as it is you who are arguing the case for inclusion, I would have
> thought that you would have been able to provide at least one such example!

I did.
 
> Why?  Perhaps if you explained your use-case (and, perhaps, why the workaround
> in comment 5 is insufficient) then you might have a chance of convincing others
> of that there was some basis to your request.

I'm not sure what more explanation you want than what I've already given you.  I want to be notified of ALL changes (which, due to the definition of the word "all," includes my own).  I added my user account to the variable whose name indicated it would do exactly this.  It used to work; now it does not.

As for the workaround, that would likely create duplicate e-mails for watchlist items and would also constitute a valid, unmonitored account (a negative for security).  And it fails to address the issues at hand.

> If you are arguing that the variable should be renamed, then please log a new
> bug for that.  I expect, for backwards-compatibility reasons, it will be closed
> as WONTFIX, but no harm trying.  It won't be me who decides, and I don't have a
> strong opinion on this.

The variable is correctly named; its functionality was broken.

> In either case, you should not be e-mailed your own changes

Yes, I should.  That's kinda the point here.  :-)
Comment 9 Mark Clements (HappyDog) 2012-09-27 11:41:34 UTC
You still haven't said *WHY* you want this functionality!
Comment 10 Michael Jennings 2012-09-28 18:43:46 UTC
Is it so inconceivable that someone else's personal preference could differ from your own?  :-)

Alrighty, then.  Let's see here.

1.  Allows me to track chronological changes independent of the wiki.  I can gather them in a single mailbox (or GMail label) for future use.

2.  Makes e-mail functionality visible to me as the system admin.  If it breaks, I'll know it sooner rather than later.

3.  If changes are made via my credentials but not by me, I find out immediately.

4.  Single-click access to changesets.

5.  Consistency is less error-prone.  Fewer exceptions mean fewer opportunities for errors.

6.  Because that's what the variable says it does.

7.  Because it used to work.

8.  Again, personal preference.  Gives me warm fuzzies.

HTH.
Comment 11 Bachsau 2012-11-08 21:58:20 UTC
It doesn't matter how a variable is named. It's just a technical thing, and I agree with HappyDog's argumentation, that it doesn't make sense to mail a user his own changes. This behaviour was the reason I didn't use that feature in the past. I'm also against renaming that variable. Stop bothering, Michael. You're just getting on peoples nerves.
Comment 12 Michael Jennings 2012-11-20 00:44:18 UTC
(In reply to comment #11)
> It doesn't matter how a variable is named.

Surely you don't mean that.  :-)

> I agree with HappyDog's argumentation, that it doesn't make sense to mail a user
> his own changes.

If it doesn't make sense for you, that's fine.  It makes sense for me.  I need functionality which used to work but doesn't work any more, and worse, is impossible to achieve at all now in the upstream codebase.

> This behaviour was the reason I didn't use that feature in the
> past. I'm also against renaming that variable.

That's your preference, and that's fine.  Mine differs.  :-)

Everyone's needs would be served by my suggestion above:  "The optimal solution may be to have a per-user setting for 'notify me of my own edits' and allow both watchlists and $wgUsersNotifiedOnAllChanges to respect this setting."

That seems reasonable, doesn't it?

> Stop bothering, Michael. You're just getting on peoples nerves.

My intent is not to bother.  My intent is to report a problem and work toward a resolution to that problem.  That's what Bugzilla was created to do.  :-)
Comment 13 Mark Clements (HappyDog) 2012-11-20 07:46:33 UTC
(In reply to comment #10)

Everything you want to do can be achieved by setting up a separate user account, as described in comment 5.

The fact that the variable name is not entirely literal really doesn't matter.  I would love us to be in a position where MediaWiki was so perfectly complete that this was worth a lengthy discussion over, but really you are just wasting people's time.
Comment 14 Michael Jennings 2012-11-20 21:18:53 UTC
(In reply to comment #13)

> Everything you want to do can be achieved by setting up a separate user
> account, as described in comment 5.

I've already explained why this is not an acceptable alternative.

In contrast, no one has explained why my suggestion is unacceptable.

> The fact that the variable name is not entirely literal really doesn't matter. 

I strongly disagree with you.  As a user who doesn't know the ins and outs of Mediawiki's inner workings, I tend to rely on variable names to give a strong indication of what they do.

> I would love us to be in a position where MediaWiki was so perfectly complete
> that this was worth a lengthy discussion over, but really you are just wasting
> people's time.

If the situation were reversed, and this change had been reverted, would you not try to make the case for your perspective?  Or would you just let it go?  Your quickness to respond to my initial comment, and the quantity of replies from you since then, would tend to indicate the former is more likely.  :-)

I'm not trying to waste anyone's time.  I'm participating in a discussion...as are you.  :-)
Comment 15 Mark Clements (HappyDog) 2012-11-20 22:27:22 UTC
(In reply to comment #14)
> (In reply to comment #13)
> 
> > Everything you want to do can be achieved by setting up a separate user
> > account, as described in comment 5.
> 
> I've already explained why this is not an acceptable alternative.

Not really, beyond that you don't like it much.
 
> In contrast, no one has explained why my suggestion is unacceptable.

Yes they have, several times.

I am going to bow out of this conversation now, as it's clearly not going anywhere.  Please stop trolling.
Comment 16 Michael Jennings 2012-11-20 23:28:24 UTC
(In reply to comment #15)

> > I've already explained why this is not an acceptable alternative.
> 
> Not really, beyond that you don't like it much.

I did.  See comment 8.

> Yes they have, several times.

No, no one has stated any reason why a user option for receiving notification of one's own changes, and respecting that in both watchlists and the aforementioned global variable, is unacceptable.

> I am going to bow out of this conversation now, as it's clearly not going
> anywhere.  Please stop trolling.

The fact that you don't agree with someone's opinion does not make their expression thereof "trolling."

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links