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.

Event Timeline

Pharos created this task.Mar 19 2019, 7:07 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 19 2019, 7:07 PM
Pharos added a subscriber: jeremyb.Mar 19 2019, 7:08 PM
jeremyb-phone updated the task description. (Show Details)
Restricted Application added a project: Growth-Team. · View Herald TranscriptMar 19 2019, 7:19 PM

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.

JTannerWMF moved this task from Incoming to QA on the Growth-Team (Current Sprint) board.
JTannerWMF added subscribers: Etonkovidova, JTannerWMF.

@Etonkovidova will look into this

Etonkovidova added a comment.EditedApr 24 2019, 3:50 PM

Confirmed - presently the notification truncates the user name:


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


The bundled notification is more brief:

SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.May 2 2019, 2:18 PM
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.

Pharos added a comment.Sep 4 2019, 7:40 PM

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

Pharos added a subscriber: Bawolff.

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).

Bawolff added a comment.EditedNov 12 2019, 8:58 PM

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.

Elitre added a subscriber: Elitre.Dec 19 2019, 12:19 PM