Page MenuHomePhabricator

MassMessage to email should show section header, not bot username
Open, Needs TriagePublic

Description

MassMessage to email a couple of years ago sent the username as well as the section header, for example:

MediaWiki message delivery left a message on your talk page.	 
/* Last call for WMF grants feedback! */ new section
View message  View changes

Currently it only sends an abbreviated form of the username:

MediaWiki message de...‬ left a message on your talk page.	 
View message  ‪MediaWiki messa...‬  View changes

I would prefer it to at least include the section header, as this is particularly valuable for event announcements. Really, the bot username can be omitted entirely if we want - perhaps we could set up a special case for MassMessage as opposed to regular talk page messages, as with these usually the subject is more important than the username.

See also T59234: Override user-talk Echo notification with something more MassMessage-specific

Event Timeline

I don't know how easy this would be to implement, but you could make a special case where, if the "user" that left a message at the talk page was the user controlled by the mass message extension, retrieve the name of the sender from the inline html comment and use that for the email instead. Alternatively, T71954 could be actioned.

Confirmed - presently the notification truncates the user name:

Screen Shot 2019-04-24 at 8.39.55 AM.png (199×530 px, 33 KB)

Screen Shot 2019-04-24 at 8.47.58 AM.png (276×532 px, 38 KB)

Note: For Flow-based talk pages, the notification has a different text:

Screen Shot 2019-04-24 at 8.32.37 AM.png (182×530 px, 27 KB)

The bundled notification is more brief:
Screen Shot 2019-04-24 at 8.33.51 AM.png (269×539 px, 26 KB)

SBisson added a subscriber: SBisson.

Triaging to "future" for the Growth team but it's possible we'll get to it as part of the effort to reduce Echo's backlog.

Here's the solutions I can think of to make the notification more understandable, in order of simplicity:

  1. Rename "MediaWiki message delivery" to something shorter so it doesn't get truncated.
  2. Revisit Echo's max length for usernames in notification text. It's possible that adding 5 or 10 characters would allow a lot more usernames to be fully displayed while keeping the average notification header's length reasonable. This would need a bit of testing with most notifications and several languages.
  3. Have MassMessage hook into Echo and do some magic. Possibly changing the event type from 'edit-user-talk' to something MassMessage-specific that has its own PresentationModel to phrase the header is a way that emphasize the message title over the sender.

Pharos bugged me about this again in person today.

  1. Have MassMessage hook into Echo and do some magic. Possibly changing the event type from 'edit-user-talk' to something MassMessage-specific that has its own PresentationModel to phrase the header is a way that emphasize the message title over the sender.

This sounds like the best way to move forward I think.

Actually, I think something else might be going wrong here...the notification *should* include the section title. EchoEditUserTalkPresentationModel has a bunch of stuff for the section title, but I don't see it in the primary URL. My guess is that DiscussionParser isn't grabbing it correctly.

Any luck on this? I think @Legoktm is probably right that this was a simple bug introduced at one point.

So testing locally, it looks like it only includes the section header in the email alert if it detects a signature.

So testing locally, it looks like it only includes the section header in the email alert if it detects a signature.

I can't think of a good reason for this, great if that limitation could just be removed. MassMessage deliveries typically do not include identiable signatures, and they are a very important use case.

Best would be to have custom behavior if it's from the MassMessage bot, with no pointless authour information, and the section header in the title of the email. (so people know what the message is about before clicking).

So digging further into the code (line 588 DiscussionParser.php), I can confirm, that mass message bot messages get classified as unknown-unsigned-addition (probably because the fake sig that involves interwiki links) which don't send the header. Its unclear to me if that's generally something that should change for all unsigned-addition's or if we should special case it for mass message. Like if someone adds a section, why does it matter if they sign their edit or not?

Would it be possible to just make a quick exception for MassMessage for now? Then we can figure out later if the limitation makes sense in general for unsigned additions.

Its probably technically easier to do it for all (although probably politically harder)

I guess noone objects to changing behavior in case of MassMessage? I would rather not wait another year for this, let's agree to just do that part.

Just as an aside, I just got an email notice about arbcom election, and flow did seem to be able to get the section header (probably because it was signed by mass message bot) - but the results were still subpar.

The subject was MediaWiki message de...‬ left you a message on Wikipedia

And the body of the email was:

MediaWiki message de...‬ left a message on your talk page in "‪ArbCom 2019 election voter message‬".

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vot...

Which is better than the interwiki case, but still not great.

MassMessage does not send emails. Is this about notifications send on pages on watchlist?

MassMessage does not send emails. Is this about notifications send on pages on watchlist?

On talk pages, rather (the "Edit to my user talk page" / edit-user-talk Echo notification).
It might be relevant for watchlist emails as well once T203941: Allow watchlist notifications to be delivered as web notification (through Echo) lands; the current watchlist emails do not have any section support.

I think this might be Resolved?
It seems to be fixed, from the old bug described in section header.
At least in plaintext-output mode.

E.g. 2021:

2022-02-09_22-32.png (354×900 px, 51 KB)

but 2022/now:

2022-02-09_22-33_1.png (346×954 px, 71 KB)

I don't think that's new. For instance I have an email from 2019:

‪MediaWiki message de...‬ left a message on your talk page in "‪ArbCom 2019 election voter message‬".

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vot...

View message: https://en.wikipedia.org/wiki/User_talk:Nemo_bis?markasread=176292205&markasreadwiki=enwiki#ArbCom_2019_election_voter_message

followed a few days later by:

‪MediaWiki message de...‬ left a message on your talk page.

View message: https://en.wikipedia.org/wiki/User_talk:Nemo_bis?markasread=176658163&markasreadwiki=enwiki

Notice that there are different messages being used to compose those email bodies. One is notification-header-edit-user-talk-with-section.

The basic problem is probably the usual, that Echo fails to parse the pieces of information it needs (section title, username, text snippet, whatever). I'm not sure how to tell whether it even tried or whether MassMessage's posting method influences the result.

Ah, good point. Yeah, I think this might still need developer-investigation then.
Interestingly, here two examples of the same newsletter (Books & Bytes), in which one worked well (2022) and the other didn't (2021).

I wonder, @Samwalton9 do you remember if anything changed with the way you setup the delivery, in the last year? The wikitext seems to be identical, so maybe it was something in the MassMessage interface that was selected differently? (if not, no worries, unsubscribe from here freely :) )

I wonder, @Samwalton9 do you remember if anything changed with the way you setup the delivery, in the last year?

I don't have any recollection of doing anything differently :)

I went through my email inbox, it started working (displaying the section header in the email) sometime in the period between 5/12/15 and 6/28/15, and stopped working sometime in the period between 4/27/2016 and 5/21/2016. @Legoktm do you recall what changes you might have made about these times?

Did some late-night hacking with @jeremyb recently, and was able to confirm that a message with a subject header that is too long for MassMessage fails to show in the email notification, but that the exact same message works for a user manually leaving it. Email notification only works on MassMessage if the header is very short.

Two MassMessages I sent on May 25 https://en.wikipedia.org/w/index.php?title=User_talk:Pharos&oldid=prev&diff=1089767985 and https://en.wikipedia.org/w/index.php?title=User_talk:Pharos&oldid=prev&diff=1089772397 worked correctly in terms of posting the section header in the email (yes, the latter was the infamous accidental "Bison" stampede). I get the impression that there is perhaps a 10-character limit to section headers. I have not been able to replicate this functionality since, no matter the number of characters, have there been some technical changes recently?

OK, on further experimentation, it communicates the subject header to email if it has a character length of 10 or fewer, and only if there is no message body. If there is a message body, it communicates the first 150 characters to email (removing the last 3 with an "..."), and it seems to fail if there are fancy templates involved.

On further further experimentation, it appears that most of the problem came from using ~~~~~ instead of ~~~~! Using the standard 4 tildes, which we had been avoiding to have a custom signature, the first few words of the subject does now show up in the email message.

On further further experimentation, it appears that most of the problem came from using ~~~~~ instead of ~~~~! Using the standard 4 tildes, which we had been avoiding to have a custom signature, the first few words of the subject does now show up in the email message.

The 4 tildes vs 5 tildes thing may only be an issue on enwiki but not on meta, not sure what setting might control this.