**Feature summary** (what you would like to be able to do and where):
Have a mouseover saying that the email is not on the machine, but in your (Gmail, etc.) mailbox.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
User clicks in vain wondering why they cannot open the "message".
**Benefits** (why should this be implemented?):
All other websites allow users to open "email" "messages" in one click.
However in this case the website is trying to communicate to the user that a real old fashioned email has been sent only.
{F44723134}
Following T115183's resolution, we now get "Page was changed" notifications when different Translate actions have been undertaken, but there's no in-notification distinction between "added to group" //vs.// "marked for translation" //vs.// others).
I believe it's not yet possible for non-core code to influence this, which might be fixed by T44457 (?), but Translate is the primary source of unclear log watchlist notification e-mails I get, so a fix would be lovely once it becomes possible.
Currently we only notify users when they make 1, 10, 100, 1000, 10000, ... edits. Boooo. Boring. Death to decimal-centric notification system.
For example, my fitbit gave me "London metro" badge after walking 402 kilometers (length of London underground). It has more like that (42km for Marathon badge, 112 km for Penguin badge, 563km for Hawaii badge, etc.).
We could have some notifications on top of the current decimal ones: (suggestions)
- 42 edits: obviously.
- 118 edits: Number of chemical elements
- 272 edits: Number of London underground stations.
- ... (suggestions welcome)
Details on why this is occurring and how team's can fix this are provided on T356434
**Steps to replicate the issue** (include links if applicable):
* Enable https://chromewebstore.google.com/detail/wcag-color-contrast-check/plnahcmalebffmaghcpcmpaciebdhgdf Chrome extension
* Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:Notifications?vectornightmode=1 making sure you have notifications
**What happens?**:
5 color contrast issues:
** (including on hover)
**What should have happened instead?**:
No color contrast issues (See T356434 for solutions)
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
** Information for newcomers **
* Make sure you are using the latest MediaWiki and Vector skin
* You will need to setup https://www.mediawiki.org/wiki/Extension:Echo. The fix should be done in this extension.
* To fix this you can try:
** Update any hex codes e.g. color: #fff with the equivalent design token https://doc.wikimedia.org/codex/latest/design-tokens/overview.html
** add the `notheme` class to `mw-echo-ui-notificationsInboxWidget`
A user changed all timestamps by one year on a page I'm subscribed to (not watching): https://www.mediawiki.org/w/index.php?title=Talk:Edit_check&oldid=prev&diff=6381816
This generated notifications for the 23 topics on that page:
{F42060185}
Revert Notification has multiple flaws that should be addressed.
**Revert's justification should be clearly given to the target user**
When a revert is performed with an edit summary added, the revert notification presents some unneeded information.
If you give a reason in the edit summary, you get the full edit summary, which includes the default revert message with the revision, something not necessarily needed:
{F41897236}
If the edit summary gets longer, in particular, because the "Undo revision by" gets longer, the reason will be truncated for sure:
{F41897288}
We should drop the "Undo revision by", as this information is unimportant and already said below. The edit ID is a piece of information for established users, which can be found in the edit itself. What matters is the page (already given in the primary message) and the reason why the revert was performed.
**Not giving a reason should display an invite to contact the performer**
If no reason is given for it, it could look unfair, and it is likely that newcomers won't try to edit anymore:
{F41897177}
In lieu, we should have a default message that would invite to contact the user who performed the undo:
> $1 didn't gave a reason, please contact them.
It is a good way to make users who are easy undoers to take their responsibilities and document.
**Is the icon conveying a bad message?**
The revert notification is quite violent and I'm not sure that the icon helps. Maybe we should use an information icon instead.
Special:DisplayNotificationsConfiguration presents what notifications exist and which are enabled for all users or new users only:
{F41845392}
(and same for "New users")
With the introduction of [conditional user defaults](https://www.mediawiki.org/wiki/Manual:$wgConditionalUserOptions), it is no longer really possible to render default values of preferences, including notification ones. Since currently, conditional defaults can be based only on time, one could assume that notification preferences that are conditionally enabled based on user registration are intended for new users, however, this assumption would break whenever more complex conditional defaults types are introduced.
Hence, I recommend removing this section from Special:DisplayNotificationsConfiguration, replacing it with a link to documentation.
(this is a clean-up task related to T353225)
In T353225, we enabled [conditional defaults](https://www.mediawiki.org/wiki/Manual:$wgConditionalUserOptions) for four Echo properties:
* `echo-subscriptions-web-reverted`
* `echo-subscriptions-web-article-linked`
* `echo-subscriptions-email-mention`
* `echo-subscriptions-email-article-linked`
This stopped the influx of new rows to user_properties by Echo's onLocalUserCreated, as those properties default to the new defaults (false for `echo-subscriptions-web-reverted`, true for the rest) starting `20240208200000`.
It should now be possible to drop old rows (from `20130501000000` onwards) by changing the cutoff date and deleting the rows (while keeping in mind the effective user property values should not change for any users). See T353225#9524337 for a previous attempt by @Urbanecm_WMF on `testwiki`.
Per the following comment by @Ladsgroup, I'm assigning this task to them.
>>! In T353225#9524337, @Ladsgroup wrote:
> I will take over the clean up, just please deploy the change ASAP so it stops adding more rows.
**Steps to replicate the issue** (include links if applicable):
* Navigate to your own userpage
* See a 'Mute this user' link in toolbar
**What happens?**:
You are able to mute yourself
**What should have happened instead?**:
No 'Mute this user' link
Google has updated their [[ https://support.google.com/mail/answer/81126 | sender guidelines ]] and they will began enforcing the new guidelines on February 2nd 2024.
=== Requirements for high-volume senders ===
* ☐ Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.
Determine whether this task is on the mediawiki's team radar and whether they have the time to complete it before February.
We currently have notifications for 2FA being enabled/disabled, but we should have distinct notifications for when 2FA is already enabled, and another 2FA method is enabled. Possibly telling the user how many different ones are enabled.
Similarly, when one is disabled (but there's still >1 enabled), show a notification to let the user know that a specific method has been disabled.
Just what it says on the tin
in Special:Preferences#mw-prefsection-echo add a checkbox option to mute all non-standard users, T207659 would allow this with a "0.0.0.0/0, ::0/0" entry, but that is a technical format and would not match upcoming temporary user accounts.
**Feature summary** (what you would like to be able to do and where):
When a user presses "undo" on an edit of mine and changes things so it's //technically// not a revert, I want to receive a notification.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
[[https://en.wikipedia.org/w/index.php?title=Jacksfilms&diff=prev&oldid=1184469319|Some IP reverted my removal of their unsourced information, this time including a reference to The Sun.]] Because they added a (useless) reference, it's not technically a revert so I wasn't notified. The links in the edit summary point to Special:Contributions and my talk page, not my user page, so I get no notification from those either.
**Benefits** (why should this be implemented?):
I could have re-reverted this sooner. And I could have easily missed it altogether.
Currently when a user is pinged the notification message they receive says something like "ExampleUser mentioned you on Wikidata:Project chat in "Foobar".
This is the same whether they have been pinged individually, or as a member of a project (as done, for example, using https://www.wikidata.org/wiki/Template:Ping_project )
It should be possible for users to see under which of those circumstances they have been pinged, so that for example, they may prioritise their responses when pinged several times.
"Mentioned you" is also misleading, when it is a project, not the individual user, which has been mentioned.
Found by @GMikesell-WMF during QA of T342907#9085628
**Steps to replicate the issue** (include links if applicable):
* Make sure you have 0 unread alert notifications. Mark as read if needed.
* Receive a thanks notification from a friend
* On desktop note the notification is shown in blue {F37394029}
* Visit mobile site
**What happens?**:
* A bell icon shows with no indication you have messages. Clicking the icon will show the thanks notification
**What should have happened instead?**:
Some visual indicator should let me know I have a notification.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
When the notification icons are clicked, Echo replaces them with an OOUI badge. This was a huge problem when switching Vector 2022 from mediawiki UI to Codex and currently, Vector 2022 manages and syncs styles for the Echo button before and after being clicked.
In T342907 while preparing Minerva for the switch from mediawiki UI to Codex, we found the exact same problem with the Minerva desktop skin so this resulting in us having to ** temporarilydisable the feature.**
We considered various solutions:
### Create a transparent mode
We considered changing the logic for Echo to add a transparent icon alongside the existing icon rather than add a new icon:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/803369
We were concerned that this would create issues for screen readers.
## Option 2: Remove the badge logic (T343838)
The badge logic seems to exist for the sole purpose of updating the badge count when actions in the overlay occur. However, the badge count can also be easily manipulated by a hook e.g.
```
mw.hook( 'ext.echo.badge.countChange' ).add( function ( type, count, converted ) {
if ( type === 'message' ) {
$existingMessageLink.attr( 'data-counter-text', converted );
$existingMessageLink.attr( 'data-counter-num', count );
}
} );
```
We think it would be better if Echo progressively enhanced the button rather than replacing it with its own button.
This felt like a relatively large refactor and a decision we couldn't make without the Echo maintainers so I created a new ticket: T343838
# Disable the Echo experience in Minerva desktop and fallback to Special:Notifications
Rather than continue this pattern of creating technical debt, we decided to disable the Echo experience in the Minerva desktop skin. This seemed like the simplest short term solution so has been implemented currently.
Echo currently maintains 2 versions of the badge that users interact with:
- The initial server side rendered version (usually rendered by skins))
- A client side OOUI version that is rendered when the badge is clicked (replacing the existing version)
We've accumulated various technical debt over the years of skins having to maintain their own styles whenever the OOUI button is rendered
# Proposed solution
Please progressively enhance the existing button rather than replacing it.
# QA
[] When clicking the button a PopupWidget should be shown pointing to the existing button
[] Hooks should be used to update the notification count
The list of notifications is in {T333531}.
The global documentation is at https://www.mediawiki.org/wiki/Help:Notifications/Types
A possible solution to ease this work would be to create a template that reflects the status of each notification for each role (regular account vs temp accounts)
---
Methodology
# [] Update https://www.mediawiki.org/wiki/Template:Notification_type
#- add a new parameter to display for "only for regular accounts", and a default "available for regular and temporary accounts"
#- hide the parameters from being visible until the release
# [] update https://www.mediawiki.org/wiki/Help:Notifications/Types to reflect the status of notifications for temp users as in T333531
# [] When temp accounts are available, update https://www.mediawiki.org/wiki/Template:Notification_type to show the new parameters
Hi,
In quite a few cases I come across users who have difficulty changing the gender settings in their preferences. There are some of them which are older women who participate in Wikimedia Israel (WMIL) courses and for whom the technological aspect is an obstacle.
In Hebrew the gender changes the word "user", and the default is male. This is of course not unique only to our language.
This imposes additional difficulty on the women when they are inadvertently addressed with the wrong pronouns, somewhat limits their ability to communicate over talk pages, and increases the gender gap in Wikipedia.
We think a lot about things that can help close this gap in our local Wikipedia. Some of the brainstormings are in collaboration with the WMIL. This problem I presented here is significant for women (in particulary the older ones) and the solutions are purely technical. It will be resolved if the sysops are given the ability to update the gender of users, of course with a summary that will contain a reason and a link that will be a reference for it.
It is important for me to emphasize again that this is a difficulty that crosses languages and greatly affects the female involvement in the community. The initial acceptance may affect the editor in all her future activities in the project. Avoiding communication at the beginning of her activity leads it to participate less in discussions and votes, as well as less involving, influence and recognition of her contribution.
Hope you can help, and thank you,
~ Hyphen
[[ https://en.wikipedia.org/w/index.php?title=Help_talk:Notifications&oldid=1164130070#Delete_specific_notifications_from_notification_log | A user reports ]] a case where they received an unnecessarily rude message. They get an overview of this message every time they check their notifications, which "become an eyesore every time I check my notifications".
We should allow users to delete or archive their notifications so that they disappear from their notifications list.
####User story & summary:
As a user logged into a temporary account, I want the alert bar to be easy to read and WCAG compliant
####Background & research:
This task is important because we aim to meet WCAG level AA, and the current message colors are too low contrast.
####Design:
[[ https://www.figma.com/file/xECM2hD7vEemP91M9YAQBC/IP-Masking?type=design&node-id=1018-29740&mode=design&t=UYKznCTYpWv4bvYl-0|Figma designs]]
{F37922218}
Background hex color: #FEF6E7
Border hex color: #AC6600
Example of current style:
{F37131089}
####Acceptance Criteria:
Given I receive a `You have a new talk page message` alert,
Then the colors of the message are high enough contrast to meet WCAG AA requirements
I wasn't notified of this edit even though my username was linked to in the edit summary: https://cs.wikipedia.org/w/index.php?diff=22926732.
The edit is tagged as `mw-undo` (//vrácení zpět//). For such edits, mentions from the edit summary are [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/ef8a472299bae6fa7de20da99da85d454a65f9bf/includes/DiscussionParser.php#144 | suppressed ]] to avoid duplicate notifications ('you were mentioned' and 'your edit has been reverted').
However, when you undo an edit, you still can add custom text to the edit summary (even replace the preloaded one altogether), including a mention of another user (whom you might want to make aware of that). I think this is surprising and should be improved. Only mention to the user(s) whose edit is reverted should not be sent (in favor of the 'your edit has been reverted' notification).
Note that some edit summaries (e.g., [[ https://cs.wikipedia.org/w/index.php?diff=22924297 | rollbacks ]]) by default mention the user who is the author of the original revision. IIRC, this was the reason for suppressing all notifications for mentions, and I agree we should not spam them with notifications because we cannot implicitly expect the revert concerns them, too. Those users should probably also be excluded.
Anyway, I'd like this to be reconsidered.
**Steps to replicate the issue** (include links if applicable):
* Install Echo
* Get a notification (or ping) to show up in Echo
* Log in
* Open the tray
* Hove your mouse over the unread notification and click on it with your mouse wheel
**What happens?**:
* Page opens in new tab
* Notification is marked as read, but there is no GUI update. You have to reload the page or close and open the notification tray (forcing a notification tray refresh) to see this
**What should have happened instead?**:
* Page opens in new tab
* Notification is marked as read, and the notification tray updates in real time to reflect that the notification is read
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* On a wiki with Vector 2022 Zebra and Echo installed:
* Receive notifications. The effect is more pronounced if you have 50 or more (of all time), as it causes a page button to appear.
* Open [[Special:Notifications]] (don't forget ?VectorZebraDesign=1).
**What happens?**:
Notifications overflow into the right sidebar.
**What should have happened instead?**:
The boxes are reduced in width to fit on the page.
**Other information** (browser name/version, screenshots, etc.):
- Resolution: 1366 x 768
- Chrome OS
- Unfortunately I cannot provide any more info because I can only reproduce this on a school-issued Chromebook that blocks the settings menu, including the about and version pages.
{F37088947}
**Feature summary** (what you would like to be able to do and where): Currently, you get notifications when you reach certain edit count milestones. I was thinking why not do the same for articles. Article creation requires more dedication then edits and it should encourage editors to create more articles.
**Steps to replicate the issue**:
* Create a new article on a Wikipedia project, or use an article you've previously made
* Have link notifications activated for this article (should be by default)
* On a different account, logged out, or with the assistance of another user, link to your article from another article
* Await notification in your notification center
* Open up your notifications and observe the issue
**What happens?**:
The notification shows two links, "All links to this page" and "Mute link notification on 'Article name'". The former link gets easily cut off when the article name is longer than six or seven letters, which is often the case on projects using languages with compound words (but occur on those without, as well).
**What should have happened instead?**:
Ideally the messages would showcase without any cut-off text, or be shown with a desirable formatting for when cut-offs are necessary (see screenshot below).
There are multiple solutions to this issue. Suggestions //1// and //2// are preferred (per report author).
//Suggestion 1:// Ensure that the correct formatting appears for when text is cut-off in notifications.
//Suggestion 2:// Remove one of the links. The first of the two links seems like the less useful in a notification center.
//Suggestion 3:// Shorten the text of the links ("All links here" and "Mute link notifications"). Might prove troublesome in translations or with clarity.
**Other information**:
Unable to find a corresponding report prior to this report. The issue has been noticed by author for a long period and across several MediaWiki versions. Uncertain when issue initially occurred.
The strings in question are:
* `notification-link-text-what-links-here` (all links to page)
* `notification-dynamic-actions-mute-page-linked` (mute link notifs)
* `notification-dynamic-actions-unmute-page-linked` (unmute link notifs)
Screenshot of notifications on nowiki. The same problematic cut-off happens when using English language text (`?uselang=en`). The screenshot shows problematic cut-offs (left, with red marking), as well as expected results (right, with green marking).
{F37082344}
There was a big spike of these recently:
{F37070476}
which I think isn't that big of a deal, except the `error` parameter was unset:
{F37070478}
([[https://logstash.wikimedia.org/app/dashboards#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2023.05.25?id=lCRJU4gBs53OSt3dt24I|link]])
Or maybe this is the thing where the same field name is used with a different type for different log entries, and Logstash is unable to handle that?
In any case, it's something to be fixed in the logging code and should be looked into.
Cross-wiki notifications in Echo currently do not provide notification content cross-wiki in shared user table setups due to a dependence on CentralAuth's session token management.
== Background goal
Echo is a large app written in OOUI. We should port it to Codex, which should have most of the required components at this point. To the extent it doesn't, we should implement those components in Echo, and upstream them to Codex afterwards.
Echo also has complex state management, and would benefit from using Pinia(*).
(*) Pinia is now available in MediaWiki, see T326174.
=== Design proposal
| [[ https://www.figma.com/file/pszmvYHcXK1ais8zrP445T/Notifications---Hackathon-2023-(T337178)?type=design&node-id=2859-27333&t=EKkbeKFeJP1oZAkd-11 | Figma design proposal ]] |
These are the design proposals we worked during the Hackathon 2023:
| {F37082659} | **Option 1**: using the Codex components and keeping the same structure as the current Notifications page and popup in production. |
| {F37082661} | **Option 2**: using the Codex components and improving some aspects of the current page in production. |
**Steps to replicate the issue** (include links if applicable):
* Have some notifications that you've seen, but not read; i.e. on desktop, you have gray numbers in the alert and/or messages icons: F36961642
* Navigate to a mobile site (Minerva skin)
**What happens?**:
* On page load, the number of notifications total is briefly visible, but then it disappears within a second, and is not replaced with the normal "red circle" showing a number of notifications: F36961644
**What should have happened instead?**:
~~The total number of unread notifications should be visible, either in a red or gray circle.~~
The total number of notifications does not appear at all.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Feature summary** (what you would like to be able to do and where):
When admin B takes action to undelete a file (on Commons) which admin A has deleted, admin A should receive an alert, similar to a revert of an edit on Wikipedia. Perhaps a similar case is undeletion of Wikipedia pages, Wikidata items etc. It appears undeletion can now be done unnoticed by admin A.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I accidently noted another admin on Commons did undelete a file I had deleted, and would have liked to be notified automatically. In this case somebody else notified me, but imho this should have been done automatically. The mentioned admin B did not comment on my talk page, nor did they initiate a procedural request for undeletion, possibly forgot to do this, or was not aware this would be de procedure.
For information, my motivation for creating this task is to be seen here: https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:1927_-_Lord_Mayor_Hugh_Lupton_(in_Mayoral_chains)_at_a_luncheon_in_Leeds_with_Lord_Harewood_(left).jpg
**Benefits** (why should this be implemented?):
In that case we could have a discussion why the file should be kept or should be deleted. In the current situation it is impossible to check if somebody reverted your decision and why they did so.
Should we do some follow-ups on improving the following items?
- the notification option is enabled automatically for all users and users cannot opt-out.
It's the only one type of notifications in Special:Preferences that users cannot opt out of it.
{F36939621}
- the notification doesn't differentiate on types of updates that are done on User talk page, i.e. "add a new topic", reply, deleting topics/replies, adding wikilove - all actions will have the same wording: "[a username] left a message on your talk page in [topic title]"
- when an update involves deleting of a topic or deleting of a reply, having a notification to say "[a username] left a message on your talk page" s might be confusing for users
As a follow-up for [[ https://phabricator.wikimedia.org/T324849#8746971 | T324849#8746971]] (thx, @Astinson!)
The `page-linked` notification has secondary links: "All links to this page" and "Mute/Unmute link notifications on [page title]". Those links
(1) overlap each other
{F36938606}
(2) the clickable area is big
{F36938608}
Even on Special:Notifications page the links on `page-linked` notifications are placed too close to each other:
{F36938610}
#### User story:
As a Wikimedian, I want to make sure there are enough mentors on my wiki, so that newcomers are receiving the support they need to remain engaged and retained.
#### Background:
We should invite experienced enough users to become mentors: {https://phabricator.wikimedia.org/T271317}
####Initial test:
At Growth pilot wikis we can create a list of users which meet certain criteria and Ambassadors can evaluate if they think it's a decent list of potential mentors.
####Acceptance Criteria:
Create a list for arwiki, bnwiki, cswiki, eswiki of users that meet the following criteria:
- Have not been a Mentor in the past
- 0 local or global blocks
- 5+ Thanks received
- 500+ mainspace Wikipedia edits
- 500+ talk page edits
Note: ideally we would want to make some or all of this community configurable in the future, but we will still need to decide on a reasonable baseline to suggest.
When all your notifications are read, the notification icons at the top of the page are supposed to be 50% opacity.
This works fine in Vector 2010:
{F36817931}
However in Vector 2022 they are full opacity to begin with...
{F36817936}
...until you click on them to open the dropdown, at which point they get replaced with OOUI versions and take on the correct opacity:
{F36817938}
//Update://
The decided fix is to never use 50% opacity as that looks like a disabled button, which they aren't.
**Steps to replicate the issue** (include links if applicable):
* Have email notifications for mentions enabled
* Make your user language English
* Have user who's user language is Russian mention you in an edit that contains a user-language dependent text such as https://www.wikidata.org/wiki/Template:Property
**What happens?**:
You receive an email whose language-dependent text is in the language of the user who sent the notification.
{F36166348}
In this case I recieved an email that had Russian when my user language is English.
Link to comment: https://www.wikidata.org/wiki/Property_talk:P10726#c-Lockal-20230112085200-Push-f-20221213090300
**What should have happened instead?**:
It should have showed the English labels of the Wikidata entities.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Feature summary** (what you would like to be able to do and where):
When I ctrl-click or shift-click on a notfication, it should mark itself as read in the notification list.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
When I ctrl-click on notifications currently from the top bar dialog and am directed to the page in another window or tab. However when I return to the original tab, it's really weird and annoying to see that they aren't marked as read in the notification list even though I clicked on them. Therefore, I usually manually mark them as read after doing this in order to get rid of them in the current tab which is annoying to do.
**Benefits** (why should this be implemented?):
Better user experience.
####User story:
As a community, I want to control whether newcomers receive revert notifications, because this decision should be left to communities.
**Related:**
- {T273787}
- {T91909}
- {T303566}
#### Acceptance Criteria:
Given I am an Admin,
When I want to change the default and ensure newcomers receive a revert notification,
Then that is Community Configurable
**Feature summary** (what you would like to be able to do and where):
It would be great to have the notification status (number and icon status) synchronized.
One way to do a lightweight version would be to synchronize using [[ https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event | localStorage events ]]. That would work at least within a single project. That could also be done with no changes on the API/server side. So should be a fairly easy change :).
You could pull state from server, but that would be heavy when working with many tabs. You would still have to do some optimisation to only pull state for current tab and still sync the state via other means then network. You could use workers I guess, not sure how it would work with many tabs though.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
# Someone responds to a topic I subscribe.
# I open many tabs e.g. to review changes in observed articles.
# All of the tabs get notifications.
# I read the notification on one of the tabs. Mark it as read.
# I go back to reviews, closing each tab one by one.
# Each of the tabs still has an unread notification.
Unread notifications are just distracting. I never know if I already read them or if the state is broken.
Sometimes I even re-open or reload all tabs to get the status cleared.
**Benefits** (why should this be implemented?):
Everybody that opens many tabs. I know users that literally have 100s of tabs open and work on them.
Per {T161647}, Echo should use JSON for serialization, not native `serialize()`. It stores some serialized data potentially forever (see T323236) so the switch will require a migration script.
PHP will [[https://wiki.php.net/rfc/phase_out_serializable|lose the ability]] to unserialize the data (as it is using the older, deprecated variant of PHP serialization) in 9.0.
When I go to https://ku.wikipedia.org/wiki/Taybet:Agahdar%C3%AE , I see the date in English:
{F35838245 size=full}
The date string //probably// comes from moment.js. This library has localization for `ku`, although the content appears to be in the Arabic script, so perhaps it's better for `ku-arab` or `ckb` locale. But in any case, we see it in English, and not even in Arabic-script Kurdish.
What complicates things further is that Moment.js appears to be going into maintenance mode, which may make contributing correct Latin-script localization harder. But if that is done, can the translators at least be sure that it will be used in MediaWiki?
When a mentor quits, a notification is sent by email to their mentees:
{F35599992}
At the moment, the notification's primary information is not highlighted, but the secondary information is.
As seen with @Rho:
"[user] is now your mentor" should be the primary information, bigger and bolder.
Reason should be slimmer and lighter.
The issue is a follow-up on {T318007}
Steps to reproduce
1. Log as a user who have >25 cross-wiki notifications (or go to Special:Notifications page and mark as unread some notifications, so the Echo badge notification count will be >25)
|{F35531093}|{F35531098}
2. Click on the Echo notification badge and click on **Mark as read** for the cross-wiki notification.
{F35531101}
What happened:
- The counter won't change which might be correct since only 25 notifications were discarded.
{F35531108}
- the cross-wiki notifications disappear entirely which is incorrect since only 25 should be discarded
3. Reload the page - the counter remains 99+ and the cross-wiki notifications reappear with the initial count of 100.
4. Repeat the step 2 - the counter changes the count to 80 and the cross-wiki notifications disappear again.
{F35531115}
5. Reload the page - the cross-wiki notifications are displayed again. After that each click on **Mark as read** will subtract 25 from the count (as it should be).
The main issue here - the cross-wiki notifications disappear from the Echo drop-down. That, along with users not knowing that **Mark as read** removes (marks as read) only 25 notifications from the drop-down, creates confusion whether the **Mark as read** action worked at all and what status cross-wiki notifications have.
Notes
- [[ https://drive.google.com/file/d/1xD9kNsZd4wVe0FYWJLFf12SR0fTOyUn0/view?usp=sharing | the screen recording ]] of the above steps
Once the few remaining legacy EventLogging schemas have been removed from the production codebases or migrated to Event Platform schemas, `EventLogging::logEvent()` will only be used as a proxy for `EventLogging::submit()`. It should be deprecated in order to narrow the EventLogging PHP API.
=== TODO
[x] Always pass `$revId = -1` when calling `::logEvent()`
[] Update calls to `::logEvent()` with equivalent calls to `::submit()`
** Per https://codesearch.wmcloud.org/search/?q=EventLogging%3A%3AlogEvent%5C(&i=nope&files=php%24&excludeFiles=&repos=: the following repos need to be updated:
*** Campaigns: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Campaigns/+/884987
*** GrowthExperiments
*** TwoColConflict
*** WikiEditor
[] Update `::logEvent()` to emit a deprecation notice
[] Remove `::logEvent()` after the next MediaWiki release
**Feature summary** (what you would like to be able to do and where):
Current behavior is you subscribe to a busy thread, it gets 100 new edits overnight, but the notification dropdown tray groups them into one group of 25 (25 is some kind of hard-coded maximum).
You then click on "All notifications" as a workaround, hoping to see the rest of the notifications grouped together, but this view loses the groupings completely.
The problem with a maximum of 25 is you'll often only end up seeing the most recent 25 revisions highlighted, which means that you're reading things out of order. That is, you're reading the most recent replies, without reading some in between replies.
My proposal is to lift the cap of 25. If there's 100 replies to the same thread overnight, I'd like it to group all 100 notifications together, and let me click on it as one item, and then go to the page and highlight those 100 paragraphs that changed.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
**Benefits** (why should this be implemented?):
While discussing T299657, and the new notification it will introduce, the Editing Team discussed the potential for people to become frustrated/distracted/etc. by the number of Echo notifications they are receiving.
To preempt/avoid this scenario, @nayoub suggested we introduce a new notification that people would receive that invites them to decide whether they would like to make any adjustments to: **A)** the types of events they are being notified about //and// **B)** the channel through which they are notified about these events (e.g. in-app, browser, email).
This ticket involves the work of introducing the notification described above.
=== Story
**As someone** who is consistently being notified about events that may or may not be relevant to them, **I want** to be reminded about the power I have to adjust what events I am notified about and how I am notified about said events **so that** I do not become distracted and annoyed by alerts that are of little interest/value to me.
=== Requirements
{F35491822}
Notification with a "notice" OOUI icon and "Manage notifications" CTA (with a "Settings" OOUI icon)
UX Copy to be confirmed: "You have been receiving many notifications lately".
=== Done
- [ ] Requirements are drafted and implemented
For the initial work on this task, we'll do some research and take notes [timeboxed to ~2 hours] as to what might be causing this issue.
---
**Steps to replicate the issue** (include links if applicable):
* Perform five failed login attempts on a non-mediawiki.org wiki
* Receive the email notification and click the link shown there (such as https://mediawiki.org/wiki/Special:MyLanguage/Help:Login_notifications?markasread=253897463&markasreadwiki=enwiki)
**What happens?**:
The notification is still unread in Echo:
{F35437438}
**What should have happened instead?**:
The notification should have been marked as read.
**Steps to replicate the issue** (include links if applicable):
* Have more than 100 notifications, which will show a "99+" badge at the notifications icon.
* Click a link with a "markasread" URL parameter, as received in email notifications.
**What happens?**:
* The badge now shows "99" even when you have more than 99 notifications.
* This is only updated once you click the Echo icon. (Repeating the above will even make the number a "98" if you don't click it in between.)
**What should have happened instead?**:
* The badge should have stayed at "99+".
**Feature summary** (what you would like to be able to do and where):
- As a user, I'd like to be able to prevent "pings" ([[ https://en.wikipedia.org/wiki/Help:Notifications#Mentions | echo mentions ]]) from alerting me when they are generated on certain pages, so that I can cut down on unnecessary (and/or stressful) notifications and focus on the tasks I want to complete "on-wiki".
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
- On high-//interaction// pages, the number of direct user mentions can often cause a significant number of notifications to be generated.
- Sometimes //multiple users// are generating mentions on a given page, making per-user "muting" ineffective.
**Benefits** (why should this be implemented?):
- Being able to "mute" mentions for a given page can reduce stressful interactions where a user is trying to disengage from a situation.
- A reduction in unnecessary notifications generated from a given page helps cut down on distracting alerts.
**Considerations**
- Mentions were //designed// to get the attention of a user, and other editors may assume a user is "ignoring everyone" if a key administrative discussion (e.g. the English Wikipedia's "[[ https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents | Wikipedia:Administrators' noticeboard/Incidents ]]" page) is on their muted list of pages — users are free to turn off mention notifications entirely (https://en.wikipedia.org/wiki/Help:Notifications#Opt-in_and_opt-out), and as such should not be relied on for getting a user's attention.
**Feature summary**
When someone posts on my talk page, I currently get TWO pings. Interesting implementation... that might actually be worth a separate ticket.
And of course it displays the giant orange bar. Anyway, oftentimes my workflow is I go read the message (which marks the ping read). But then I go to my ping drawer and mark it as unread again so I don't forget to work on it. However marking it unread again brings back the orange bar.
1) Would be nice if marking a once read ping as unread would not bring back the orange bar.
2) Re-visiting the user talk page should not clear all user talk pings. Other ping pages don't work like this, it's unique to user talk.
**Use case(s)**
**Benefits**
Improved ability to use pings as a "todo list". Improved differentiation between a new talk page message and an old talk page message.
{F35272516}
**List of steps to reproduce** (step by step, including full links if applicable):
* Use the Vector 2022 skin
* Have a large number of notifications (see below for a bit of Javascript if that's not already the case)
* Set the browser's default font size in the settings to something larger, e.g. very large in Chrome-based browsers or 150% zoom with only the "only text" option selected in Firefox
* or, set the interface language to Classical Chinese (some other languages which use their own numeral systems also have the same problem, although less prominently)
**What happens?**:
The notification icons overlap.
**What should have happened instead?**:
The notification icons should adjust to the size of the text and not overlap.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
A bit of Javascript to make the interface mimic having the maximum number of notifications:
```for (let e of document.querySelectorAll("#pt-notifications-alert a, #pt-notifications-notice a")) {
e.dataset.counterText = mw.language.convertNumber("99+");
e.dataset.counterNum = "100";
e.classList.add("mw-echo-notifications-badge-long-label");
e.classList.remove("mw-echo-notifications-badge-all-read");
}```
Chrome-based browser using English and very large font sizes:
{F35269158}
Chrome-based browser using Classical Chinese and default font sizes:
{F35269160}
Firefox using English and default font sizes:
{F35269176}
'enotifminoredits' stands for "Email me also for minor edits of pages and files" and it is //disabled// by default.
`EchoNotificationController::notify` does the following:
```lang=php,name=includes/controller/NotificationController.php
foreach ( self::getUsersToNotifyForEvent( $event ) as $user ) {
$userIds[$user->getId()] = $user->getId();
$userNotifyTypes = $notifyTypes;
// Respect the enotifminoredits preference
// @todo should this be checked somewhere else?
if (
!$userOptionsLookup->getOption( $user, 'enotifminoredits' ) &&
self::hasMinorRevision( $event )
) {
$userNotifyTypes = array_diff( $userNotifyTypes, [ 'email' ] );
}
```
Ultimately, when you are thanked for a minor edit, have thanks sent to your email and have the option disabled, no email is sent to you.
It's somewhat weird and unexpected because the option is phrased as "Email me also for minor edits of pages and files", but thanks is not "an edit", it's a "thank you for an edit".
**Original report:** https://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou_(technika)#Upozorn%C4%9Bn%C3%AD_na_pod%C4%9Bkov%C3%A1n%C3%AD
**Feature summary** (what you would like to be able to do and where):
Be able to actively notify the secret list of page watchers that a page they are watching has been created or edited, for certain creations or edits.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Certain edits to a page can be considered extra important, for example starting a project workflow relevant to the page such as a deletion discussion or a major rewrite of a page such as a new version of a project policy. People watching a page can easily overlook these if they have a busy watchlist.
To address this: When creating a new page or revision, allow certain editors to request sending a notification to all page watchers of the creation/edit.
**Benefits** (why should this be implemented?):
This allows page watchers to remain secret, while still being able to actively notify them of significant changes.
**Notes**
This feature could be abused, so suggest that it (a) require a permission to use, similar to how "minoredit" is required to flag an edit as minor. Use of this feature should also be logged, possible with the existing revision flags, maybe in its own log. By default permission should be included with sysop - projects can determine what other groups are appropriate case-by-case.
{T203941} is resolved, so this is ready to be deployed to production wikis.
TBD: A deployment and communication plan around that.
[[ https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Notifications,_Watchlists_and_Talk_Pages/On-wiki_notifications_for_the_Watchlist_or_subscriptions_per_page | Community Wishlist Survey 2023/On-wiki notifications for the Watchlist or subscriptions per page ]]
Flow and DiscussionTools make their own notifications, we don't need a duplicate notification saying that the relevant watched page was also modified.
Acceptance criteria:
- [ ] DiscussionTools notifications are not duplicated with a Watchlist notification
- [ ] Flow notifications are not duplicated with a Watchlist notification
Sometimes I edit some discussion and relevant section turns to [subscribed]. But I didn't noticed any response in that sections.
Now I found I have in my options disabled notification for subscribed sections, so I was never informed about new reply when I was relying to notification.
Then I enabled it, but have dozens of notifications for pages also in watchlist :-( , see T287790
=== Notes
Currently, it's possible for two things to happen:
1. {nav [ subscribe ]} affordances appear on talk pages you visit
2. You become automatically subscribed to discussions you comment in and start
3. You will NOT receive any notifications for new comments in sections you've subscribed to **IF** none of the notification delivery options are enabled for the `Talk page subscription` setting within `Special:Preferences#mw-prefsection-echo`
Echo notifications can take up significant DB space. On Wikidata, a particularly bot-heavy wiki with lots of edits, discarding notification sent to bots would probably free up considerable DB space (tens of gigabytes).
A similar thing was done for watchlist entries of Wikidata bot accounts in the past: {T258098}
This could be used for integration tests. The REST routes should probably be in the development section so that it's not enabled in production, or otherwise there needs to be a mechanism to prevent abuse.
MediaWiki is not using the timestamp datatype on its schema. Needs data migration.
See {T283461}
Should be done after the abstract schema T259375
**Feature summary**:
I want to send an echo notification to **myself**. The most obvious and versatile way would be to make this possible using the API, but JS would work for me as well.
**Use case(s)**:
My userscript cooks things in the background. If/when it has found something, it has to notify the user somehow. mw.notify is just a fleeting notification that can be missed while taking a sip of one's tea. Other solutions generally don't carry over to other sessions/devices/browsers. And, errr, there already //is// a perfectly good notification system and area in place, I just can't use it!
**Benefits**:
Allow userscripts/gadgets/anything that's not an extension to take advantage of echo notifications.
This feature request is different from T58362 as I am requesting only notifications to **self** (which takes away a whole lot of potential abuse factors) and no special page or user interface, just API.
Possibly this is a regression?
Noticed when namespacing #mediawiki-extensions-newsletter....
I can't do
```lang=php
'user-locators' => [
[ EchoNewsletterUserLocator::class, 'locateNewsletterSubscribedUsers' ],
],
```
BlueSpice does
```lang=php
'user-locators' => [ static::class . '::getSysops' ]
```
so I've had to do...
```lang=php
'user-locators' => [
[ EchoNewsletterUserLocator::class . '::locateNewsletterSubscribedUsers' ],
],
```
Which feels hacky...
**List of steps to reproduce** (step by step, including full links if applicable):
* {F35013133}
* https://en.wikipedia.org/w/index.php?title=User_talk:Donald_Trung&oldid=prev&diff=1078291126
* https://en.wikipedia.org/w/index.php?title=User_talk:Donald_Trung/Archive_85&oldid=prev&diff=1078291147
**What happens?**:
The first mention (bottom) is fine. Donald said "{{Ping|Alexis Jazz}}" and inserted a signature.
The second mention (top) is a mystery to me. It's a tool-assisted archive action. The summary says "([[https://en.wikipedia.org/wiki/User:Technical_13/1CA | OneClickArchiver]] adding [[https://en.wikipedia.org/wiki/User_talk:Donald_Trung/Archive_85#How_to_make_Global_JS|How to make Global JS]])", no mention there. The two timestamps in the text are from 17 March 2022, clearly not added in an edit made on 20 March 2022. So //why// did I get a mention for this? I never did before, and Donald has been using OneClickArchiver for ages.
I wasn't notified about https://en.wikipedia.org/w/index.php?title=User_talk:Donald_Trung/Archive_85&diff=1077176509&oldid=1077176497 which would seem similar. Haven't changed my settings either.
**What should have happened instead?**:
No mention for archiving edits?
**List of steps to reproduce** (step by step, including full links if applicable):
* Echo extension: https://mediawiki.org/wiki/Extension:Echo
* Click bell icon
* Inspect elements
* Click bell icon
* Inspect elements
* Click bell icon
* Inspect elements
* Click bell icon
* Inspect elements
**What happens?**:
There is a bug in extensions/Echo/modules/ui/mw.echo.ui.ActionMenuPopupWidget.js - Every time I open and close the "Your alerts" menu dialog (bell icon), the div.mw-echo-ui-NotificationBadgeWidget-overlay-menu gets appended to with the same content that already was previously appended to during previous clicks.
I tested on the home page and another page,and same issue
The JavaScript code looks like it's easy to spot the issue at quick glance
e.g. no if condition to determine if the append elements are already appended previously
**What should have happened instead?**:
No duplicate appends
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
**Request Status:** New Request
**Request Type:** project support request
**Related OKRs:** iOS FY21-22
**Request Title:** Get full text of echo notifications
--
- **Request Description:** Echo notification system truncates long notifications at 150 characters. This means we can't show full notifications to users. Long notifications are shown truncated, reducing usefulness of the notification and reducing trust in the notifications overall.
We recognize there may be performance reasons to truncate notifications when making an API request that returns many notifications. While we could remove the character limit for the existing API, another solution would be to have a new simple API - send a request w/ notification revision ID, and (if user is properly authorized) return the entire body text of the notification.
- **Indicate Priority Level:** Medium
- **Main Requestors:** iOS team (this also improves Android app)
- **Ideal Delivery Date:** mid-April 2022
- **Stakeholders:** Wikipedia notification users that use the iOS or Android app (especially experienced editors)
**Request Documentation**
--
|**Document Type**| **Required?** | **Document/Link** |
| **Related PHAB Tickets** | Yes | <add link here> |
| **Product One Pager** | Yes |<add link here> |
| **Product Requirements Document (PRD)** | Yes | <add link here> |
| **Product Roadmap** | No | |
| **Product Planning/Business Case** | No | |
| **Product Brief** | No | |
| **Other Links** | No |OKR: https://docs.google.com/document/d/1ClZdFuSLCdlPkHppkWAcq3YsWJ2dMahTDqr-gUYOOpo/edit |
{F34974587}
**What happens?**:
en: Xiplus changed group membership for User:Cys wang mc from (none) to ipblock-exempt
qqx: (logentry-rights-rights: Xiplus, Xiplus, User:Cys wang mc, (rightsnone), ipblock-exempt, Cys wang mc)
**What should have happened instead?**:
en: Xiplus changed group membership for User:Cys wang mc from (none) to IP block exempt
qqx: (logentry-rights-rights: Xiplus, Xiplus, User:Cys wang mc, (rightsnone), (group-ipblock-exempt-member: Cys wang mc), Cys wang mc)
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
MediaWiki 1.38.0-wmf.24 (f9858b2)
**Feature summary**:
The bell (alert) and inbox (notification) icons always show messages. If you have no new messages, it shows unread messages.
**Use case(s)**:
Some users would prefer to see an empty inbox. See [[https://en.wikipedia.org/w/index.php?title=User_talk:ARoseWolf&oldid=1070548696#Some_basic_beginner_questions_from_GavriilaDmitriev_(talk)_14:18,_2_February_2022_(UTC) |this discussion]].
Currently with the Echo extension for 1 single comment added, I usually get 2 emails. One notifies me that the page I had automatically watchlisted because I wrote in it has been changed, the other notifies me that I have a new reply in this conversation I had automatically subscribed while being its starter.
This makes me get double emails for almost everything and feels redundant. Echo email notifications triggered from the same action (as in the aforementioned case) should be bundled into a single email, providing you all the needed information in it.
Two Selenium gate-and-submit builds ([#96757](https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-selenium-docker/96757/console) for [change 731277](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/731277), and [#96764](https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-selenium-docker/96764/console) for [change 748299](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/748299)) have failed with the same errors:
```counterexample
[0-0] Error in "Echo.checks for welcome message after signup"
Error: element (".mw-echo-ui-notificationItemWidget-content-message-header") still not displayed after 5000ms
at /workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/commands/browser/waitUntil.js:66:23
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.elementErrorHandlerCallbackFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/middlewares.js:24:32)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.elementErrorHandlerCallbackFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/middlewares.js:24:32)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Context.<anonymous> (/workspace/src/extensions/Echo/tests/selenium/specs/echo.js:56:3)
[0-0] RETRYING in chrome - /tests/selenium/specs/echo.js
[0-0] RUNNING in chrome - /tests/selenium/specs/echo.js
[0-0] Error in "Echo.checks for welcome message after signup"
Error: element (".mw-echo-ui-notificationItemWidget-content-message-header") still not displayed after 5000ms
at /workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/commands/browser/waitUntil.js:66:23
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.elementErrorHandlerCallbackFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/middlewares.js:24:32)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Element.elementErrorHandlerCallbackFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/webdriverio/build/middlewares.js:24:32)
at async Element.wrapCommandFn (/workspace/src/extensions/Echo/node_modules/@wdio/runner/node_modules/@wdio/utils/build/shim.js:131:29)
at async Context.<anonymous> (/workspace/src/extensions/Echo/tests/selenium/specs/echo.js:56:3)
[0-0] FAILED in chrome - /tests/selenium/specs/echo.js (1 retries)
```
After T108190, there are two categories for notifications, Alerts, and Messages.
However, Minerva Neue has only one button for notifications for some reason. Behind the scene, Minerva just places a `<a href="…/Special:Mytalk…">` element and runs SkinMinervaReplaceNotificationsBadgeHook, then Echo takes the hook and provides a notification button.
This should be possible for other skins. It would be a simple renaming of SkinMinervaReplaceNotificationsBadgeHook, or be a more generic means in the perspective of #MediaWiki-Core-Skin-Architecture.
I have a notice group with 76 items (every notice item is from another wiki). If i click on //mark as read//, so in the result the notice group doesn't mark as read.
Every time i see (on wiki):
{F34893707}
Many times, a revert is accompanied by a message on the user's talk page. In the Notifications API, we'd like any relevant user talk page message IDs to be included with revert notifications.
Essentially, take the revert ID, use the Talk Page API (https://en.wikipedia.org/api/rest_v1/page/talk/User_talk:Jimbo) and see if any of the HTML snippets include the revert ID. If so, that talk page message's sha should be returned in the notification API as part of the revert notification object.
**Feature summary** If User:Alice has subpages under their own userpage, and User:Bob moves one of those subpages, then User:Alice should be notified.
**Benefits**: This would help users to be aware of good-faith or malicious page-moves that are directly related to them.
Requested [[https://en.wikipedia.org/w/index.php?title=Help_talk:Notifications&oldid=1058224440#A_useful_notification|here at Enwiki]].
See also:
* {T166924}
* {T5234}
I'm splitting this from {T296270} as the follow-up discussion.
>>! In T296270#7524650, @Umherirrender wrote:
>>>! In T296270#7524590, @Legoktm wrote:
>>>>! In T296270#7524505, @Umherirrender wrote:
>>> The default of true seems to be set in wmf config, not extension config.
>>>
>>> Maybe the order of loading config is now a problem, when the hook is running after the settings is set and overrides it.
>>>
>>> https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/8b9e94cd0955d66344d706f4450e66f04683c86a/wmf-config/CommonSettings.php#3228
>>
>> I think so, the hook is overwriting the config...which would mean it's impossible to set defaults for any of the other settings?
>
> Also in Pre-UserOptionsLookup code [1] the hook overrides the defaults from LocalSettings.php.
> It seems that options from the hook could not get values from the config. But the global is for that purpose.
>
> It is not possible to change the order, because echo also looks for default of core settings, which should reflect changes in LocalSettings.php as well ... (but that is part of my patch set and could be removed as well).
>
> The options with a fix name could be moved to extension.json, but the variable named options are not ready for overrides (but that is not new to echo extension).
> Fixing all hooks to check if the option is already set is also much work and could be broken in future again.
>
>
> [1] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/REL1_34/includes/user/User.php#1703
> [2] https://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions
As reported in T295621, this notification is one of (if not the only) notifications which directly takes the user away from a MediaWiki project. As such, the default way of marking the notification as read doesn't work.
Users are sent to a URL like https://wikipedialibrary.wmflabs.org/?markasread=4013139&markasreadwiki=metawiki. The query parameters would mark the notification as read if the destination was another Wikimedia project, but don't do anything on the Library Card platform.
We should investigate how to mark the notification as read when clicked.
Per @Legoktm: "Another option could be to add TWL to the Interwiki map and use links like https://meta.wikimedia.org/wiki/Special:GoToInterwiki/google:foo to provide an interstitial and have the markasread query parameters work."
The echo notification for https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Johannnes89&oldid=prev&diff=217190931 is persistently broken: The heading's words are displayed in the wrong order. See the attached screenshots for the broken display.
The notification's href attribute is `https://de.wikipedia.org/wiki/Benutzer_Diskussion:Johannnes89?markasread=46990807&markasreadwiki=dewiki#c-Johannnes89-2021-11-11T19:29:00.000Z-ToBeFree-2021-11-11T18:42:00.000Z`.
{F34742470}
{F34742469}
Expected output, from left to right: A right-to-left username, and then a left-to-right "CU-gesperrt" string.
Wikitext output: As expected.
Echo notification output: a left-to-right "CU-gesperrt" string, and then the right-to-left username.
Seemingly a repeat of {T227009}; was disabled in {e76e9f9b5ca522027ba349ac59a432f810168faa} and re-enabled in {05f3e66a9d7e9867d732d15cbd981baf80849a79}
Seen in an unrelated MW patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/734676/ in job https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/120153/console
```
16:49:49 [0-0] Error in "Echo checks for welcome message after signup"
16:49:58 element (".mw-echo-ui-notificationItemWidget-content-message-header") still not displayed after 5000ms
16:49:58 INFO:backend.PhpWebserver:[Tue Oct 26 16:49:59 2021] 127.0.0.1:33748 [200]: /api.php
16:49:59 [0-0] FAILED in chrome - /tests/selenium/specs/echo.js
```
It was pointed out to me recently that when someone is renamed or for other reasons we may want to consider a redirect for a user (For example, the 2-3 usernames associated with Jimmy that redirect to his main user account - or some staff accounts with possible reasons for redirects) - if someone were to ping that redirect based username, it will not ping the new or actual username.
So for example:
I {{ping|OldUsername}} it will not alert the person at User:NewUsername even if a redirect page is setup from User:OldUsername to User:NewUsername.
It would be great if a ping could follow a redirect to a user's correct or new username. Potentially on a restricted level of some sort to prevent abuse creation of user pages taking up potential usernames.
**List of steps to reproduce** (step by step, including full links if applicable):
* Keep open a tab with some Echo buttons.
* Log out for testing purposes (usually this happens automatically, hence why it is important to communicate in message).
* Try to open a notification drawer.
* Read ‘There are no notifications’ message (`MediaWiki:Echo-notification-placeholder`) instead of something that would indicate that the user has been logged out.
**What should have happened instead?**:
Echo extension should indicate that the user is logged out if API returns a response indicating that. For Echo notifications, that is currently the case:
```
{"error":{"code":"login-required","info":"You must be logged in.","docref":"See https://ru.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."},"servedby":"mw1388"}
```
The error should be caught and displayed to user, so they would not be mistaken that they don’t have or have lost all their notifications somehow.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
Any
There are two ResourceLoader modules, `ext.echo.dm` and `ext.echo.logger`, that are only loaded by and used in `ext.echo.ui` - these should be merged in, to reduce the module count and the size of the registry that is loaded on all views.
Note that the logger uses package files but `ext.echo.ui` doesn't yet, so that will be trickier to merge
I have email notifications enabled globally for all listed events (except for "Comment on subscribed talk page topics" and "Translations", which appear to be recent additions), as well as web notifications. However, over the last month, email notifications appear to have skipped a few events, especially thanking actions, though one undo too.
On the English Wikipedia, while having been notified via web about the following actions (as seen from the screenshots below), the email notifications did not get sent.
* Thanked for [[https://en.wikipedia.org/wiki/Special:Diff/prev/1039119683]], [[https://en.wikipedia.org/wiki/Special:Diff/prev/1039119729]], [[https://en.wikipedia.org/wiki/Special:Diff/prev/1044105183]].
{F34646495}
{F34646497}
On Commons, while having been notified via web about the following actions (as seen from the screenshots below), the email notifications did not get sent.
* Thanked for [[https://commons.wikimedia.org/wiki/Special:Diff/prev/586196445]], [[https://commons.wikimedia.org/wiki/Special:Diff/prev/585431053]],
* Undone at [[https://commons.wikimedia.org/wiki/Special:Diff/prev/591530531]].
{F34646499}
{F34646501}
----
Edit: Another batch of undo alerts missing email notifications from Commons:
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506148]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506138]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506094]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506090]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506087]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593506064]]
* [[https://commons.wikimedia.org/wiki/Special:Diff/prev/593505969]]
{F34654551}
Hi, while running a script calling `action=growthsetmentor` a lot, I noticed that it's way less performing than I'd expect it to (it should only do permission checks, a write DB query, and sending an echo notification). However, I noticed that the endpoint takes more than expected (sometimes, over a second), and filled {T291212} to investigate.
Per https://performance.wikimedia.org/xhgui/run/view?id=614386f2f09ba49ec8ee85e8, MultiHttpClient::runMultiCurl is what takes the most time. Since nothing in ChangeMentor uses HTTP requests, I tried to wrap ChangeMentor::notify (which fires an echo notification) with a DeferredUpdate, and noticed it speeds things up significantly (down to 60ms per API call).
It appears that Echo indeed uses requests in push notifications:
```
urbanecm@notebook ~/unsynced/gerrit/mediawiki/extensions/Echo
$ git grep Http
ServiceWiring.php: $httpRequestFactory = $services->getHttpRequestFactory();
includes/ForeignWikiRequest.php: $http = MediaWikiServices::getInstance()->getHttpRequestFactory()->createMultiClient();
includes/Push/NotificationServiceClient.php:use MediaWiki\Http\HttpRequestFactory;
includes/Push/NotificationServiceClient.php:use MWHttpRequest;
includes/Push/NotificationServiceClient.php: /** @var HttpRequestFactory */
includes/Push/NotificationServiceClient.php: * @param HttpRequestFactory $httpRequestFactory
includes/Push/NotificationServiceClient.php: public function __construct( HttpRequestFactory $httpRequestFactory, string $endpointBase ) {
includes/Push/NotificationServiceClient.php: * Construct a MWHttpRequest object based on the subscription and payload.
includes/Push/NotificationServiceClient.php: * @return MWHttpRequest
includes/Push/NotificationServiceClient.php: private function constructRequest( string $provider, array $payload ): MWHttpRequest {
tests/phpunit/integration/Push/NotificationServiceClientTest.php: use MockHttpTrait;
tests/phpunit/integration/Push/NotificationServiceClientTest.php: $this->installMockHttp( 'hi' );
tests/phpunit/integration/Push/NotificationServiceClientTest.php: $this->assertInstanceOf( MWHttpRequest::class, $request );
tests/phpunit/revision_txt/138274875.txt:::::Irgendwo kam ein <code>forceHttps</code>-Cookie her, jetzt ist es weg. Es fallen immer noch viele Dinge beim reinen Überfliegen auf:
tests/phpunit/revision_txt/138275105.txt:::::Irgendwo kam ein <code>forceHttps</code>-Cookie her, jetzt ist es weg. Es fallen immer noch viele Dinge beim reinen Überfliegen auf:
urbanecm@notebook ~/unsynced/gerrit/mediawiki/extensions/Echo
$
```
Can push notifications be made more faster? To me, as a developer using Echo's interface to fire notifications, it is unexpected that it will take this long -- I'd expect notification to be nearly-instant.
Push notification support is only enabled on wikis in the [[ https://noc.wikimedia.org/conf/highlight.php?file=dblists%2Fwikipedia.dblist | wikipedia ]] group at present. This is accomplished using the `EchoEnablePush` config setting provided by the Echo extension.
A few wikis had to be individually excluded yesterday to resolve a train blocker (T291128). This solution is brittle because the problem could reappear anytime a new private wiki is added to the `wikipedia` group. This task is to implement a more future-proof solution.
Potential solutions:
# Create the push tables in private wiki DBs, and enable the `push` notifier type universally. This would have the added benefit of allowing the `push` notifier type to be defined and configured in Echo like the `web` and `email` types rather than being special-cased in [[ https://github.com/wikimedia/operations-mediawiki-config/blob/e196cbe410589aacea092da56d91b2162e4d3460/wmf-config/CommonSettings.php#L3197-L3210 | CommonSettings.php ]]. The drawback is that this could potentially cause the users of the Wikipedia apps to receive notifications for wikis irrelevant to them, but this could be handled by the app clients (either by appropriate use of per-wiki filtering when requesting notification content, or post-hoc filtering of received notifications).
# Investigate options for updating configuration to be more future-proof, e.g., to exclude non-SUL wikis by group. (Would `$wgEchoEnablePush = [ 'default' => false, 'wikipedia' => true, 'special' => false ]` have the desired effect? Note that [[ https://www.php.net/manual/en/language.types.array.php | arrays in PHP are actually ordered maps ]], so if MediaWiki applies these rules in the order defined, it should work.)
# Create the `echo_push_*` tables in the local DBs of all non-SUL wikis, even if there are no immediate plans to use them.
In T286954#7314813, @iamjessklein entered the potential that Junior Contributors might not intuitively understand what the `echo-category-title-edit-user-talk` event, and its associated tooltip (`Echo-pref-tooltip-edit-user-talk`), are referring to.
This ticket involves the work with learning the answers to the ===Open questions below so that we can decide whether it would be worthwhile to adjust the language used to describe these settings. //Note: this language was last changed in T286954.//
=== Open questions
- [ ] What do Junior Contributors intuitively understand the `echo-category-title-edit-user-talk` event, and its associated tooltip (`Echo-pref-tooltip-edit-user-talk`) to mean? What do they think they will //not// be notified about were they to disable this setting?
In T286954#7315586, @matmarex entered the potential that people being notified about every edit that is made to their user talk page as being unhelpful.
This ticket involves the work with learning the answers to the `===Open questions` below so that we can decide whether there would be value in revising what kinds of edits to their user talk pages people are notified about.
=== Open questions
- [ ] For what reason(s) are people notified about //every// edit that is made to their user talk pages?
- [ ] What workflows and or tools have emerged that now depend on people being notified about //every// edit that is made to their user talk pages?
=== Done
- [ ] All `===Open questions` are answered and documented
**List of steps to reproduce**:
* Open any wiki where you have notifications, preferrably //bundled// ones, like in this pic: {F34621223} Bundled notifications may also come from #discussiontools' topic subscriptions, for instance: {F34621242} (In my case, bundled items were ones to have overlay menus, but actually all items create a `.mw-echo-ui-actionMenuPopupWidget-menu` element, even if empty.)
* Click the "Notices" notification badge once {F34621227}
* Open DevTools, search for the second `.mw-echo-ui-NotificationBadgeWidget-overlay-menu` element. Click on it to select it.
* Type `$0.childElementCount` in the console, execute.
* Close and open the "Notices" popup several times. Say, three.
**What happens?**:
* `$0.childElementCount` returns a four times bigger number. This means the previous menus were not cleaned up.
**What should have happened instead?**:
* `$0.childElementCount` should not change (unless the notification count has changed). In order to achieve that, these menus should be removed from the DOM on notification popup (or other relevant widget) teardown.
This bug has a potential of cluttering the DOM at great speed, especially given the features such as the new #discussiontools' Topic subscriptions. (It's also how I found this bug, being surprised by hundreds of child elements with unreachable menus.)
**What happened:**
# Create a thread
# Subscribe to a thread
# Get a reply (with notification) on 'Monday'.
# Reply to that.
# Get a reply (with notification) on 'Tuesday'.
# Reply to that.
# Get a reply (with notification) on 'Wednesday'.
# Reply to that.
# Get a reply 14 hours ago.
# Echo says there are **four** replies (not the expected one) and that all four of them happened 14 hours ago (not on different days).
### Description
Echo uses OOUI popup widgets for the "Alerts" and "Notices" overlays that are opened by notification icons in the person menu. Because the popup widgets are inserted at the end of the page, the only way they can be accessed by users using assistive tech is to tab through to the end of the document.
### Expected behavior
Users should be able to tab into either the "Alerts" and "Notices" overlays after opening them via the notification icons.
### Developer Notes
One possible solution is to implement a focus trap, and essentially treat the overlays similarly to OOUI dialogs.
I received a message on my personal talk page from a user who made a small markup mistake by placing template instead of a wikilink in the header section. The notification I received displayed an entire content of the included template and loaded in about a minute or two. I think the notifications system should strip or sanitize a wiki code before sending.
Diff of a message:
https://ru.wikipedia.org/?diff=115663814
Results in the notification center:
{F34563258}
Recent research showed that surfacing the impact that user translations have on readers is an important motivating factor. This ticket proposes to show to users that made a translation for an article or section, the number of views that the article got during the last month.
A notification of this kind of event will provide editors a better sense of the number of people they enable to access relevant knowledge. This ticket proposes to send notifications with the following information 30 days after a translation was published:
{F34567015, size=full}
- Message: A different version of the message is used depending on whether the user published a new article or expanded an article with a new section:
-- Your translation of <article> was viewed X times last month. Expand with a new section?
-- Your contribution to <article> was viewed X times last month. Expand with a new section?
- Main action: link to Section translation with the article pre-selected for the user to expand with a new section.
- Additional actions: Article name links to the target article for the user to check its status since it was published.
- Icon: Language icon on blue article. Similar to what is used for other Content Translation notifications, but using Accent50 (#36c) since [[ https://www.mediawiki.org/wiki/Notifications/Design_guide#Icon_colors | the notification is an update ]] (instead of a new element).
**Bundled version**
A bundled version will be also provided in order to avoid users getting overwhelmed by multiple notifications of the same type.
{F34567013, size=full}
(!!Details to be finalized!!)
# Details on the logic
Monitoring the changes made to articles to generate notifications can be a complex process. In addition, we want to make multiple checks to make sure that the notification is providing valuable information to the user. A possible approach (feel free to suggest other options) is described below:
30 days after publishing a translation (new article creation or section added), a notification will be send if all the conditions below are met:
- The article was not deleted.
- The published article received more than 100 views in the 30 days after its publication.
- There are sections missing in the article the user can expand (content sections, that is, not counting "references", "see also", etc..
- No other notifications of this type is sent in the same day. This helps reduce the volume to one proposal to expand an article per day, which can be convenient for very prolific translators. In case it is easy to select which one to send, the one with a higher number of views will be selected.
# Blockers
Since notifications are available across mobile and desktop, we can only support them once Section translation is supported in both platforms. Thus, the following ticket needs to be completed first: {T234323}
Recent research showed that users are interested in new content being available on articles they previously translated. For example, a user that has translated the Moon article from English to Bengali may be interested in a new section (e.g., "Legal status") that was added to the English version recently in order to expand and keep up to date the Bengali version.
A notification of this kind of event will help users to become aware of relevant opportunities to translate that are connected to the work they did. This ticket proposes to send notifications with the following information:
{F34567008, size=full}
- Message: "<article> was expanded with (a) new section(s) you can translate"
- Additional details: new section or sections available. "Legal status and X more" can be used to keep the message short when multiple sections.
- Main action: link to Section translation with the section pre-selected for the user to translate.
- Additional actions: Source and target language names linking to the source and target versions of the article.
- Icon: Language icon on blue article. Similar to what is used for other Content Translation notifications, but using Accent50 (#36c) since [[ https://www.mediawiki.org/wiki/Notifications/Design_guide#Icon_colors | the notification is an update ]] (instead of a new element).
**Bundled version**
A bundled version will be also provided in order to avoid users getting overwhelmed by multiple notifications of the same type.
{F34567010, size=full}
(!!Details to be finalized!!)
# Details on the logic
Monitoring the changes made to articles to generate notifications can be a complex process. In addition, we want to make multiple checks to make sure that the notification is providing valuable information to the user. A possible approach (feel free to suggest other options) is described below:
20 days after publishing a translation (new article creation or section added), the content of the source article is checked to identify new sections added since the publication. A notification will be send if all the conditions below are met:
- The article is in the main namespace
- The source article has new sections compared to the version at the time the translation was published.
- Some of the sections added are content sections (i.e., no "references", "see also", etc.)
- Some of the sections has a significant amount of content. 500 bytes was proposed as threshold in T287025 but we can pick a better threshold (ideally the same for all entry points using similar criteria).
- TBD: Think on criteria to avoid cases of repeated notifications.
# Blockers
Since notifications are available across mobile and desktop, we can only support them once Section translation is supported in both platforms. Thus, the following ticket needs to be completed first: {T234323}
**List of steps to reproduce**:
* add ` $wgEchoWatchlistNotifications = true; ` to the LocalSettings.php to get watchlist notifications
* enable web notifications for "Edit to watched page" in your notification preferences
* add a page to your watchlist
* have another user (or you on another account) delete the page
* visit Special:Notifications
**What happens?**:
an Internal error is displayed
**What should have happened instead?**:
the Special:Notifications page should be displayed
**Software version, other information, etc**:
MediaWiki Version: 1.35.1 (889d124)
Echo Version: – (fd6a33e)
error on page **Special:Notifications**
EventPresentationModel.php: Argument 1 passed to EchoEventPresentationModel::getTruncatedTitleText() must be an instance of Title, null given
```
/Special:Notifications TypeError from line 564 of <server>/extensions/Echo/includes/formatters/EventPresentationModel.php: Argument 1 passed to EchoEventPresentationModel::getTruncatedTitleText() must be an instance of Title, null given, called in <server>/extensions/Echo/includes/formatters/WatchlistChangePresentationModel.php on line 31
Backtrace:
#0 <server>/extensions/Echo/includes/formatters/WatchlistChangePresentationModel.php(31): EchoEventPresentationModel->getTruncatedTitleText()
#1 <server>/extensions/Echo/includes/formatters/SpecialNotificationsFormatter.php(45): EchoWatchlistChangePresentationModel->getHeaderMessage()
#2 <server>/extensions/Echo/includes/formatters/EchoEventFormatter.php(72): SpecialNotificationsFormatter->formatModel()
#3 <server>/extensions/Echo/includes/DataOutputFormatter.php(189): EchoEventFormatter->format()
#4 <server>/extensions/Echo/includes/DataOutputFormatter.php(149): EchoDataOutputFormatter::formatNotification()
#5 <server>/extensions/Echo/includes/special/SpecialNotifications.php(61): EchoDataOutputFormatter::formatOutput()
#6 <server>/includes/specialpage/SpecialPage.php(600): SpecialNotifications->execute()
#7 <server>/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run()
#8 <server>/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#9 <server>/includes/MediaWiki.php(940): MediaWiki->performRequest()
#10 <server>/includes/MediaWiki.php(543): MediaWiki->main()
#11 <server>/index.php(53): MediaWiki->run()
#12 <server>/index.php(46): wfIndexMain()
#13 {main}
```
```lang=sql
CREATE TABLE /*_*/echo_event (
/* [...] */
-- The agent (user who triggered the event), if any. If the agent is a logged-in user,
-- event_agent_id contains their user ID and event_agent_ip is null. If the agent is
-- an anonymous user , event_agent_ip contains their IP address and event_agent_id is null.
-- If the event doesn't have an agent, both fields are null.
event_agent_id int unsigned null,
event_agent_ip varchar(39) binary null,
/* [...] */
) /*$wgDBTableOptions*/;
```
`event_agent_id` and `event_agent_ip` should be merged to `event_agent_actor`. Beware, both fields are **nullable** (and so should probably be the new field).
See also {T259375} and {T188180}.
Notifications may contain incorrect section (anchor) links if the section contains <pre>/<nowiki> code
When I received notification about this edit:
https://commons.wikimedia.org/w/index.php?title=Commons:Undeletion_requests/Current_requests&oldid=prev&diff=568644986
it contained the link
https://commons.wikimedia.org/wiki/Commons:Undeletion_requests/Current_requests#Opis
("Opis" is Polish translation of "Description") which seems to originate from parsed <pre>/<nowiki> code:
=={{int:filedesc}}==
(which should not be parsed).
The link should be to the existent section anchor (`File:South_Australian_Railways_520_class_locomotives_--_evolution_of_design.tif` at https://commons.wikimedia.org/wiki/Commons:Undeletion_requests/Current_requests#File:South_Australian_Railways_520_class_locomotives_--_evolution_of_design.tif in this case)
=== Behavior
**Actual**
- When I get an Echo notification,
- I click unsubscribe from the overflow menu
- It displays an unsubscribe confirmation message and removes the overflow option from the Notifications window
- I need to reload the page for the "unsubscribe" button next to the actual conversation to return to "subscribe"
**Expected**
- When I get an Echo notification,
- I click unsubscribe from the overflow menu
- It displays an unsubscribe confirmation message and removes the overflow option from the Notifications window
- It automatically changes the "unsubscribe" button next to the actual conversation to "subscribe"
This was experienced in T279150
=== Environment
Browser (version): Chrome (89.0.4389.114)
Platform (version): Desktop
OS: MacOS (Big Sur 11.2)
=== Done
- [ ] "Expected" behavior is implemented
=== Description
Up until June 2021, when you had a message on your Talk page the `Talk` link in your user/personal tools area would transform into a yellow-notice-link-thing that said //You have new messages//. In other words, your normal Talk page link would be replaced by this notice.
In the course of the Desktop improvements project we modified the behavior here a bit: instead of the notice //replacing// the Talk page link, it was added as an additional element. See these screenshots for clarification:
| Before June 2021 | After June 2021
| {F34478663} | {F34478664}
There is nothing currently broken with this functionality, however there is probably room for improvement in regards to:
- the yellow notification is duplicative of the red dot on the bell icon
- the yellow notification is inconsistent with other notifications
- the need for the yellow notification is possibly an indication that the "standard" methods of notification are insufficient or are not working properly
=== Notes
additional context here T274428
==== Error ====
* mwversion: `1.37.0-wmf.4`
* reqId: `315b37df-ed8c-4504-a74a-f1622e74b5d8`
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2021-05-08T17:28:32.000Z',to:'2021-05-10T12:05:14.794Z'))&_a=(query:(query_string:(query:'reqId:%22315b37df-ed8c-4504-a74a-f1622e74b5d8%22'))) | Find reqId in Logstash ]]
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:now-30d,to:now))&_a=(query:(query_string:(query:'normalized_message:%22%5B%7BreqId%7D%5D%20%7Bexception_url%7D%20%20%20TypeError:%20Argument%201%20passed%20to%20EchoEvent::setTitle()%20must%20be%20an%20instance%20of%20Title,%20null%20given,%20called%20in%20/srv/mediawiki/php-1.37.0-wmf.4/extensions/Flow/includes/Notifications/UserLocator.php%20on%20line%2049%22'))) | Find normalized_message in Logstash ]]
```name=normalized_message
[{reqId}] {exception_url} TypeError: Argument 1 passed to EchoEvent::setTitle() must be an instance of Title, null given, called in /srv/mediawiki/php-1.37.0-wmf.4/extensions/Flow/includes/Notifications/UserLocator.php on line 49
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.37.0-wmf.4/extensions/Echo/includes/model/Event.php(636)
#0 /srv/mediawiki/php-1.37.0-wmf.4/extensions/Flow/includes/Notifications/UserLocator.php(49): EchoEvent->setTitle(NULL)
#1 /srv/mediawiki/php-1.37.0-wmf.4/extensions/Echo/includes/controller/NotificationController.php(449): Flow\Notifications\UserLocator::locateUsersWatchingTopic(EchoEvent)
#2 /srv/mediawiki/php-1.37.0-wmf.4/extensions/Echo/includes/controller/NotificationController.php(466): EchoNotificationController::evaluateUserCallable(EchoEvent, string)
#3 /srv/mediawiki/php-1.37.0-wmf.4/extensions/Echo/includes/controller/NotificationController.php(116): EchoNotificationController::getUsersToNotifyForEvent(EchoEvent)
#4 /srv/mediawiki/php-1.37.0-wmf.4/extensions/Echo/includes/jobs/NotificationJob.php(13): EchoNotificationController::notify(EchoEvent, boolean)
#5 /srv/mediawiki/php-1.37.0-wmf.4/extensions/EventBus/includes/JobExecutor.php(79): EchoNotificationJob->run()
#6 /srv/mediawiki/rpc/RunSingleJob.php(76): MediaWiki\Extension\EventBus\JobExecutor->execute(array)
#7 {main}
```
==== Impact ====
One or more notifications are not sent to users watching a topic.
==== Notes ====
Did a quick look at the relevant section of NotificationController.php, UserLocator.php and Event.php, doesn't seem like anything there changed recently.
It could be nice to have a way on Special:Notifications to 1) clear all alerts and/or notifications for the current wiki 2) clear all alerts and/or notifications across all wikis.
We'd need some design proposal before implementing.
---
Original report from @Harej
> As part of my work I used a script to create an account on each Wikimedia wiki. This has resulted in 477 notifications, one per wiki, in the "notices" column. Because of the sheer number of notifications, and the nature in which they are distributed across hundreds of wikis, there are simply too many to mark as read. I would like someone to do that manually, please.
---
| Impact | Users with notifications across multiple wikis don't have a nice experience when attempting to clear them or mark them as read
| What happens if we don't do this task | Users who interact with multiple wikis will continue to be frustrated when interacting with notifications
| Level of effort | Medium. Design, product, engineering
When we doing rollback, MediaWiki generates a default summary:
> Reverted edits by UserName (talk) to last version by UserName2
But in some wikis (nlwiki) summary by default is another:
> Reverted edits by UserName (talk) to last version by **[[user:UserName2|**UserName2**]]**
When we doing rollback via site, ping to user UserName2 is suppressed, but If we do it via API, user receives ping.
See discussion: [[https://nl.wikipedia.org/w/index.php?title=Help:Helpdesk&oldid=58782757#Melding_van_een_automatisch_gegenereerde_link_naar_gebruikersnaam_in_een_bewerkingssamenvatting|nlwiki]] => [[ https://meta.wikimedia.org/w/index.php?title=Talk:SWViewer&oldid=21380929#%5BOTHER%5D:_Rollback_pings|metawiki]]. I tested it in the [[https://nl.wikipedia.org/w/index.php?title=Gebruiker:IluvatarBot/Kladblok&action=history|Sandbox]]. Code of my tool is very simple:
```
$params = ['action' => 'rollback', 'title' => $page, 'user' => $user, 'token' => $token, 'utf8' => '1', 'format' => 'json'];
$client->makeOAuthCall($accessToken, $apiUrl, true, $params);
```
In PHP when wgEchoSeenTime is added to the mw.config, the seen time for notices is added under the `notice` key. When wgEchoSeenTime is updated in JavaScript, the new value is added under the `message` key.
{F34280028 size=full}
They should both use the `message` key as that's what's used by the API and what's used internally by the extension, unless T139682 is implemented, in which case everything should use `notice`.