Page MenuHomePhabricator
Search Advanced Search
    • Task
    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) ```
    • Task
    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.
    • Task
    I once checked "Set a local exception for this global preference." in my use preference's "Notify me about these events" section in Chinese Wikipedia. After I set a local exception, I modified my settings, unchecked every checkbox. I then saved my settings. Today I decided to undo my changes, so I straightforwardly unchecked "Set a local exception for this global preference." and saved my preferences. The global preference does not sync to the settings, and I even cannot set my settings via global preferences.
    • Task
    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}
    • Task
    ``` php tests/phpunit/phpunit.php tests/phpunit/includes/preferences/DefaultPreferencesFactoryTest.php Using PHP 7.4.26 PHPUnit 8.5.21 by Sebastian Bergmann and contributors. .....EE..EEI. 13 / 13 (100%) Time: 2.21 seconds, Memory: 79.00 MB There were 4 errors: 1) DefaultPreferencesFactoryTest::testShowRollbackConfIsHiddenForUsersWithoutRollbackRights Error: Call to a member function getSession() on null /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1429 /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1369 /Users/kostajh/src/mediawiki/w/extensions/Echo/includes/EchoHooks.php:309 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:338 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:137 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookRunner.php:1909 /Users/kostajh/src/mediawiki/w/includes/preferences/DefaultPreferencesFactory.php:248 /Users/kostajh/src/mediawiki/w/tests/phpunit/includes/preferences/DefaultPreferencesFactoryTest.php:211 /Users/kostajh/src/mediawiki/w/tests/phpunit/MediaWikiIntegrationTestCase.php:452 === Logs generated by test case [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [localisation] [debug] LocalisationCache using store LCStoreNull [] [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [localisation] [debug] LocalisationCache using store LCStoreNull [] [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [objectcache] [debug] MainObjectStash using store {class} {"class":"HashBagOStuff"} [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"} [Parser] [debug] Parser::setOutputFlag: set user-signature flag on 'DefaultPreferencesFactoryTest'; User signature detected [] === 2) DefaultPreferencesFactoryTest::testShowRollbackConfIsShownForUsersWithRollbackRights Error: Call to a member function getSession() on null /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1429 /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1369 /Users/kostajh/src/mediawiki/w/extensions/Echo/includes/EchoHooks.php:309 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:338 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:137 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookRunner.php:1909 /Users/kostajh/src/mediawiki/w/includes/preferences/DefaultPreferencesFactory.php:248 /Users/kostajh/src/mediawiki/w/tests/phpunit/includes/preferences/DefaultPreferencesFactoryTest.php:231 /Users/kostajh/src/mediawiki/w/tests/phpunit/MediaWikiIntegrationTestCase.php:452 === Logs generated by test case [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [localisation] [debug] LocalisationCache using store LCStoreNull [] [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [localisation] [debug] LocalisationCache using store LCStoreNull [] [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [objectcache] [debug] MainObjectStash using store {class} {"class":"HashBagOStuff"} [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"} [Parser] [debug] Parser::setOutputFlag: set user-signature flag on 'DefaultPreferencesFactoryTest'; User signature detected [] === 3) DefaultPreferencesFactoryTest::testVariantsSupport Error: Call to a member function getSession() on null /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1429 /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1369 /Users/kostajh/src/mediawiki/w/extensions/Echo/includes/EchoHooks.php:309 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:338 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:137 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookRunner.php:1909 /Users/kostajh/src/mediawiki/w/includes/preferences/DefaultPreferencesFactory.php:248 /Users/kostajh/src/mediawiki/w/tests/phpunit/includes/preferences/DefaultPreferencesFactoryTest.php:371 /Users/kostajh/src/mediawiki/w/tests/phpunit/MediaWikiIntegrationTestCase.php:452 === Logs generated by test case [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [localisation] [debug] LocalisationCache using store LCStoreNull [] [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [localisation] [debug] LocalisationCache using store LCStoreNull [] [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [objectcache] [debug] MainObjectStash using store {class} {"class":"HashBagOStuff"} [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"} [Parser] [debug] Parser::setOutputFlag: set user-signature flag on 'DefaultPreferencesFactoryTest'; User signature detected [] === 4) DefaultPreferencesFactoryTest::testUserGroupMemberships Error: Call to a member function getSession() on null /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1429 /Users/kostajh/src/mediawiki/w/includes/Permissions/PermissionManager.php:1369 /Users/kostajh/src/mediawiki/w/extensions/Echo/includes/EchoHooks.php:309 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:338 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookContainer.php:137 /Users/kostajh/src/mediawiki/w/includes/HookContainer/HookRunner.php:1909 /Users/kostajh/src/mediawiki/w/includes/preferences/DefaultPreferencesFactory.php:248 /Users/kostajh/src/mediawiki/w/tests/phpunit/includes/preferences/DefaultPreferencesFactoryTest.php:396 /Users/kostajh/src/mediawiki/w/tests/phpunit/MediaWikiIntegrationTestCase.php:452 === Logs generated by test case [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [localisation] [debug] LocalisationCache using store LCStoreNull [] [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [localisation] [debug] LocalisationCache using store LCStoreNull [] [objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"} [objectcache] [debug] MainObjectStash using store {class} {"class":"HashBagOStuff"} [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false} [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one [] [MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"} [UserOptionsManager] [debug] Loading options from database {"user_id":0} [Parser] [debug] Parser::setOutputFlag: set user-signature flag on 'DefaultPreferencesFactoryTest'; User signature detected [] [CentralAuthVerbose] [info] Loading state for global user {user} from DB {"user":"","private":false} [CentralAuthVerbose] [info] Loading attached wiki list for global user from DB {"private":false} [CentralAuthVerbose] [info] Loading groups for global user {user} {"user":"","private":false} [objectcache] [debug] fetchOrRegenerate(global:centralauth-user:d41d8cd98f00b204e9800998ecf8427e): miss, new value computed [] [CentralAuthVerbose] [info] Loading CentralAuthUser for user {user} from cache object {"user":"","private":false} === ERRORS! Tests: 13, Assertions: 28, Errors: 4, Incomplete: 1. You should really speed up these slow tests (>50ms)... 1. 200ms to run DefaultPreferencesFactoryTest:testIntvalFilter 2. 158ms to run DefaultPreferencesFactoryTest:testGetForm 3. 94ms to run DefaultPreferencesFactoryTest:testEmailAuthentication with data set #0 4. 68ms to run DefaultPreferencesFactoryTest:testEmailAuthentication with data set #2 5. 67ms to run DefaultPreferencesFactoryTest:testEmailAuthentication with data set #1 ```
    • Task
    From parent task: > Some extensions use the incremental data from LinksUpdate as input to their own data updates, specifically CirrusSearch, Disambiguator, EventBus and Echo. They could receive a narrower, read-only view into the generated data. They all use LinksUpdateComplete except for Echo, which uses LinksUpdateAfterInsert. > LinksUpdateAfterInsert is only used by the Echo extension. It needs a list of added links, but it could apparently use getAddedLinks() in LinksUpdateComplete instead, like CirrusSearch and EventBus.
    • Task
    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.
    • Task
    **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}
    • Task
    ## Review There are four LinksUpdate hooks, all of which pass a LinksUpdate object, which is a kitchen sink object with a lot of public properties and methods. I reviewed the extension handlers of these hooks. The aim is to make it easier for extensions to do common things, and to narrow the interfaces so as to make it easier to improve LinksUpdate. Some extensions are only using LinksUpdate hooks as a convenient place to do an unrelated cache purge. GlobalUserPage, PageTriage, UploadWizard (and fork MediaUploader), PhpTagsWiki, SharedHelpPages and MarkImages only need the title and possibly the current revision. They could use the RevisionDataUpdates hook instead, available since 1.35. That hook is not called on delete, so some of them would have to also hook PageDeletionDataUpdates. Some extensions are adding a link-like table, usually with their own implementation of incremental updates, specifically Babel, GeoData, GlobalUsage and PageAssessments. They all have some quirk which makes them different to core link tables, but they could probably still benefit from the link table abstraction that I'm developing. Some extensions use the incremental data from LinksUpdate as input to their own data updates, specifically CirrusSearch, Disambiguator, EventBus and Echo. They could receive a narrower, read-only view into the generated data. They all use LinksUpdateComplete except for Echo, which uses LinksUpdateAfterInsert. LinksUpdateAfterInsert is only used by the Echo extension. It needs a list of added links, but it could apparently use getAddedLinks() in LinksUpdateComplete instead, like CirrusSearch and EventBus. LinksUpdateConstructed is only used by SemanticMediaWiki. It updates secondary data based on the ParserOutput. It could use the RevisionDataUpdates hook instead, except that it uses the recursive flag, which is not passed down to the hook despite being an argument to DerivedPageDataUpdater::getSecondaryDataUpdates(). It could apparently also use LinksUpdate or LinksUpdateComplete. It is unclear to me why it is using this unusual hook. PageImages uses the LinksUpdate hook to modify the page properties before save. It loads the revision text from the database, parses the lead section, extracts extension data from the resulting ParserOutput, and then saves data derived from this operation back to $linksUpdate->mProperties as if it came from the main page parse. This seems inelegant. I think this could use a late parser hook instead, like ParserAfterTidy. It could discover the section of an image by looking for the image tags in the HTML and matching them up by name with previously stored candidates. In Parsoid this would be a DOM pass. Translate is similarly using the LinksUpdate hook for last-minute modification of the data extracted from ParserOutput. It wipes $linksUpdate->mCategories depending on the page title. I think this could also use a late parser hook. There is ParserOutput::setCategories(). ## Proposal * Deprecate LinksUpdateAfterInsert, instead use LinksUpdateComplete * Deprecate LinksUpdateConstructed, instead use LinksUpdate, LinksUpdateComplete or RevisionDataUpdates * For unrelated secondary data updates, use RevisionDataUpdates and PageDeletionDataUpdates * Migrate PageImages and Translate to use a late parser hook instead. * Make all LinksUpdate properties be private or protected. * Wrap up incremental table changes derived from LinksUpdate into a narrower object and provide it to a new hook, for CirrusSearch etc.
    • Task
    ==== What is the problem? On beta over the last few days, I am seeing lots of errors like: ``` 2021-11-30 09:10:34 [185b66024cff8dd03475bb83] deployment-mwmaint02 testwiki 1.38.0-alpha exception ERROR: [185b66024cff8dd03475bb83] [no req] MWException: File '/srv/mediawiki/php-master/extensions//static/images/wikibase/echoIcon.svg' does not exist {"exception_url":"[no req]","reqId":"185b66024cff8dd03475bb83","caught_by":"other"} [Exception MWException] (/srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderImage.php:294) File '/srv/mediawiki/php-master/extensions//static/images/wikibase/echoIcon.svg' does not exist #0 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderImage.php(264): ResourceLoaderImage->getImageData(DerivativeResourceLoaderContext, NULL, string) #1 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderImageModule.php(377): ResourceLoaderImage->getDataUri(DerivativeResourceLoaderContext, NULL, string) #2 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderImageModule.php(331): ResourceLoaderImageModule->getStyleDeclarations(DerivativeResourceLoaderContext, ResourceLoaderImage, string) #3 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderModule.php(796): ResourceLoaderImageModule->getStyles(DerivativeResourceLoaderContext) #4 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderModule.php(747): ResourceLoaderModule->buildContent(DerivativeResourceLoaderContext) #5 /srv/mediawiki/php-master/includes/resourceloader/ResourceLoader.php(1139): ResourceLoaderModule->getModuleContent(DerivativeResourceLoaderContext) #6 /srv/mediawiki/php-master/extensions/WikimediaMaintenance/blameStartupRegistry.php(137): ResourceLoader->makeModuleResponse(DerivativeResourceLoaderContext, array) #7 /srv/mediawiki/php-master/maintenance/doMaintenance.php(108): BlameStartupRegistry->execute() #8 /srv/mediawiki/php-master/extensions/WikimediaMaintenance/blameStartupRegistry.php(332): require_once(string) #9 /srv/mediawiki/multiversion/MWScript.php(116): require_once(string) #10 {main} ```
    • Task
    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
    • Task
    **List of steps to reproduce**: * (Assume there is a user named Foo) * Add `[[User:Foo]] ~~~~` in an edit, and `[[User:Foo]]` for edit summary **What happens?**: Foo will receive two notifications, one is "(Somebody) mentioned you in an edit summary on <Page>", another is "(Somebody) mentioned you on <Page>‬ in <Section>". **What should have happened instead?**: Foo should receive only one mention notification.
    • Task
    === Description As a general rule there should only be one menu open at a time. So when you open a menu, if another menu is currently open it should close. This seems to work properly for the new User menu and the new ULS, and also seems to work properly for the two echo menus (Notifications and Alerts), but it doesn't seem to be working properly for the echo menus and the User menu/ULS. {F34750505}
    • Task
    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.
    • Task
    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 ```
    • Task
    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.
    • Task
    ==== Error ==== * mwversion: `1.38.0-wmf.4` * reqId: `5c41748a-bf45-4d25-ba4c-510e7c05b10c` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2021-10-13T21:44:37.000Z',to:'2021-10-14T21:50:24.380Z'))&_a=(query:(query_string:(query:'reqId:%225c41748a-bf45-4d25-ba4c-510e7c05b10c%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%20PHP%20Notice:%20Undefined%20offset:%20577%22'))) | Find normalized_message in Logstash ]] ```name=normalized_message [{reqId}] {exception_url} PHP Notice: Undefined offset: 577 ``` ```name=exception.trace,lines=10 from /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(782) #0 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(782): MWExceptionHandler::handleError(integer, string, string, integer, array) #1 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(769): EchoDiscussionParser::getSectionStartIndex(integer, array) #2 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(621): EchoDiscussionParser::getSectionSpan(integer, array) #3 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(533): EchoDiscussionParser::interpretDiff(array, string, Title) #4 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/DiscussionParser.php(47): EchoDiscussionParser::getChangeInterpretationForRevision(MediaWiki\Revision\RevisionStoreRecord) #5 /srv/mediawiki/php-1.38.0-wmf.4/extensions/Echo/includes/EchoHooks.php(507): EchoDiscussionParser::generateEventsForRevision(MediaWiki\Revision\RevisionStoreRecord, boolean) #6 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/MWCallableUpdate.php(38): EchoHooks::{closure}() #7 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdates.php(515): MWCallableUpdate->doUpdate() #8 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdates.php(391): DeferredUpdates::attemptUpdate(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti) #9 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdates.php(221): DeferredUpdates::run(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti, Monolog\Logger, BufferingStatsdDataFactory, string) #10 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdatesScope.php(267): DeferredUpdates::{closure}(MWCallableUpdate, integer) #11 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdatesScope.php(196): DeferredUpdatesScope->processStageQueue(integer, integer, Closure) #12 /srv/mediawiki/php-1.38.0-wmf.4/includes/deferred/DeferredUpdates.php(242): DeferredUpdatesScope->processUpdates(integer, Closure) #13 /srv/mediawiki/php-1.38.0-wmf.4/includes/MediaWiki.php(1136): DeferredUpdates::doUpdates() #14 /srv/mediawiki/php-1.38.0-wmf.4/includes/MediaWiki.php(846): MediaWiki->restInPeace() #15 /srv/mediawiki/php-1.38.0-wmf.4/includes/MediaWiki.php(584): MediaWiki->doPostOutputShutdown() #16 /srv/mediawiki/php-1.38.0-wmf.4/index.php(53): MediaWiki->run() #17 /srv/mediawiki/php-1.38.0-wmf.4/index.php(46): wfIndexMain() #18 /srv/mediawiki/w/index.php(3): require(string) #19 {main} ``` ==== Notes ==== Just one today.
    • Task
    HTML entities for non-breaking spaces should not be visible in the label, see screenshot: {F34686282} This bug is similar to T142882. [[https://translatewiki.net/wiki/MediaWiki:Notification-dynamic-actions-flow-board-unwatch/fr|Link to the translated message on Translatewiki]] [[https://translatewiki.net/wiki/Thread:MediaWiki_talk:Notification-dynamic-actions-flow-board-unwatch/fr/Espaces_ins%C3%A9cables|Discussion on Translatewiki]] Relevant code in FlowPresentationModel.php: ```lang=php // notification-dynamic-actions-flow-board-unwatch // notification-dynamic-actions-flow-topic-unwatch $link['label'] = $this ->msg( 'notification-dynamic-actions-flow-' . $type . '-unwatch' ) ->params( $stringPageTitle, $title->getFullURL( $query ), $this->getUser()->getName() ) ->parse(); ```
    • Task
    **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 &lt;https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/&gt; 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
    • Task
    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
    • Task
    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}
    • Task
    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.
    • Task
    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.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Receive a notification that someone is your new mentor (I don’t know what the mentor has to do to make this happen) * Open the notification **What happens?**: The text visually cuts off in a mildly funny position: “Say hi to your new men”. (This might depend on installed fonts etc.) {F34644151} **What should have happened instead?**: The text should display completely: “Say hi to your new mentor!” (copied from dev tools) **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: 1.37.0-wmf.23 (c90ba33) on test.wikipedia.org; Mozilla Firefox Developer Edition 93.0b4 This seems to be due to the following CSS rule: ```lang=css .mw-echo-ui-notificationItemWidget-content-actions > .mw-echo-ui-notificationItemWidget-content-actions-buttons.oo-ui-buttonSelectWidget > .oo-ui-buttonOptionWidget { min-width: 7em; max-width: 14em; overflow: hidden; } ``` If I disable the `max-width` in dev tools, the full text appears.
    • Task
    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?
    • Task
    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
    • Task
    **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.)
    • Task
    **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).
    • Task
    It is annoying to see edits on the watchlist again that you've already seen because you got a notification about them (because you were mentioned, it's your own talk page, you subscribed to a topic using DiscussionTools, etc.) What if the watchlist had a filter to exclude edits that also caused a notification to be sent to you?
    • Task
    While QAing a MonoBook related change, we noticed that Echo icons appear in a strange visual position with bullet points {F34590993} I'm not sure whether this has always been broken and how this is meant to display. The bullet points can be explained and I'll post a patch.
    • Task
    ### 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.
    • Task
    The Wikipedia Library Echo notification (T132084) is ready for deployment, and will be rolled out with a gradually decreasing edit count requirement for receiving it. This is because, per T271962, approximately 40,000 editors may receive this notification in the first week if it was deployed with the target requirements and we don't want to substantially degrade tool performance. Pending any issues or bugs, we will follow this deployment plan: | **Week of...** | **Projects** | **Edit count threshold** | **Approximate number of editors receiving notification** | **Done?** | 6th November | Meta and Test only | 50,000 | Unknown (low)* | X | //Testing and holiday break// | 10th January | All | 50,000 | 5,249 | X | 18th January | All | 10,000 | 9,862 | X | 24th January | All | 2,000 | 12,259 | | 31st January | All | 500 | 11,771 | //*Subsequent analysis shows this number was approximately 500-1000.// **Extension page:** https://www.mediawiki.org/wiki/Extension:TheWikipediaLibrary [X] **Security review:** T207990 [X] **Performance review:** T275774 The notification has been deployed in its current state on Beta since May 2021.
    • Task
    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}
    • Task
    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}
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Use Firefox (haven't tested Chromium) * Make resolution mobile size give or take. * Click on the notifications icon. **What happens?**: * For small screens, the notifications dropdown is totally obscured by a white area. * For small-medium screens, the notifications dropdown is squished by a similar white area. * Minerva seems to be handling this mysterious whitespace decently, relative to the other two skins **What should have happened instead?**: * Notifications pane displays at full mobile width **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: * 1.37.0-wmf.14 (388e638) ** Has been a week or two of this issue. Images are from minimum desktop resolution. | Timeless | Vector | Minerva | {F34559265} | {F34559263} | {F34559269}
    • Task
    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}
    • Task
    The issue is reproducible in a browser emulator. It's been confirmed on real devices - iPhone 11 and Galaxy S8. 1. On mobile go to Special:Notifications page 2. Filter for **Unread** 3. Click on the cog menu - when **Unread** messages are present, the drop-down menu items are not fully displayed. When no **Unread** messages are present, the "Preferences" label is completely hidden; it won't be displayed even the landscape view. |When Unread messages are present| no Unread messages |---|--- |{F34558154}|{F34558152}
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Open Russian Wikipedia with notifications from other wikis * Open notification drawer * See button text cut off due to Echo’s CSS **What happens?**: {F34553349} Translation: //More notifications from other wiki// //English Wikipedia// //Show 1 notification// [cuts off] **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: The CSS rules that cause this: ``` .mw-echo-ui-notificationItemWidget-content-actions > .mw-echo-ui-notificationItemWidget-content-actions-buttons.oo-ui-buttonSelectWidget > .oo-ui-buttonOptionWidget { min-width: 7em; max-width: 14em; overflow: hidden; } ```
    • Task
    ```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}.
    • Task
    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)
    • Task
    === 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
    • Task
    === 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
    • Task
    There are several venues for severe harassments on Wikipedia. Harassers can write on the taget's talk page, they can send emails or they can for example ping them in comments. When someone jumps IPs after blocks, they can use this to wear down Wikipedians. In a situation where this harassment is happening, there might be a need to protect users even if it means that some can't communicate with them, without completely shutting them out of the conversations. Talk pages can be protected by semi-protecting them, meaning that new accounts or IPs the harasser has registered to switched to can't write on the talk page until protection is lifted. Emails can be restricted by temporarily unchecking "Allow emails from brand-new users", letting many Wikimedians still use them but disallowing the harasser's new accounts from doing so. But there is no similar solution for pings. In order to make it more difficult for harassers, we should have a similar solution for notifications, where one can choose not to get notifications from brand new users. This would raise the level of effort needed to use this as a tool of harassment, and make it easier for the affected users to ride out the storm.
    • Task
    ==== 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.
    • Task
    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
    • Task
    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); ```
    • Task
    Preferences link in mobile notifications is broken on phones (works on tablets). https://en.m.wikipedia.org/wiki/Special:Notifications (to find this page, click {nav icon=bell > All notifications}). | Broken: {F34409719} | Looks good at wider screen size: {F34409721} The problem is caused by this CSS rule: (but I don't know what else it does, so I'm not submitting a patch) ``` @media (max-width: 720px) .mw-echo-ui-overlay .oo-ui-clippableElement-clippable { width: 100% !important; } ``` | Broken: {F34409732} | Fixed: {F34409730}
    • Task
    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`.
    • Task
    I get a hundreds of e-mails from SchlurcherBot, even though I entered the preferences on my user page under notification as an muted user. How else can I prevent this? I would be grateful for a solution.
    • Task
    Communicating with users is critical in order for the community to provide feedback to the edits of new and more seasoned editors alike. This is how people learn, help each other, how they are warned about potential consequences (Block), stopped from making incorrect edits etc. The share of mobile users has increased significantly over the years, yet the mobile platforms have opted out of implementing the infrastructure for communicating with other users ever since these mobile interfaces were developed. When the mobile interfaces were readonly this wasn't as much of a problem but over the years more and more edit functionality has been implemented yet the communication (and thus feedback loop) has been left in the dust. This is significantly frustrating the desktop editing community and causing confusion for editors using the mobile platforms. Enwiki discussion: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#What_we've_got_here_is_failure_to_communicate_(some_mobile_editors_you_just_can't_reach) Table adapted from [[https://en.wikipedia.org/wiki/User:Suffusion_of_Yellow/Mobile_communication_bugs | User:Suffusion of Yellow/Mobile communication bugs]]: <table> <tr> <th>Editor</th> <th>Tag</th> <th>"New message" alert</th> <th>Other alerts</th> <th>Custom block messages</th> <th>Partial block shown as partial</th> <th>Editnotices [1]</th> <th>Custom edit filter messages </th> </tr> <tr> <td>Desktop (IP)</td> <td></td> <td>Orange bar of doom</td> <td>N/A</td> <td>Yes</td> <td>Yes (?)</td> <td>Yes</td> <td>Yes </td> </tr> <tr> <td>Desktop (User)</td> <td></td> <td>Miniature orange bar of doom [2] </td> <td>Yes</td> <td>Yes</td> <td>Yes</td> <td>Yes [3]</td> <td>Yes </td> </tr> <tr> <td>Mobile Web (IP)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&tagfilter=mobile+web+edit | Mobile web edit ]]</td> <td>**No** T240889</td> <td>N/A</td> <td>Yes</td> <td>Yes (?)</td> <td>**No** T201595</td> <td>Yes </td> </tr> <tr> <td>Mobile Web (User)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideanons=1&tagfilter=mobile+web+edit | Mobile web edit ]] </td> <td class="table-partial">Looks like other alerts T240976</td> <td>Yes</td> <td>Yes</td> <td>Yes</td> <td>**No** T201595</td> <td>Yes </td> </tr> <tr> <td>iOS (IP)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&tagfilter=ios+app+edit | iOS app edit ]] </td> <td>**No** (?) T274404</td> <td>N/A</td> <td>Unknown</td> <td>Unknown</td> <td>**No** T201596</td> <td>Broken [4]</td> </tr> <tr> <td>iOS (User)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&userExpLevel=registered&tagfilter=ios+app+edit | iOS app edit]]</td> <td>**No** T274404</td> <td>**No** T274404</td> <td>**No** T275118</td> <td>Unknown</td> <td>**No** T201596</td> <td>Broken [4]</td> </tr> <tr> <td>Android (IP)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&tagfilter=android+app+edit | Android app edit]]</td> <td>**No** T95396</td> <td>N/A</td> <td>Seems flaky T276149</td> <td>Unknown</td> <td>**No** T201597</td> <td>**No** (?) T276139</td> </tr> <tr> <td>Android (User)</td> <td>[[https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideanons=1&tagfilter=android+app+edit | Android app edit]] </td> <td>Yes (w/ ding+vibrate)</td> <td>Yes (w/ ding+vibrate)</td> <td>**No** T276147</td> <td>**No** T276147</td> <td>**No** T201597</td> <td>**No** T276139</td> </tr> </table> ---- [1}: See also {T201613} [2]: Shown in Vector (default), Monobook, and Modern skins. Looks like other alerts in Timeless and MinerveNeue skins. [3]: Shown in Vector (default), Monobook and Modern and Timeless skins. Not shown in MinervaNeue skin. [4]: If the message is at MediaWiki:Abusefilter-warning-foo, the user will see `<abusefilter-warning-foo>`, and not the content of that page
    • Task
    SVGO has been updated to new major version 2.x after some time without any updates. It needs to be switched to JS configuration. First exemplary configuration [[ https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/674926 | is in Vector ]]. [[https://codesearch.wmcloud.org/deployed/?q=grunt-svgmin&i=nope&files=package%5C.json&excludeFiles=&repos=|Production uses]]: [x] MediaWiki - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/692591 [x] CentralNotice - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/692455 [x] ~~Cite~~ No SVGs part of extension anymore. Instead removed grunt-svgmin package [x] Echo - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/692450 [x] GuidedTour - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GuidedTour/+/681944 [x] Kartographer - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/692446 [x] MultimediaViewer - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/678635 [x] MobileFrontend - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/678403 [x] Popups ("Page Previews") - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/681760 [x] RevisionSlider - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/RevisionSlider/+/692458 [x] TwoColConflict - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TwoColConflict/+/692580 [x] UniversalLanguageSelector - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/692584/ [x] MinervaNeue - https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/678637 [x] MonoBook - https://gerrit.wikimedia.org/r/c/mediawiki/skins/MonoBook/+/692596 [x] Timeless - https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/692595 [x] Vector – https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/674926 [] Wikimedia Design Style Guide
    • Task
    ``` Targets Occurrences of '(white|black)[ \-]?list' in Directory /Users/reedy/PhpstormProjects/mediawiki/extensions/Echo Found Occurrences (166 usages found) extensions (166 usages found) Echo (166 usages found) i18n (78 usages found) ar.json (1 usage found) 56 "echo-pref-notifications-blacklist": "لا تعرض الإخطارات من هؤلاء المستخدمين. ([[mw:Special:MyLanguage/Help:Notifications#mute|اعرف المزيد]])", ast.json (1 usage found) 31 "echo-pref-notifications-blacklist": "Nun amosar notificaciones d'estos usuarios. ([[mw:Special:MyLanguage/Help:Notifications#mute|más información]])", az.json (1 usage found) 36 "echo-pref-notifications-blacklist": "Bu istifadəçilərdən gələn bildirişləri göstərmə. ([[mw:Special:MyLanguage/Help:Notifications#mute|daha ətraflı]])", be-tarask.json (1 usage found) 31 "echo-pref-notifications-blacklist": "Не паказваць паведамленьні ад гэтых удзельнікаў. ([[mw:Special:MyLanguage/Help:Notifications#mute|даведацца болей]])", be.json (1 usage found) 30 "echo-pref-notifications-blacklist": "Не паказваць паведамленні ад гэтых удзельнікаў ([[mw:Special:MyLanguage/Help:Notifications#mute|даведацца больш]]):", bg.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Да не се показват известия от следните потребители.\n([[mw:Special:MyLanguage/Help:Notifications#mute|научете повече]])", bn.json (1 usage found) 39 "echo-pref-notifications-blacklist": "এই ব্যবহারকারীদের থেকে বিজ্ঞপ্তি প্রদর্শন করবেন না। ([[mw:Special:MyLanguage/Help:Notifications#mute|আরও জানুন]])", bs.json (1 usage found) 33 "echo-pref-notifications-blacklist": "Ne prikazuj obavještenja od ovih korisnika. ([[mw:Special:MyLanguage/Help:Notifications#mute|detaljnije]])", ce.json (1 usage found) 29 "echo-pref-notifications-blacklist": "ХӀокху декъашхошкара хаамаш ма гайта. ([[mw:Special:MyLanguage/Help:Notifications#mute|мадарра]])", ckb.json (1 usage found) 34 "echo-pref-notifications-blacklist": "ھۆشداری ئەم بەکارھێنەرانە پیشان مەدە.\n([[mw:Special:MyLanguage/Help:Notifications#mute|زیاتر بزانە]])", cs.json (1 usage found) 46 "echo-pref-notifications-blacklist": "Nezobrazovat notifikace od těchto uživatelů. ([[mw:Special:MyLanguage/Help:Notifications#mute|dozvědět se více]])", da.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Vis ikke beskeder (notifikationer) fra disse brugere. ([[mw:Special:MyLanguage/Help:Notifications#mute|læs mere]])", de.json (1 usage found) 48 "echo-pref-notifications-blacklist": "Benachrichtigungen von diesen Benutzern nicht anzeigen ([[mw:Special:MyLanguage/Help:Notifications#mute|mehr erfahren]]).", diq.json (1 usage found) 39 "echo-pref-notifications-blacklist": "Nê karberan ra a ayê pêhesnayışa memocne. ([[mw:Special:MyLanguage/Help:Notifications#mute|tayêna melumat bıgêrê ]])", el.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Να μην εμφανίζονται ειδοποιήσεις από αυτούς τους χρήστες.([[mw:Special:MyLanguage/Help:Notifications#mute|μάθετε περισσότερα]])", en.json (2 usages found) 62 "echo-pref-notifications-blacklist": "Do not display notifications from these users. ([[mw:Special:MyLanguage/Help:Notifications#mute|learn more]])", 262 "echo-blacklist": "", es.json (1 usage found) 62 "echo-pref-notifications-blacklist": "No mostrar notificaciones de estos usuarios. ([[mw:Special:MyLanguage/Help:Notifications#mute|más información]])", et.json (1 usage found) 36 "echo-pref-notifications-blacklist": "Neilt kasutajatelt teavitusi ei näidata. ([[mw:Special:MyLanguage/Help:Notifications#mute|lisateave]])", fa.json (1 usage found) 55 "echo-pref-notifications-blacklist": "عدم نمایش آگاه‌سازی برای این کاربران. [[mw:Special:MyLanguage/Help:Notifications#mute|برای اطلاعات بیشتر]]", fi.json (1 usage found) 41 "echo-pref-notifications-blacklist": "Älä näytä ilmoituksia näiltä käyttäjiltä. ([[mw:Special:MyLanguage/Help:Notifications#mute|lisätietoja]])", fit.json (1 usage found) 16 "echo-pref-notifications-blacklist": "Älä näytä ilmotuksia näiltä käyttäjiltä. ([[mw:Special:MyLanguage/Help:Notifications#mute|lisätietoja]])", fr.json (1 usage found) 74 "echo-pref-notifications-blacklist": "Ne pas afficher les notifications de ces utilisateurs. ([[mw:Special:MyLanguage/Help:Notifications#mute|en savoir plus]])", fy.json (1 usage found) 33 "echo-pref-notifications-blacklist": "Gjin meldingen sjen litte fan dizze meidoggers. ([[mw:Special:MyLanguage/Help:Notifications#mute|mear witte]])", gl.json (1 usage found) 35 "echo-pref-notifications-blacklist": "Non amosar notificacións destes usuarios.\n([[mw:Special:MyLanguage/Help:Notifications#mute|Saber máis]])", he.json (1 usage found) 43 "echo-pref-notifications-blacklist": "לא להציג התראות מהמשתמשים האלה. ([[mw:Special:MyLanguage/Help:Notifications#mute|מידע נוסף]])", hr.json (1 usage found) 37 "echo-pref-notifications-blacklist": "Ne prikazuj obavijesti ovih suradnika. ([[mw:Special:MyLanguage/Help:Notifications#mute|saznaj više]])", hu.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Értesítések megjelenítésének letiltása ezektől a felhasználóktól. ([[mw:Help:Notifications/hu#mute|további információk]])", hy.json (1 usage found) 32 "echo-pref-notifications-blacklist": "Հետևյալ մասնակիցներից ծանուցումներ ցույց չտալ․\n([[mw:Special:MyLanguage/Help:Notifications#mute|իմանալ ավելին]])", ia.json (1 usage found) 30 "echo-pref-notifications-blacklist": "Non monstrar notificationes ab iste usatores. ([[mw:Special:MyLanguage/Help:Notifications#mute|leger plus]])", id.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Jangan tampilkan pemberitahuan dari pengguna berikut. \n([[mw:Special:MyLanguage/Help:Notifications#mute|pelajari selengkapnya]])", inh.json (1 usage found) 22 "echo-pref-notifications-blacklist": "Ма гойта хоамаш укх доакъашхошкара ([[mw:Special:MyLanguage/Help:Notifications#mute|дукхагIа хá]])", io.json (1 usage found) 24 "echo-pref-notifications-blacklist": "Ne montrez avizi pri ca uzeri. ([[mw:Special:MyLanguage/Help:Notifications#mute|lernez pluse]])", it.json (1 usage found) 45 "echo-pref-notifications-blacklist": "Non mostrare notifiche di questi utenti ([[mw:Special:MyLanguage/Help:Notifications#mute|ulteriori informazioni]])", ja.json (1 usage found) 49 "echo-pref-notifications-blacklist": "以下の利用者からの通知は表示されません ([[mw:Special:MyLanguage/Help:Notifications#mute|詳細]])。", ka.json (1 usage found) 34 "echo-pref-notifications-blacklist": "არ აჩვენო ამ მომხმარებლების შეტყობინება. ([[mw:Special:MyLanguage/Help:Notifications#mute|მეტის გაგება]])", km.json (1 usage found) 27 "echo-pref-notifications-blacklist": "កុំបង្ហាញសារជូនដំណឹងពីអ្នកប្រើប្រាស់ទាំងនេះ ([[mw:Special:MyLanguage/Help:Notifications#mute|ស្វែងយល់បន្ថែម]])", ko.json (1 usage found) 47 "echo-pref-notifications-blacklist": "이 사용자의 알림을 표시하지 않습니다. ([[mw:Special:MyLanguage/Help:Notifications#mute|더 알아보기]])", lb.json (1 usage found) 32 "echo-pref-notifications-blacklist": "Notifikatioune vun dëse Benotzer net weisen.\n([[mw:Special:MyLanguage/Help:Notifications#mute|méi gewuer ginn]])", lij.json (1 usage found) 30 "echo-pref-notifications-blacklist": "No mostrâ e notiffiche de questi utenti ([[mw:Special:MyLanguage/Help:Notifications#mute|pe saveine de ciu]])", lmo.json (1 usage found) 31 "echo-pref-notifications-blacklist": "Mostra no i notifiche che chi utent chì. ([[mw:Special:MyLanguage/Help:Notifications#mute|per savenn pussee]])", lt.json (1 usage found) 34 "echo-pref-notifications-blacklist": "Nerodyti pranešimų iš šių naudotojų. ([[mw:Special:MyLanguage/Help:Notifications#mute|sužinoti daugiau]])", lv.json (1 usage found) 32 "echo-pref-notifications-blacklist": "Nerādīt paziņojumus no šiem dalībniekiem. ([[mw:Special:MyLanguage/Help:Notifications#mute|uzzināt vairāk]])", min.json (1 usage found) 25 "echo-pref-notifications-blacklist": "Jan tampak pambaritauan dari pangguno ko. ([[mw:Special:MyLanguage/Help:Notifications#mute|labiah lanjuik]])", mk.json (1 usage found) 32 "echo-pref-notifications-blacklist": "Не прикажувај известувања од овие корисници. ([[mw:Special:MyLanguage/Help:Notifications#mute|дознајте повеќе]])", ml.json (1 usage found) 32 "echo-pref-notifications-blacklist": "ഈ ഉപയോക്താക്കളിൽ നിന്നുള്ള വിജ്ഞാപനങ്ങൾ പ്രദർശിപ്പിക്കേണ്ടതില്ല. ([[mw:Special:MyLanguage/Help:Notifications#mute|കൂടുതൽ അറിയുക]])", mr.json (1 usage found) 33 "echo-pref-notifications-blacklist": "या सदस्यांनी पाठविलेल्या अधिसूचना दर्शवू नका.([[mw:Special:MyLanguage/Help:Notifications#mute|याबाबत अधिक जाणा]])", mwl.json (1 usage found) 25 "echo-pref-notifications-blacklist": "Nun amostrar notificaçones destes outelizadores. ([[mw:Special:MyLanguage/Help:Notifications#mute|coincer mais]])", my.json (1 usage found) 32 "echo-pref-notifications-blacklist": "ဤအသုံးပြုသူများထံမှ အသိပေးချက်များကို မပြပါနှင့် ([[mw:Special:MyLanguage/Help:Notifications#mute|ပိုမိုလေ့လာရန်]])", nb.json (1 usage found) 39 "echo-pref-notifications-blacklist": "Ikke vis varsler fra disse brukerne. ([[mw:Special:MyLanguage/Help:Notifications#mute|lær mer]])", ne.json (1 usage found) 39 "echo-pref-notifications-blacklist": "यी प्रयोगकर्ताहरूबाट आउने अधिसूचनाहरू नदेखाउनू।\n([[mw:Special:MyLanguage/Help:Notifications#mute|थप जान्नुहोस्]])", nl.json (1 usage found) 58 "echo-pref-notifications-blacklist": "Toon geen meldingen van deze gebruikers. ([[mw:Special:MyLanguage/Help:Notifications#mute|Meer lezen]])", nn.json (1 usage found) 28 "echo-pref-notifications-blacklist": "Ikkje vis varsel frå desse brukarane. ([[mw:Special:MyLanguage/Help:Notifications#mute|lær meir]])", pl.json (1 usage found) 52 "echo-pref-notifications-blacklist": "Nie wyświetlaj powiadomień od tych użytkowników ([[mw:Special:MyLanguage/Help:Notifications#mute|dowiedz się więcej]]).", ps.json (1 usage found) 27 "echo-pref-notifications-blacklist": "د دې کاروونکو خبرتیاوې مه ښکاره کوي. ([[mw:Special:MyLanguage/Help:Notifications#mute|lنور ولولئ]])", pt-br.json (1 usage found) 55 "echo-pref-notifications-blacklist": "Não apresentar notificações destes usuários. ([[mw:Special:MyLanguage/Help:Notifications#mute|mais informações]])", pt.json (1 usage found) 52 "echo-pref-notifications-blacklist": "Não apresentar notificações destes utilizadores. ([[mw:Special:MyLanguage/Help:Notifications#mute|mais informações]])", qqq.json (2 usages found) 65 "echo-pref-notifications-blacklist": "Label for a preference which allows a user to block notifications from certain users.\n\nNote that 265 "echo-blacklist": "{{ignored}} Site-wide list of accounts that cannot trigger notifications. Can be overridden by users at [[Special:MyPage/Echo-whitelist]].", ro.json (1 usage found) 39 "echo-pref-notifications-blacklist": "Nu arăta notificări de la acești utilizatori. ([[mw:Special:MyLanguage/Help:Notifications#mute|află mai multe]])", roa-tara.json (1 usage found) 32 "echo-pref-notifications-blacklist": "Nò ffà 'ndrucà le notifeche da ste utinde. ([[mw:Special:MyLanguage/Help:Notifications#mute|'mbare de cchiù]])", ru.json (1 usage found) 74 "echo-pref-notifications-blacklist": "Не показывать уведомления от этих участников ([[mw:Special:MyLanguage/Help:Notifications#mute|узнать больше]]):", sd.json (1 usage found) 28 "echo-pref-notifications-blacklist": "هنن واپرائيندڙ جا اطلاع نه ڏيو. ([[mw:Special:MyLanguage/Help:Notifications#mute|وڌيڪ معلومات]])", sh.json (1 usage found) 30 "echo-pref-notifications-blacklist": "Ne prikazuj obavještenja ovih korisnika. ([[mw:Special:MyLanguage/Help:Notifications#mute|saznajte više]])", sk.json (1 usage found) 37 "echo-pref-notifications-blacklist": "Nezobrazovať notifikácie od týchto používateľov. ([[mw:Special:MyLanguage/Help:Notifications#mute|podrobnosti]])", sl.json (1 usage found) 34 "echo-pref-notifications-blacklist": "Ne prikazuj obvestil naslednjih uporabnikov. ([[mw:Special:MyLanguage/Help:Notifications#mute|več]])", sr-ec.json (1 usage found) 42 "echo-pref-notifications-blacklist": "Не приказуј обавештења од следећих корисника: ([[mw:Special:MyLanguage/Help:Notifications#mute|детаљније]])", sr-el.json (1 usage found) 31 "echo-pref-notifications-blacklist": "Ne prikazuj obaveštenja od ovih korisnika. ([[mw:Special:MyLanguage/Help:Notifications#mute|saznaj više]])", sv.json (1 usage found) 50 "echo-pref-notifications-blacklist": "Visa inte aviseringar från dessa användare. ([[mw:Special:MyLanguage/Help:Notifications#mute|läs mer]])", te.json (1 usage found) 31 "echo-pref-notifications-blacklist": "కింది వాడుకరుల నుండి వచ్చే గమనింపులను చూపవద్దు.\n([[mw:Special:MyLanguage/Help:Notifications#mute|మరింత సమాచారం]])", th.json (1 usage found) 38 "echo-pref-notifications-blacklist": "ไม่ต้องแสดงการแจ้งเตือนจากผู้ใช้เหล่านี้\n([[mw:Special:MyLanguage/Help:Notifications#mute|เรียนรู้เพิ่มเติม]])", tr.json (1 usage found) 59 "echo-pref-notifications-blacklist": "Bu kullanıcılardan gelen bildirimleri gösterme. ([[mw:Special:MyLanguage/Help:Notifications#mute|daha fazla bilgi edin]])", uk.json (1 usage found) 48 "echo-pref-notifications-blacklist": "Не показувати сповіщень від цих користувачів. ([[mw:Special:MyLanguage/Help:Notifications#mute|дізнайтесь більше]])", ur.json (1 usage found) 37 "echo-pref-notifications-blacklist": "ان صارفین کے اطلاع نامے نہ دکھائیں۔ [[mw:Special:MyLanguage/Help:Notifications#mute|مزید تفصیلات]]", vec.json (1 usage found) 33 "echo-pref-notifications-blacklist": "No sta mostrare notifeghe de sti utenti ([[mw:Special:MyLanguage/Help:Notifications#mute|pì informasion]])", vi.json (1 usage found) 38 "echo-pref-notifications-blacklist": "Ẩn thông báo từ những người dùng này. ([[mw:Special:MyLanguage/Help:Notifications#mute|Tìm hiểu thêm]])", zh-hans.json (1 usage found) 79 "echo-pref-notifications-blacklist": "不显示来自这些用户的通知([[mw:Special:MyLanguage/Help:Notifications#mute|了解更多]])", zh-hant.json (1 usage found) 58 "echo-pref-notifications-blacklist": "不顯示來自這些使用者的通知([[mw:Special:MyLanguage/Help:Notifications#mute|了解更多]])", includes (75 usages found) api (1 usage found) ApiEchoMute.php (1 usage found) 13 'pref' => 'echo-notifications-blacklist', controller (63 usages found) NotificationController.php (63 usages found) 28 * Echo event agent per user blacklist 32 protected static $blacklistByUser; 42 * Echo event agent per wiki blacklist 46 protected static $wikiBlacklist; 49 * Echo event agent per user whitelist, this overwrites $blacklistByUser 53 protected static $whitelistByUser; 269 * Implements blacklist per active wiki expected to be initialized 273 * @param User $user recipient of the notification for per-user blacklists 274 * @return bool True when the event agent is blacklisted 276 public static function isBlacklistedByUser( EchoEvent $event, User $user ) { 277 global $wgEchoAgentBlacklist, $wgEchoPerUserBlacklist; 283 // Ensure we have a list of blacklists 284 if ( self::$blacklistByUser === null ) { 285 self::$blacklistByUser = new MapCacheLRU( self::$maxRecipientCacheSize ); 288 // Ensure we have a blacklist for the user 289 if ( !self::$blacklistByUser->has( (string)$user->getId() ) ) { 290 $blacklist = new EchoContainmentSet( $user ); 293 $blacklist->addArray( $wgEchoAgentBlacklist ); 295 // Add wiki-wide blacklist 296 $wikiBlacklist = self::getWikiBlacklist(); 297 if ( $wikiBlacklist !== null ) { 298 $blacklist->add( $wikiBlacklist ); 301 // Add to blacklist from user preference 302 if ( $wgEchoPerUserBlacklist ) { 303 $blacklist->addFromUserOption( 'echo-notifications-blacklist' ); 306 // Add user's blacklist to dictionary if user wasn't already there 307 self::$blacklistByUser->set( (string)$user->getId(), $blacklist ); 309 // Just get the user's blacklist if it's already there 310 $blacklist = self::$blacklistByUser->get( (string)$user->getId() ); 312 return $blacklist->contains( $event->getAgent()->getName() ) || 313 ( $wgEchoPerUserBlacklist && 319 * Check if a title is in the user's page-linked event blacklist. 344 protected static function getWikiBlacklist() { 345 global $wgEchoOnWikiBlacklist; 346 if ( !$wgEchoOnWikiBlacklist ) { 349 if ( self::$wikiBlacklist === null ) { 351 self::$wikiBlacklist = new EchoCachedList( 353 $clusterCache->makeKey( "echo_on_wiki_blacklist" ), 354 new EchoOnWikiList( NS_MEDIAWIKI, $wgEchoOnWikiBlacklist ) 358 return self::$wikiBlacklist; 362 * Implements per-user whitelist sourced from a user wiki page 364 * @param EchoEvent $event The event to test for inclusion in whitelist 365 * @param User $user The user that owns the whitelist 366 * @return bool True when the event agent is in the user whitelist 368 public static function isWhitelistedByUser( EchoEvent $event, User $user ) { 370 global $wgEchoPerUserWhitelistFormat; 372 if ( $wgEchoPerUserWhitelistFormat === null || !$event->getAgent() ) { 381 // Ensure we have a list of whitelists 382 if ( self::$whitelistByUser === null ) { 383 self::$whitelistByUser = new MapCacheLRU( self::$maxRecipientCacheSize ); 386 // Ensure we have a whitelist for the user 387 if ( !self::$whitelistByUser->has( (string)$userId ) ) { 388 $whitelist = new EchoContainmentSet( $user ); 389 self::$whitelistByUser->set( (string)$userId, $whitelist ); 390 $whitelist->addOnWiki( 392 sprintf( $wgEchoPerUserWhitelistFormat, $user->getName() ), 394 $clusterCache->makeKey( "echo_on_wiki_whitelist_" . $userId ) 397 // Just get the user's whitelist 398 $whitelist = self::$whitelistByUser->get( (string)$userId ); 400 return $whitelist->contains( $event->getAgent()->getName() ); 521 // Apply blacklists and whitelists. 525 if ( self::isBlacklistedByUser( $event, $user ) && 536 return self::isWhitelistedByUser( $event, $user ); formatters (1 usage found) PageLinkedPresentationModel.php (1 usage found) 65 if ( !MediaWikiServices::getInstance()->getMainConfig()->get( 'EchoPerUserBlacklist' ) ) { EchoContainmentSet.php (1 usage found) 6 * Utilizes EchoContainmentList interface to provide a fluent interface to whitelist/blacklist EchoHooks.php (8 usages found) 302 $wgEchoCrossWikiNotifications, $wgEchoPerUserBlacklist, 485 if ( $wgEchoPerUserBlacklist ) { 486 $preferences['echo-notifications-blacklist'] = [ 488 'label-message' => 'echo-pref-notifications-blacklist', 1639 $echoPerUserBlacklist = MediaWikiServices::getInstance()->getMainConfig()->get( 'EchoPerUserBlacklist' ); 1640 if ( $echoPerUserBlacklist ) { 1642 $list = MultiUsernameFilter::splitIds( $user->getOption( 'echo-notifications-blacklist' ) ); 1643 $fields[ 'echo-notifications-blacklist'] = [ EventLogging.php (1 usage found) 84 // whitelist valid delivery methods so it is always valid maintenance (6 usages found) updatePerUserBlacklist.php (6 usages found) 19 class EchoUpdatePerUserBlacklist extends LoggedUpdateMaintenance { 24 $this->addDescription( 'Update echo-notifications-blacklist User Preference from Usernames to Ids' ); 48 'up_property' => 'echo-notifications-blacklist' 53 $this->output( "Updating Echo Notification Blacklist...\n" ); 84 'up_property' => 'echo-notifications-blacklist', 99 $maintClass = EchoUpdatePerUserBlacklist::class; extension.json (7 usages found) 590 "EchoAgentBlacklist": { 593 "EchoOnWikiBlacklist": { 594 "value": "Echo-blacklist" 596 "EchoPerUserBlacklist": { 599 "EchoPerUserWhitelistFormat": { 600 "value": "%s/Echo-whitelist" 1139 "EchoUpdatePerUserBlacklist": "maintenance/updatePerUserBlacklist.php" ```
    • Task
    As noted in [gerrit](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/667635/1..2#message-023e285c92bcb8b78ad7904ef1f585d308b0a902), the fix for {T276114} and {T138734} involved setting icon height/width in pixels instead of em, so the icon size will not scale as the browser font-size is adjusted.
    • Task
    Echo renders OOUI icons at 30x30, which is 1.5 scale. This is usually fine as the icons are SVGs, but it email it deliberately uses rasterized versions (presumably for better email client support), which results in blurriness. The icons should be scaled to 30x30 before rasterizing. Current: {F34124349,size=full} Expected: {F34124353,size=full}
    • Task
    Due to {T275334}, the [code](https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L3084-L3091) responsible for unsetting the group `push-subscription-manager` from all wikis but metawiki no longer runs reliably. ==== Impact Limited, just visually clutters the interface.
    • Task
    This task is about creating ways for editors to write rules that determine what talk page activity they are notified about. This idea is prompted by the idea @Sdkb shared on mediawiki.org [here](https://www.mediawiki.org/w/index.php?title=Topic:W3c084ihivgkm9vt&topic_showPostId=w3c4ps7qjbtfdr4h#flow-post-w3c4ps7qjbtfdr4h): > ...sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria. For instance, at ITN nominations, some editors might want to only watchlist sections that are not recent deaths, so it'd be really powerful to be able to tell the software "watchlist new sections here if they don't contain `|recent death = yes`"
    • Task
    With the actual transition from User to UserIdentityValue, echo should support receiving any UserIdentity from user-locator callback. It can then unwrap it into User using `UserFactory::newFromUserIdentity`. It can happen at any time, but it would be beneficial to do it as late as possible.
    • Task
    Weird symbols appear while editing on a wiki, logging out on another wiki and logging back in on another wiki. It occured at hrwiki and cswiki to me. See the picture:{F34094350}
    • Task
    I logged into my account on fawiki yesterday and my last edit was 2:53 AM UTC of February 3. Since I have higher privileges in fawiki, I never use the "keep me signed in" option. I did not explicitly log out, but left my browser window unattended for approximately 22 hours. When I came back, I refresh the window (which was showing a fawiki page). The page refreshed successfully, and I noticed that I have 3 alerts and 2 notices; the yellow "new message" box also appeared. If I understand the MW session configurations at WMF correctly, my session must have expired by the time I came back. Therefore, even on the first refresh, I should not have been considered logged in, therefore, I should not have seen my notifications or the yellow talk page message. I am guessing some kind of cache was involved in this. Therefore, I refreshed the page. This time, it was shown to me in logged-out form. I believe something is wrong here. If I was still logged in (which I should not have been) then the session should have been rejuvenated upon the first refresh and I should have remained logged in for the second refresh too, no? And if I indeed was logged out, then why did the first refresh show me the notifications? Of note, when I logged in later, the notification counts were exactly what I had seen after first refresh. Could there be a cache-related security issue here? The obvious challenge with this task: it is hardly reproducible. PS: I remember this happened to me once before, several months ago. At the time, I assumed that I was confused and dismissed it. But that incident made me pay closer attention this time.
    • Task
    ```name=Error message PHP Notice: Undefined index: query ``` ```lines=12,name=Stack Trace from /srv/mediawiki/php-1.36.0-wmf.27/extensions/Echo/includes/api/ApiEchoUnreadNotificationPages.php(174) #0 /srv/mediawiki/php-1.36.0-wmf.27/extensions/Echo/includes/api/ApiEchoUnreadNotificationPages.php(174): MWExceptionHandler::handleError(integer, string, string, integer, array) #1 /srv/mediawiki/php-1.36.0-wmf.27/extensions/Echo/includes/api/ApiEchoUnreadNotificationPages.php(38): ApiEchoUnreadNotificationPages->getUnreadNotificationPagesFromForeign() #2 /srv/mediawiki/php-1.36.0-wmf.27/includes/api/ApiQuery.php(269): ApiEchoUnreadNotificationPages->execute() #3 /srv/mediawiki/php-1.36.0-wmf.27/includes/api/ApiMain.php(1612): ApiQuery->execute() #4 /srv/mediawiki/php-1.36.0-wmf.27/includes/api/ApiMain.php(592): ApiMain->executeAction() #5 /srv/mediawiki/php-1.36.0-wmf.27/includes/api/ApiMain.php(563): ApiMain->executeActionWithErrorHandling() #6 /srv/mediawiki/php-1.36.0-wmf.27/api.php(90): ApiMain->execute() #7 /srv/mediawiki/php-1.36.0-wmf.27/api.php(45): wfApiMain() #8 /srv/mediawiki/w/api.php(3): require(string) #9 {main} ``` ##### Notes These started happening on Jan 20, 2021. About 25 per day.
    • Task
    Mentoring started on wikis we work with because some people added their names to the list of mentors when we publicized the deployment of the features. However, we can't be sure that this group of users will auto-renew. What we are sure of is that a few users already removed their names from the list, because they discover that they dont have time or patience for being mentors. The software should invite experienced enough users to become mentors. Being a mentor requires two skills: * being able to have empathy towards newcomers * have a good enough experience of the wikis to help newcomers (or find someone who could help). The notification could be triggered when a user raches some conditions, such as: * a certain number of edits in the mainspace (to characterize activity) * a certain volume of edits in the mainspace (to characterize constructive edits and avoid people who think quantity is a better measure than quality) * a certain number of edits in discussion and communities namespaces (to show interaction) * a certain number of positive diffs (showing constructive edits) * a clean block log * ...? These conditions should be defined with inputs from various community members, to find the average values. Of course, this is not a replacement for local outreach performed by communities.
    • Task
    https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/74703/console ``` 22:14:25 [0-0] Error in "Echo flyout for notices appears when clicked @daily" 22:14:25 element (".oo-ui-labelElement-label*=Notices") still not displayed after 10000ms ``` ``` 22:14:47 [Chrome 73.0.3683.75 linux #0-0] Spec: /workspace/src/extensions/Echo/tests/selenium/specs/echo.js 22:14:47 [Chrome 73.0.3683.75 linux #0-0] Running: Chrome (v73.0.3683.75) on linux 22:14:47 [Chrome 73.0.3683.75 linux #0-0] Session ID: 5abe34c2-b878-40d0-867a-05cc1893c9ce 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 22:14:47 [Chrome 73.0.3683.75 linux #0-0] Echo 22:14:47 [Chrome 73.0.3683.75 linux #0-0] ✓ alerts and notices are visible after logging in @daily 22:14:47 [Chrome 73.0.3683.75 linux #0-0] ✓ flyout for alert appears when clicked @daily 22:14:47 [Chrome 73.0.3683.75 linux #0-0] ✖ flyout for notices appears when clicked @daily 22:14:47 [Chrome 73.0.3683.75 linux #0-0] ✓ checks for welcome message after signup 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 3 passing (29.8s) 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 1 failing 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 22:14:47 [Chrome 73.0.3683.75 linux #0-0] 1) Echo flyout for notices appears when clicked @daily 22:14:47 [Chrome 73.0.3683.75 linux #0-0] element (".oo-ui-labelElement-label*=Notices") still not displayed after 10000ms 22:14:47 [Chrome 73.0.3683.75 linux #0-0] Error: element (".oo-ui-labelElement-label*=Notices") still not displayed after 10000ms 22:14:47 [Chrome 73.0.3683.75 linux #0-0] at Context.<anonymous> (/workspace/src/extensions/Echo/tests/selenium/specs/echo.js:39:26) ``` Investigated in T271281#6884406 - Issue: The button gets clicked on before the JS has run on the button (that would trigger the fly out thing) - Actionable: Make the test (and others like it) wait for the JS to actually run on the button - Followups : {T276503}
    • Task
    When I test in my browser's console with any Wikipedia, `(new mw.echo.api.EchoApi()).markAllRead( 'local', 'all' );` has no effect, but only `markAllRead( 'local', [ 'message', 'alert' ] );` works. It is not the spec, I guess.
    • Task
    First, I am not technically sophisticated, so apologies for my likely lack of typical detail on what code's involved, etc. The origin of this report is [[https://en.wikipedia.org/wiki/Wikipedia:Help_desk/Archives/2020_December_18#Muting_thanks.|en:Wikipedia:Help desk#Muting thanks.]] Currently the language at [[https://en.wikipedia.org/wiki/Help:Notifications#Muting_users|en:Help:Notifications#Muting users]] / [[https://www.mediawiki.org/wiki/Help:Notifications#Muting_users|mw:Help:Notifications#Muting users]] identically provide: > You will still receive notifications if a muted user writes or participates on your user talk page... This exception appears to refer to ''edits'' to a user talk page. Certainly, it does not plainly indicate that even a system thanks will not be muted. Nevertheless, upon testing (in light of the linked help desk query), the notification for a system thanks from a muted user, for any edit //the thanked user has made to their own talk page//, is not suppressed. If this cannot be fixed/is not worth fixing, and this language was intended to capture even such system thanks, then there's no issue here. (I will go ahead and clarify the language at both help pages.) If, on the other hand, this is a bug, or can be fixed--well ... here's the report.
    • Task
    1. User B watches a talk page of which the title contains an ampersand. For example "Talk:Mission & Values", or this sandbox test case on [mediawiki.org/wiki/Talk:Structured Discussions/Sandbox & Box of sand](https://www.mediawiki.org/wiki/Talk:Structured_Discussions/Sandbox_%26_Box_of_sand). Simply view the board and ensure the Watchstar is on. 2. User A creates a new topic on this board. E.g. new topic "Foo" 3. Another topic is created, e.g. "Bar" either by a third user or the same user A, doesn't matter. Observe User B browsing the wiki, any page is fine except the talk page in question, and it has a new notification, which when viewed is as follows. ### Actual result It says `Stop watching new activity on "Sandbox &amp; Box of sand"` {F33946030 height=300} ### Expected result It should say `Sandbox & Box of sand` instead of `Sandbox &amp; Box of sand`. ### Other Info I initially did not know how to reproduce it after seeing it once. I have confirmed that the notication for a reply to a watched topic is fine, and that the first notification for a single new topic on a watched talk page is also fine. It is only after the first one that the issue appears.
    • Task
    Add the subject namespace to some messages to avoid confusion about the related page. Test case: # Active "Successful mention" for Web in https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Einstellungen#mw-prefsection-echo # Write a comment on the talk page of a page in the** Portal namespace**, i.e. https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Portal_Diskussion:Frankreich&action=edit&redlink=1. ## Ping** at least** 2 users Success message as notification for me as sender: {F33917680} **Missing: **The name of the namespace, here "Portal", in the message. This leads fo´to confusion by the sender. Reported on the [[ https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=205628118#Benachrichtigungen | German Wikipedia ]] by User:Snookerado Should read as ".... on the **Portal **Frankreich talk page As far as I can see the following messages are related: * MediaWiki:Notification-header-mention-success-bundle * MediaWiki:Notification-header-mention-status-bundle * MediaWiki:Notification-header-mention-failure-bundle * MediaWiki:Notification-header-mention-article-talkpage-nosection * MediaWiki:Notification-header-mention-article-talkpage
    • Task
    This is a proposed improvement for screen reader users (vision impairment) primarily. The Echo icons' text is not informative: only says "Alert (0)" / "Alert (1)" / "Alerts (2)" / etc. or "Notifications ($1)", etc. Not an issue for a regular, but for newcomer it's unclear how this element behaves. I think the following messages would be more helpful due to being more descriptive: [[ https://github.com/DemianX0/mediawiki-extensions-Echo/commit/e2ac07e6a8451a0dfc2880a04001351113941a96#diff-1a490f08504158838befaa816ee8d5c08dff9e694d5a568ce4b0a4398dcc563eR237-R238 | PATCH ]] ``` "tooltip-pt-notifications-alert": "Alerts. Opens popup listing {{GENDER:|your}} alerts.", "tooltip-pt-notifications-notice": "Notices. Opens popup listing {{GENDER:|your}} notices.", "echo-notification-alert": "Alerts. $1 unread. Opens popup listing {{GENDER:$1|your}} alerts."`, "echo-notification-notice": Notices. $1 unread. Opens popup listing {{GENDER:$1|your}} notices."`, ``` `tooltip-pt-notifications-*` messages are used server-side (for initial HTML), where the notification count is not available, thus the message does not include a count. The client-side JS updates the message with the count using `echo-notification-*` message. This latter message key could be made consistent with the other one (eg. `tooltip-pt-notifications-notice-counter`. If needed the count could be included server-side, however I haven't investigated the costs. This would benefit non-JS users (only). As an added benefit I propose moving the message from the text node - which involves a tricky and problematic solution to hide it, that the web team is [[ https://phabricator.wikimedia.org/T264339#6588587 | struggling with ]] - into the tooltip (`title` attribute). This solves the hiding issue and also benefit non-screen-reader-users. [[https://github.com/DemianX0/mediawiki-extensions-Echo/commit/e2ac07e6a8451a0dfc2880a04001351113941a96#diff-629535f46e04681786670409e97aed8023610755d5e4d175c3d356dcb210fba5R72|PATCH ]] Steps to test this UX: # Run JAWS / NVDA / VoiceOver screen reader # Open demo: http://demian-demo.epizy.com/wiki/Desktop_Improvements_volunteer_demo # Close sidebar # Click in the header # Press TAB until one of the Echo icons is focused # Listen to the reader # Press TAB / SHIFT-TAB to focus the other icon # Listen to the reader
    • Task
    **Steps:** * Be logged in on mediawiki.org (or any wiki where you have `unseen` notifications) - click on Notice (or Alert) badge with `unseen` notification so they become `unread` * Go to a wiki on which you are not logged in, e.g. ja.wikibooks.org * Explicitly log in (no idea why SUL isn't working as expected, probably some cross-domain cookie fun). **Outcome:** See a red "6" in the top bar for messages which are not new at all (but which I have kept as unread on other wikis). **Expected:** A grey "6" as on other wikis where I am logged in for items which I have kept as unread on other wikis. Firefox 80.0.1. {F32351565} Note: - also works with SUL - after being logged into a different wiki and seeing notifications as `unseen` again, go back to the tab/window where your initial login has happened - reload a page, the `unread` (grey) notification counters become `unseen` (red/blue) again.
    • Task
    Steps to Reproduce: 1. Install the echo extension with the following theme: https://invent.kde.org/websites/aether-mediawiki (production: community.kde.org) 2. Click on the notification clock. Actual Results: The notification clock has `class="d-flex align-items-center position-static"` before clicking on it and after clicking on it: `class="oo-ui-widget oo-ui-widget-enabled mw-echo-ui-notificationBadgeButtonPopupWidget mw-echo-ui-notificationBadgeButtonPopupWidget-alert"`. Expected Results: Clicking on the clock don't remove unrelated classes. I guess using the classlist js api should works fines (https://developer.mozilla.org/en-US/docs/Web/API/Element/classList).
    • Task
    Several time our users reported that they didnt get ping notification via Template:Ping or Template:User link, see [1] and [2]. Are there internal problems with this feature, ot it just happen? Could someone please check it? Best regards. [1] https://vi.wikipedia.org/wiki/Wikipedia:Th%E1%BA%A3o_lu%E1%BA%ADn#L%E1%BB%97i_ch%E1%BB%A9c_n%C4%83ng_th%C3%B4ng_b%C3%A1o [2] https://vi.wikipedia.org/wiki/Wikipedia:Th%E1%BA%A3o_lu%E1%BA%ADn#L%E1%BB%97i_ch%E1%BB%A9c_n%C4%83ng_th%C3%B4ng_b%C3%A1o
    • Task
    Presumably, when a user is notified that a page they created has been reviewed, a link contained in the notification body (e.g., “view page” in the email body, or the bounding box of the notice item in the “your notices” onsite UI element) should lead the user to the page that has been reviewed. However, if the page in question is a redirect, the user, upon following the link, ends up on the redirect-//target// page instead of the redirect page. Steps to Reproduce (though this has not been verified): - Create a new redirect page. - It may be necessary to add the new page to the watchlist. - Have another user review that redirect page. (cf. https://en.wikipedia.org/w/index.php?title=Special:Log&page=Traditionserlass) - Follow the link in the message/notice “The page //pagename//‬ has been reviewed.” Actual Results: - The link will lead to the target of the redirect page. Expected Results: - The link should contain query parameters to suppress the redirection, e.g., `redirect=no`.
    • Task
    1. On a betalabs log in and enable Homepage with the option "Default to newcomer homepage from username link in personal tools" (Special:Preferences in User profile tab in Newcomer homepage section). 2. Hover over Echo notification badges - and see that areas to click for Notices and Alerts overlapping and the Alert click area overlaps the user name clickable area. {F32194059} (click on the animated gif) {F32194061}
    • Task
    It looks like `Notification-link-text-expand-alert-count` gets cut off (see image). I haven't noticed this before so I guess it is quite new. In Swedish I now get to see "Visa 2 systemmeddeland" when I [[ https://translatewiki.net/wiki/MediaWiki:Notification-link-text-expand-alert-count/sv | expect ]] to see "Visa 2 systemmeddelanden". {F32191417}
    • Task
    Part of incident prevention and follow-up from T257079: > From [Unused wmf-config settigns](https://wikitech.wikimedia.org/w/index.php?title=Technical_debt/Unused_config&oldid=1875513): > * `wgNotificationReplyName` > * `wgNotificationSender` > * `wgNotificationSender` These are currently assigned in production, but as of some months/years ago are no longer recognised by Echo. This means either their purpose is no longer working correctly (ignored, out of date), or they have been unintentionally migrated/usurped and the prod settings are simply left-overs. Current values: ```name=wmf-config/CommonSettings.php,lang=php 3048 $wgNotificationSender = $wmgNotificationSender; 3049 $wgNotificationSenderName = $wgSitename; 3050 $wgNotificationReplyName = 'No Reply'; ``` Original code relating to it from Echo: [Echo@REL1_30](https://github.com/wikimedia/mediawiki-extensions-Echo/blob/REL1_30/extension.json#L462-L467).
    • Task
    https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&oldid=prev&diff=970984949 I got two echo notifications for this: >Narky Blert‬ mentioned you on ‪Wikipedia:Administrators' noticeboard/Incidents‬ in "‪Aspersions at ARS‬". > Alexis Jazz: Thanks. Your #1 is my standard trick; it's especially good if you have a headline. I'll have a look at the others. > Narky Blert‬ mentioned you on ‪Wikipedia:Administrators' noticeboard/Incidents‬ in "‪Aspersions at ARS‬". > Thanks, Alexis Jazz, and I will take a look. However, my point still stands: the arrogance of assuming everyone has access to everything is bloody... The "view changes" link for both points to https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&oldid=prev&diff=970984949. This appears to have happened because Narky Blert added a curly bracket that Sitush forgot when attempting to ping me.
    • Task
    In support of {T191231}, and to action {T244898}, Echo should be migrated to Abstract Schema
    • Task
    AFAICT it is only used in Echo to show a "thanks" {F31952981,size=full} A different local icon (top right) is used to show links to user talk pages
    • Task
    Echo/Notifications can just use skinStyles, instead of Minerva having to know about an extension.
    • Task
    * Steps to reproduce: ** Log in to an account with the following boxes for notifications in [[Special:Preferences#mw-prefsection-echo]]'s "Notify me about these events" checked: *** "Failed mention" *** "Successful mention" ** Mention a user with the boxes for "Mention" in [[Special:Preferences#mw-prefsection-echo]]'s "Notify me about these events" unchecked. * Expected results: ** No mention is sent. ** The sending user gets a notification of a failed mention (perhaps with text like "Your mention of [User] was not sent because they have mention notifications disabled.") * Actual results: ** No mention is sent. ** The sending user gets a notification of a //successful// mention (actual text: "Your mention of [User] was sent."), even though no notification was received.
    • Task
    =Steps to reproduce= # Start screen reader software and navigate with the keyboard (not with the mouse). # Log into a Wikimedia project such as Wikipedia or Wiktionary. # Navigate to the "Alerts" or "Notices" links that appear after the link to your user page. # Activate either of these links. # Find and read the information about your alerts and notices. =What happens= The information includes abbreviations for time units. The page does not define these abbreviations. I did not expect to find abbreviations, especially abbreviations without definitions. The meaning of these abbreviations was not obvious to me. I took several days to work out what the abbreviations meant (after watching them change). =Expected behavior= I expected information to be clear. I expected more help for new users. I expected features for advanced users (like abbreviations) to be off by default. =Suggestions= # Do not use abbreviations by default. # Explain the abbreviations. # Do not use the abbreviations for screen reader users by default. (The abbreviations do not save screen space for screen reader users using speech output). =Third-party software= I tried this with the Mozilla Firefox web browser and the Orca screen reader.
    • Task
    =Steps to reproduce= # Start screen reader software and navigate with the keyboard (not with the mouse). # Log into a Wikimedia project such as Wikipedia or Wiktionary. # Navigate to the "Alerts" or "Notices" links that appear after the link to your user page. # Activate either of these links. =What happens= New content (details of your alerts or notices) appears at the end of the page. Nothing happens to tell a blind screen reader user that this has happened. The focus remains on the link, nowhere near the new content, just as if nothing had happened. =Expected behavior= I expected to reach a page containing details of my alerts or notices. =Further information= Screen reader users expect links to navigate to a new page. These links do not navigate to a new page. These links add content to the page. Buttons perform an action. Buttons seem more appropriate than links to add content to a page. =Suggestions= # Make the links go to special pages containing information about the alerts or notices (or let users choose this behavior in their user preferences). # If continuing to add information to the page, change the links to buttons and move the focus to the top of the new content. =Third-party software= I tried this with the Mozilla Firefox web browser and the Orca screen reader.
    • Task
    Hi! Shouldn't a notification be sent/received only if text is/has been added in the scope of a section or a subsection? [[ https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Pautard&oldid=prev&diff=172735137 | This edit/action ]] is a massive clean up of a user discussion page only consisting in deletion of sections (which are not successive). Nevertheless, it led to all* contributors mentioned (with an internal link) on that page being recipient of as many notifications as the total number of those internal links (still ?) existing in the page, and potentially for very old messages. Not very problematic but useless or disturbing. Note*: assumption confirmed by the page activity after the edition. Bug about Echo but doesn't look like a duplicate of T202467. Regards.
    • Task
    On the talk page: ``` ==real header== text * text <syntaxhighlight> ==example header== </syntaxhighlight> --~~~~ ** @[[user:ExampleUser]] ping ExampleUser --~~~~ ``` expected: you were mentioned on page 1 in section "real header" in the notification shows: you were mentioned on page 1 in section "example header"
    • Task
    ====== Motivation Visual: notification icons are the odd one in the header with most skins. Bit misaligned or over-sized, different focus outline (and slightly transparent). Technical: changing alignment (margin, padding, font-size) of menu items in the header is very likely to change positioning of the notification icons in significantly different ways than menu items. The icons should behave consistently with menu items. ====== Requirements [] Notification button sizes are proportional to the header and menu items (Modern, MonoBook). [] Button sizes are responsive to font-size changes (all skins). [] Buttons' focus outline can be restored to browser default, consistent with any other link's behavior (all skins). ====== Related This work started in the Vector skin: {T256893} Modern skin: {T246931}
    • Task
    Spotted these while looking at https://en.wikipedia.org/wiki/Help:Notifications `MediaWiki:Echo-blacklist` is a sitewide list of accounts that shouldn't trigger notifications (e.g. auto signing bots) `Special:MyPage/Echo-whitelist` is where individual users can choose to override that.
    • Task
    //**Note:**////This task is a follow-up for the comment //- https://phabricator.wikimedia.org/T254197#6186533 >>! In T254197#6186533, @RHo wrote: [...] it would be nice to show the muted unbell icon in place of the unread/read toggle icon so that users can see that the notification has been muted without having to open the menu. This is my proposed update: > | Muted notification {F31851512} | Nested muted notification {F31851516}
    • Task
    This is occurring for the Mute/Unmute action (forthcoming on T254197) on the page-linked notification type. ==== Steps to Reproduce **Scenario A. Notifications panel ** # Open the Notices panel and select the "..." option on a page-linked notification # Select the option to mute the notification. # Close the confirmation pop-up and click to see the notifications panel again. **Scenario B. Special:Notifications page ** # Open the Special:Notifications page and select the "..." option on a page-linked notification # Select the option to mute the notification. ==== Actual Results: **Scenario A. Notifications panel ** The page-link notification item does not show "..." menu button at first, it only re-appears after the notifications panel finishes reloading. {F31851475} //open full-screen to see animated gif // **Scenario B. Special:Notifications page ** The page-link notification item does not show "..." menu button at all, it only re-appears after the page is refreshed. {F31851477} //open full-screen to see animated gif // === Expected Results: **Scenario A. Notifications panel ** The page-link notifications should continue to show the "..." menu button, which when selected shows the option to unmute the notification **Scenario B. Special:Notifications page ** The page-link notifications should continue to show the "..." menu button, which when selected shows the option to unmute the notification
    • Task
    I received the following notification today: {F31851103} The notification says that a link was made from [[ https://en.wikipedia.org/wiki/Trams_in_Sintra | Trams in Sintra ]] to [[ https://en.wikipedia.org/wiki/Minho | Minho ]] with [[ https://en.wikipedia.org/w/index.php?title=Trams_in_Sintra&diff=960323114&oldid=prev | this revision ]]. However, the revision linked to only changes a period to a comma in regular text. Looking through the history of the article and its transcluded templates, I see that a link to Minho was added to [[ https://en.wikipedia.org/wiki/Template:Railway_lines_in_Portugal | Template:Railway lines in Portugal ]] [[ https://en.wikipedia.org/w/index.php?title=Template%3ARailway_lines_in_Portugal&type=revision&diff=959634423&oldid=881333950 | on May 29 ]] (4 days ago), and the edit today to Trams in Sintra was first time that article had been edited since then. While the edit may have rebuilt the cache for the page and thus (from the software's point of view) been associated with the addition of the link, it's very confusing from the user's point of view to be shown a diff that has nothing to do with the link. This also makes me suspect that page muting will not work in this situation, which I'll check in a minute. This is basically a dupe of T144785, but since that bug is less specific and was closed, I decided to start a fresh bug.
    • Task
    I usually ask to add GENDER support to messages, but in the case of Notification-dynamic-actions-mute-page-linked and Notification-dynamic-actions-unmute-page-linked I think that it perhaps should be removed. The action is an imperative or bare infinitive verb for an action that is requested by the human and performed by the software. We don't have gender for Edit, Move, Delete, and many other such buttons, and I don't think that we should have it for Mute. However, if anyone thinks that these are substantially different and should have gender, feel free to decline.
    • Task
    ``` lang=php 'timestamp' => [ // ISO 8601 is __//supposed//__ to be the *only* format used for // date output, but back-compat... 'utciso8601' => $utcTimestampIso8601, // UTC timestamp in UNIX format used for loading more notification 'utcunix' => $utcTimestampUnix, 'unix' => self::getUserLocalTime( $user, $timestamp, TS_UNIX ), 'utcmw' => $utcTimestampMW, 'mw' => $timestampMw, 'date' => $date ], ```
    • Task
    Steps to Reproduce: - Navigate till "your notices" or "your notifications" control - Open screen reader - Navigate using tab Actual Results: - Screen reader announces unnecessary table markup - users might get confused by unnecessary markup being announced Expected Results: - Screen reader should not announce unnecessary table markup
    • Task
    When you get some notification, open it via phone and zoom out page. In screenshot down, you can see that notifications and options goes out of page... {F31833119} I believe that this shouldn't happen.
    • Task
    {F31807051} Note the horizontal scrolling on https://en.m.wikipedia.org/w/index.php?title=Special:Notifications&returnto=Main+Page
    • Task
    Note: the issue seems to be specific ** only** to Mac OS X Yosemite, not to a browser. I also checked the Windows 10 and 8) Mac OS X Catalina and a LInux installation. On the following wikis [[ https://zh.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5 | zh.wikipedia.org ]] [[ https://zh-min-nan.wikipedia.org/wiki/Th%C3%A2u-ia%CC%8Dh | zh-min-nan.wikipedia.org]] [[ https://zh-yue.wikipedia.org/wiki/%E9%A0%AD%E7%89%88 | zh-min-nan.wikipedia.org ]] [[ https://wuu.wikipedia.org/wiki/%E5%B0%81%E9%9D%A2 | wuu.wikipedia.org]] Echo notification badge icons are displayed cut off: {F31802514} {F31802517} {F31802519}
    • Task
    From volunteer andrybak on [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Notification_icons_blurry_rendering | Wikipedia:VillagePump ]]: > I don't know how the community feels about pixel peeping in UI elements, but here's a very minor nitpick about rendering of some of the notification icons (Commons category). They are originally 20x20 pixels SVG files. In the notifications UI they are rendered in size 30x30 pixels. Positions of some vertical and horizontal edges in these icons relate to the size 30x30 in such a way, that some edges are blurred. The size 30x30 pixels is set through the following CSS rule, which is independent of the skin (Cologne Blue · MinervaNeue (mobile) · Modern · MonoBook · Timeless · Vector): {F31791237 width=100%}
    • Task
    In production, `$wgEchoPerUserBlacklist` is set to true for all wikis, and `$wgEchoAgentBlacklist` appears to be unused. I don't know if we need to go through a deprecation process for this.
    • Task
    I just did a mass-rollback on jawikiquote that resulted in 3 edits, my first three to the site; I got a "You just made your first edit; thank you, and welcome!" for both my edits to https://ja.wikiquote.org/w/index.php?title=Wikiquote:%E3%82%B5%E3%83%B3%E3%83%89%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9&oldid=32884 and https://ja.wikiquote.org/w/index.php?title=Wikiquote:FAQ&oldid=32883 (the diffs are huge, chrome couldn't open them for me, so linked to the permalink). My feed at https://ja.wikiquote.org/wiki/Special:Notifications shown two notifications for my first edit
    • Task
    {F31760006} No matter how often I mark my notifications as read, I have a batch of 100+ notifications from English Wikinews: {F31760009} Is there a problem because the number of notifications is so large?