Page MenuHomePhabricator
Search Advanced Search
    • Task
    ==== Error ==== * mwversion: `1.38.0-wmf.18` * reqId: `da5fa467-0d6d-471f-9af5-51af6a4096be` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-01-19T22:34:36.000Z',to:'2022-01-20T21:59:58.772Z'))&_a=(query:(query_string:(query:'reqId:%22da5fa467-0d6d-471f-9af5-51af6a4096be%22'))) | Find reqId in Logstash ]] ```name=normalized_message [{reqId}] {exception_url} Exception: Flagged revision with ID 219379998 exists with unexpected fr_page_id ``` ```name=exception.trace,lines=10 from /srv/mediawiki/php-1.38.0-wmf.18/extensions/FlaggedRevs/business/RevisionReviewForm.php(534) #0 /srv/mediawiki/php-1.38.0-wmf.18/extensions/FlaggedRevs/business/RevisionReviewForm.php(331): RevisionReviewForm->approveRevision(MediaWiki\Revision\RevisionStoreRecord, NULL) #1 /srv/mediawiki/php-1.38.0-wmf.18/extensions/FlaggedRevs/business/FRGenericSubmitForm.php(195): RevisionReviewForm->doSubmit() #2 /srv/mediawiki/php-1.38.0-wmf.18/extensions/FlaggedRevs/frontend/specialpages/actions/RevisionReview.php(312): FRGenericSubmitForm->submit() #3 /srv/mediawiki/php-1.38.0-wmf.18/extensions/FlaggedRevs/rest/ReviewHandler.php(25): RevisionReview::doReview(array) #4 /srv/mediawiki/php-1.38.0-wmf.18/includes/Rest/SimpleHandler.php(38): MediaWiki\Extension\FlaggedRevs\Rest\ReviewHandler->run(string) #5 /srv/mediawiki/php-1.38.0-wmf.18/includes/Rest/Router.php(414): MediaWiki\Rest\SimpleHandler->execute() #6 /srv/mediawiki/php-1.38.0-wmf.18/includes/Rest/Router.php(338): MediaWiki\Rest\Router->executeHandler(MediaWiki\Extension\FlaggedRevs\Rest\ReviewHandler) #7 /srv/mediawiki/php-1.38.0-wmf.18/includes/Rest/EntryPoint.php(167): MediaWiki\Rest\Router->execute(MediaWiki\Rest\RequestFromGlobals) #8 /srv/mediawiki/php-1.38.0-wmf.18/includes/Rest/EntryPoint.php(132): MediaWiki\Rest\EntryPoint->execute() #9 /srv/mediawiki/php-1.38.0-wmf.18/rest.php(31): MediaWiki\Rest\EntryPoint::main() #10 /srv/mediawiki/w/rest.php(3): require(string) #11 {main} ``` ==== Impact ==== ==== Notes ====
    • Task
    # **ALTERs to run:** https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/743403/2/backend/schema/mysql/patch-flaggedtemplates-fr_title.sql # **Where to run those changes:** flaggedrevs.dblist[1] # **When to run those changes:** Any time. # **If the schema change is backwards compatible:** No # **If the schema change has been tested already on some of the test/beta wikis:** Yes. Beta cluster. had some learnings[2] # **If the data should be made available on the cloud services replicas and/or dumps:** It's public but the maintain-views has name of this field mentioned, probably we should remove that. [1] The table exists only in fifty wikis and out of those it's mostly empty in lots of them but it's massive (~100GB) in several including arwiki, dewiki, huwiki, plwiki, ruwiki. [2]The table might include data that cause alter to fail, we need to delete any rows that ft_tmp_rev_id is either 0 or NULL [] s1 (enwiki) [] s2 (eowiki fiwiki idwiki plwiki trwiki) [] s3 (alswiki bawiki bewiki bnwiki bswiki cawikinews cewiki ckbwiki de_labswikimedia dewikiquote dewiktionary elwikinews en_labswikimedia enwikibooks enwikinews eswikinews fawikinews flaggedrevs_labswikimedia frwikinews hewikisource hiwiki iawiki iswiktionary kawiki lawikisource mkwiki ptwikibooks ptwikinews ptwikisource plwikisource plwiktionary ruwikinews ruwikiquote ruwikisource ruwiktionary siwiki sqwiki tawikinews test2wiki trwikiquote ukwiktionary vecwiki zh_classicalwiki) [] s5 (dewiki) [] s6 (frwiki ruwiki) [] s7 (arwiki fawiki huwiki ukwiki)
    • Task
    {T289249} is done now but still flaggedtemplates table in arwiki (for example) is bigger than revision table of enwiki or wikidatawiki. Two (mutually inclusive) actions that can be taken: - The current pruning script, deletes data on revisions that have 50 newer revision in a page (and are older than an hour). That is not the case for most revisions because they are spread among a lot of pages. - Make the script reduce that number to five revisions (instead of 50) for revisions older than a year. - Drop `ft_namespace` and `ft_title` columns. - the table mirrors templatelinks table (by picking up its worst parts), for templatelinks it makes sense to keep title instead of page_id or rev_id but for flaggedtemplates, we are keeping track of stable revisions of transcluded templates. That concept is useless here as a non-existent template doesn't have a stable version.
    • Task
    After upgrading MediaWiki to 1.37 and to FlaggedRevs – (4dec80b) 14:21, 10 October 2021, I get the following error on the wiki, making it unusable: ``` Fatal error: Uncaught Error: Undefined constant "APCOND_FR_EDITSUMMARYCOUNT" in /var/www/vhosts/example.com/httpdocs/extensions/FlaggedRevs/FlaggedRevsSetup.php:55 Stack trace: #0 /var/www/vhosts/example.com/httpdocs/extensions/FlaggedRevs/FlaggedRevsSetup.php(31): FlaggedRevsSetup->setAutopromoteConfig() #1 /var/www/vhosts/example.com/httpdocs/extensions/FlaggedRevs/backend/FlaggedRevsHooks.php(68): FlaggedRevsSetup->doSetup() #2 /var/www/vhosts/example.com/httpdocs/includes/HookContainer/HookContainer.php(338): FlaggedRevsHooks::onMediaWikiServices() #3 /var/www/vhosts/example.com/httpdocs/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook() #4 /var/www/vhosts/example.com/httpdocs/includes/HookContainer/HookRunner.php(2517): MediaWiki\HookContainer\HookContainer->run() #5 /var/www/vhosts/example.com/httpdocs/includes/MediaWikiServices.php(268): MediaWiki\HookContainer\HookRunner->onMediaWikiServices() #6 /var/www/vhosts/example.com/httpdocs/extensions/BootstrapComponents/src/HookRegistry.php(381): MediaWiki\MediaWikiServices::getInstance() #7 /var/www/vhosts/example.com/httpdocs/extensions/BootstrapComponents/src/HookRegistry.php(87): BootstrapComponents\HookRegistry->registerMyConfiguration() #8 /var/www/vhosts/example.com/httpdocs/extensions/BootstrapComponents/src/BootstrapComponents.php(90): BootstrapComponents\HookRegistry->__construct() #9 /var/www/vhosts/example.com/httpdocs/includes/registration/ExtensionRegistry.php(546): BootstrapComponents\BootstrapComponents::init() #10 /var/www/vhosts/example.com/httpdocs/includes/registration/ExtensionRegistry.php(231): ExtensionRegistry->exportExtractedData() #11 /var/www/vhosts/example.com/httpdocs/includes/Setup.php(168): ExtensionRegistry->loadFromQueue() #12 /var/www/vhosts/example.com/httpdocs/includes/WebStart.php(90): require_once('...') #13 /var/www/vhosts/example.com/httpdocs/index.php(44): require('...') #14 {main} thrown in /var/www/vhosts/example.com/httpdocs/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 55 ``` If I comment my current configuration in LocalSettings.php out OR downgrade to FlaggedRevs for 1.36 OR downgrade my PHP to 7.4 the error goes away. ``` #$wgFlaggedRevsAutoconfirm = [ # 'days' => 15, # days since registration # 'edits' => 25, # total edit count # 'spacing' => 3, # spacing of edit intervals # 'benchmarks' => 5, # how many edit intervals are needed? # 'excludeLastDays' => 1, # exclude the last X days of edits from edit counts # 'totalContentEdits' => 50, # $wgContentNamespaces edits OR... # 'totalCheckedEdits' => 25, # ...Edits before the stable version of pages # 'uniqueContentPages' => 5, # $wgContentNamespaces unique pages edited # 'editComments' => 10, # how many edit comments used? # 'email' => true, # user must be emailconfirmed? # 'neverBlocked' => true, # Can users that were blocked be promoted? #]; #$wgFlaggedRevsAutopromote = [ # 'days' => 30, # days since registration # 'edits' => 50, # total edit count # 'excludeLastDays' => 2, # exclude the last X days of edits from below edit counts # 'benchmarks' => 10, # number of "spread out" edits # 'spacing' => 3, # number of days between these edits (the "spread") # 'totalContentEdits' => 100, # edits to pages in $wgContentNamespaces # 'totalCheckedEdits' => 50, # edits before the stable version of pages # 'uniqueContentPages' => 10, # unique pages in $wgContentNamespaces edited # 'editComments' => 25, # number of manual edit summaries used # 'userpageBytes' => 0, # size of userpage (use 0 to not require a userpage) # 'neverBlocked' => true, # username was never blocked before? # 'email' => true, # user must be emailconfirmed? # 'maxRevertedEditRatio' => 0.03, # max fraction of edits reverted via "rollback"/"undo" #]; ``` MediaWiki 1.36 worked with this configuration, PHP 8 and the stable FlaggedRev for 1.36 that can currently be downloaded, the same is true for MediaWiki 1.35 and the respective stable FlaggedRevs version with PHP 8. (I'm aware MediaWiki states it does not support PHP 8 yet, I've just been using it for a long while with no observed issues)
    • Task
    == Steps to reproduce 1. Log in as an `editor` user to a wiki using FlaggedRevs (e.g. huwiki). 2. Find a page that has pending changes (e.g. choose from [[https://hu.wikipedia.org/wiki/Special:PendingChanges|Special:PendingChanges]]). 3. Go to the review view, e.g. by clicking the “review” link on the special page. 4. Wait a few hours to make sure the edit token expires. 5. Try to review the page. == Actual result 6. Nothing. The review button is greyed out and shows //Submitting...// forever, there’s no feedback to the user about the request failing due to the expired token. == Former result 6. A message appeared, telling the user that there’s a problem with the edit session and the user should resubmit the form. (In fact, they had to reload the page //and then// resubmit the form, otherwise the token wasn’t updated.) == //Expected// result 6. The review succeeds. If the token has expired, the JS code renews it and re-submits the form with an up-to-date token instead of requiring the user to reload the page. == Additional information * Likely caused by ba3a7af8 by @Vlad.shapik. * The best would be implementing the behavior described in //Expected result//, but restoring the previous behavior is also acceptable. Not communicating anything with the user is not.
    • Task
    Usages can be replaced with service calls. Remove usages. [[ https://codesearch.wmcloud.org/search/?q=global%20%5C%24mediaWiki%5Cb&i=nope&files=&excludeFiles=&repos= | These ]] seem to be the only usages: * [x] extension-BlueSpiceFlaggedRevsConnector * [x] extension-FlaggedRevs * [x] extension-PageDisqus * [x] skin-Poncho * [x] PHPCodeSniffer should complain if the global is reintroduced. * [] Finally, the global declaration in mediawiki-core index.php should be removed.
    • Task
    With [[https://gerrit.wikimedia.org/r/709218|709218]] merged and deployed (since Thursday), two indexes of `fr_page_qal_rev` and `fr_page_qal_time` should be now unused. We can drop them if DBAs confirm there is no more indexes reading from them.
    • Task
    An i18n message needs creating for `apihelp-stabilize-param-watchlist` {F34527355}
    • Task
    E.g. the [[https://hu.wikipedia.org/wiki/Speci%C3%A1lis:Ellen%C5%91rz%C3%A9si_statisztika?uselang=en|huwiki page]] right now says: > The average review delay for pages with edits currently pending review is 80 d 12 h; the delay measures how long the oldest pending edit has gone unreviewed. > The average wait for edits by users that have not logged in to be reviewed is 25 h 48 min; the median is 3 h 35 min. "average review delay for pages with edits currently pending review" and "average wait for edits by users that have not logged in to be reviewed" are seemingly the same thing but the numbers are vastly different. Needs clearer phrasing / explanation or one of these is misleading and should be removed. (Note that the data is also completely wrong. That's tracked in {T163107}.)
    • Task
    I'm not sure exactly when this broke, presumably after some DerivedPageUpdater refactoring. The WikiPage::mPreparedEdit field is no longer populated, though FlaggedRevs still tries to use it... Fixing the FlaggableWikiPage method seems too difficult given all of the MCR related changes, so it's probably best to use a different approach and just tack the additional flaggedrevs state onto the Title/WikiPage object itself, rather than a subclass that tries to copy some fields over.
    • Task
    {F34262713} {F34262712} Since the last revision may contain vandalism and is not shown by default to the users when flaggedrevs are enabled, this may lead to confusion.
    • Task
    `Linker::link()` and `Linker::linkKnown()` functions are deprecated as of MediaWiki 1.28, and the new `LinkRenderer` is preferred instead. https://doc.wikimedia.org/mediawiki-core/master/php/classLinker.html ``` ./FlaggedRevs/frontend/FlaggablePageView.php: $link = Linker::link( $title, htmlspecialchars( $title->getPrefixedText() ) ); ./FlaggedRevs/frontend/FlaggablePageView.php: $link = Linker::linkKnown( ```
    • Task
    Many smaller projects build a significant backlog of pages needing review. Currently these pages can only be sorted by age or alphabetically; ideally I'd want to review the most important changes first. This would require some sort of interaction with PageAssessments which tracks page importance.
    • Task
    It will bring down the whole wiki. See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/672570/8/backend/FlaggedRevs.php@88 We need to change the merge strategy.
    • Task
    Split from parent per @tgr. [ ] Drop flagging features [ ] Drop having multiple tiers of review [x] Drop tier3 (pristine) support – {41d295479e16e5f8fac08368970f0e75cc045710} [x] Drop tier2 (quality) support – {04ffb5f56f2331138f2463584aacbb702e8d243e} [ ] Clean-up now there's only one tier [x] Drop having multiple dimensions of review ("tone", "style", etc.) [x] Drop "tone" and "style" dimensions – {ddb91cf8b29a894450fe3657dca7153be2797859} [x] Support only one dimension – {3fe0bacc5bb328a676ba7f1ae623bff982a8cba9} [x] Drop ability to have pages immune from review – {0fe4ed9a6842b04324d7525447f2c80855c5dd74} [x] Drop ability to show the version of templates/files that the page used when reviewed – {e4ff4779203d4ec44cdadcfa33f6d634bee1a7f1} [ ] … [ ] Drop UX features [] Special pages: [x] ProblemChanges – {8d8b3822d3ac9d126f69eb0ea39741b3d6ff9849} [x] ReviewedPages – {7de102e939d5df33e5b80c504ca838c192b717bf} [x] ReviewedVersions – {552aaf00394bc3117c8668811ae93838ee23fd5a} (and API equivalent, {dc93e33eb3a73091e5794a31f1125d7a3b0acb03}) [ ] QualityOversight [x] Drop ability to choose which user groups get shown unreviewed versions by default – {50ffcdf7ca938a976fa7ae40158ef9c6d38dd6db} [x] Drop background image on non-low profile wikis when a page has a pending edit you're not seeing – {889ee09d2e9109debe857baf00e078e7279595db} [x] Drop hidden message on non-simple UI wikis when viewing an old stable revision as a a reviewer – {889ee09d2e9109debe857baf00e078e7279595db} [x] {T285608} [ ] … [ ] Drop extension hooks [x] Drop FlaggedRevsFRGenericSubmitFormReady hook – {e894afbca50be0dea4bd96a7118769a4a657f4e1} [ ] Drop FlaggedRevsRevisionReviewFormAfterDoSubmit Hook – {b6291fc8b803a6de84e369ee045e0b9bc3cacd89} [ ] … [] Merge user rights
    • Task
    Let me describe the important problem that we have. It is related to this issue, but rather a tweak than a bug. It was difficult for me to make the PNGs, so I try to write by text. If I have to open new request, please ask, and I will. The text: **Russian Wikinews want unmoderated comments** (verb "patrol" below means "flagged review") 1) There are the "Comments" namespace in Russian Wikinews. It reads "Комментарии:". It is different from "Talk" namespace which reads "Обсуждение:". "Комментарии:" name space is attached only to main articles and not elsewhere, e. g. forums. At each article, link "Комментарии:" a) is attached at the upper tab as a 3rd namespace link b) is transcluded below the article by a custom bot operated by @Krassotkin. Transclusion template contains instructions for commenters and invites //all people// to comment their thoughts on the subject of the news story. This is very different from "Talk:" ("Обсуждение:") which is meant for editors to discuss story //writing process// not its subject and is not transcluded in this way. 2) When a visitor wants to comment, they are given "Комментарии:" namespace page in editing mode. They comment and save. 3) The whole main article becomes "unpatrolled" (un-flagged-reviewed). As result, the visitor cannot view their own comment that they just have written. This is confusing. 4) Only after an "editor"-flagged regular Wikinews author presses "partol" (flagged review) on the //main article//, visitor can see its own comment and maintain further talk. If several visitors try to talk to each other, they are unable to talk in real-time: each edit have to be "patrolled" (flag-rev'd). If any "flagged reviewers" are not available at the time, hours and days may pass. In fact, this is an unintended pre-moderation of comments that is against democratic journalistic free-speech principles that we believe in. The task: cancel this pre-moderation. Adjust the flagging review system in the way when visitors can talk real-time.
    • Task
    Happening in a new mediawiki installation where database was restored using maintenance script `importDump.php`. All pages are now `unchecked`. To avoid having to check 100's of pages. I wanted to use the following maintenance script. ``` php reviewAllPages.php --username Patrick ``` issue: ``` Auto-reviewing all current page versions... Reviewer username: Patrick ...doing page_id from 2 to 101 InvalidArgumentException from line 302 of /var/www/w/includes/CommentStore.php: $row does not contain fields needed for comment rev_comment #0 /var/www/w/includes/CommentStore.php(403): CommentStore->getCommentInternal(Object(Wikimedia\Rdbms\DBConnRef), 'rev_comment', Array, true) #1 /var/www/w/includes/Revision/RevisionStore.php(1529): CommentStore->getCommentLegacy(Object(Wikimedia\Rdbms\DBConnRef), 'rev_comment', Object(stdClass), true) #2 /var/www/w/includes/Revision/RevisionStore.php(1387): MediaWiki\Revision\RevisionStore->newRevisionFromRowAndSlots(Object(stdClass), NULL, 1, Object(Title), false) #3 /var/www/w/extensions/FlaggedRevs/maintenance/reviewAllPages.php(79): MediaWiki\Revision\RevisionStore->newRevisionFromRow(Object(stdClass), 1) #4 /var/www/w/extensions/FlaggedRevs/maintenance/reviewAllPages.php(31): ReviewAllPages->autoreview_current(Object(User)) #5 /var/www/w/maintenance/doMaintenance.php(107): ReviewAllPages->execute() #6 /var/www/w/extensions/FlaggedRevs/maintenance/reviewAllPages.php(106): require_once('/var/www/w/main...') #7 {main} ``` mediawiki version: 1.35.1 T252043 might be related. Please advice.
    • Task
    I can't move pages with my bot account, [[ https://bs.wikipedia.org/wiki/Posebno:SredisnjaAutent/WumpusBot | WumpusBot ]], on wikis that have FlaggedRevs enabled. For instance, my bot account is over 12 months old and has over 50,000 edits on bs.wiki, but [[ https://bs.wikipedia.org/wiki/Posebno:Premjesti_stranicu/Vi%C5%A1egradska_grupa?uselang=en | when I try to move ]] a random page (i.e. "Višegradska grupa"), [[ https://bs.wikipedia.org/w/index.php?title=Vi%C5%A1egradska_grupa&action=info | which isn't move-protected]], I get this error: {F34118516} I seem to be able to move pages that aren't in the main namespace, [[ https://bs.wikipedia.org/wiki/Posebno:Protokol/WumpusBot | as seen here ]]. Another user, [[ https://bs.wikipedia.org/w/index.php?target=Neptune%2C+the+Mystic&namespace=all&tagfilter=&start=&end=&limit=50&title=Posebno%3ADoprinos | Neptune, the Mystic ]], actually told me about this when he tried to move a page on bs.wiki and was unable to do so, even though he [[ https://bs.wikipedia.org/wiki/Posebno:SredisnjaAutent?target=Neptune%2C+the+Mystic | has over 200 edits, his account is a several years old ]], he has the 'autoreview' right, and he [[ https://bs.wikipedia.org/wiki/Posebno:Protokol?type=move&user=Neptune%2C+the+Mystic&page=&wpdate=&tagfilter=&wpfilters%5B%5D=newusers | has moved pages in the past ]], which leads me to believe this is a new issue.
    • Task
    The more recent edits of [[ https://en.wikipedia.org/wiki/User:Jontel | User:Jontel ]] to the [[ https://en.wikipedia.org/wiki/Michael_Rosen | Michael Rosen article ]] require manual review (e.g., [[ https://en.wikipedia.org/w/index.php?title=Michael_Rosen&diff=1007768618&oldid=1007757853&diffmode=source | this]]) , even though Jontel is extended confirmed. The protection of the page also does not show up in the page's [[ https://en.wikipedia.org/w/index.php?title=Special:Log&page=Michael_Rosen&type=protect | protection log ]], but the box with the reason for protection shows up when reviewing. The page protection status itself also does not mention pending changes protection. This bug might be similar to https://phabricator.wikimedia.org/T233561.
    • Task
    Hi, I have noticed in the last few days (I guess with MediaWiki 1.36/wmf.29-31) one thing has been changed. enwn uses FlaggedRevs extension, which came with "Mark this version as reviewed" option for reviewers/editor (user group) on the edit page option. Right next to "This is a minor edit" and "Watch this page". It is now missing. Unless accepted otherwise, the edits would not be sighted ("accepted") by default. But now, it is "automatically checked". Only reviewers/editors can sight that edit, but looks like reviewer's edits are autosighted. **Steps to reproduce** # On a wiki using FlaggedRevs, sight a revision. # Now as a reviewer ("editor" group), make any changes to the page. # The button for "mark this version as reviewed" is no longer there. # Save the page, and check the history, it is automatically sighted. # Now let a non-editor make an edit. # When an editor now clicks on edit source, they see "Mark this version as reviewed" is now visible. **Expected behaviour** # "Mark this version as reviewed" option for reviewers/editor (user group) on the edit page option MUST always be present, and should not be selected by default # Edits by reviewers SHOULD NOT be autosighted.
    • Task
    There is no reason why the ProtectionForm expiration dropdowns should be in the content language since it doesn't change the submitted value. The issue is that items in the dropdown are defined in the message. This applies to: [] Core (ProtectionForm.php) [] FlaggedRevs (FlaggedRevsUIHooks.php) [] ArticleFeedbackv5 (ArticleFeedbackv5Hooks.php)
    • Task
    Currently if I open Special:Stabilization with an account that doesn't have permissions to stabilize pages, I see this generic error message: {F34083230} It should display why the user can't do that like other special pages do that: {F34083232}
    • Task
    Issue raised here by @Nedops: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Oznaczanie_wersji Problem: * Sometimes there are many pending revisions in an article. When you review a version between the last marked as reviewed and the latest, then the latest version gets marked as reviewed. Example from plwiki: # I went to [[ https://pl.wikipedia.org/wiki/Mistrzostwa_Europy_w_Pi%C5%82ce_R%C4%99cznej_Kobiet_2020 | this article ]] # Unmarked the latest (at that time) revision ([[ https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_R%C4%99cznej_Kobiet_2020&diff=61682540&oldid=61682483 | this one ]]) # Went into one of the previous revisions ([[https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_R%C4%99cznej_Kobiet_2020&oldid=61682474 | this one ]]) # Scrolled all the way to the bottom, clicked "Accept revision" # The latest revision (and therefore the entire article) got marked as accepted ([[ https://pl.wikipedia.org/wiki/Specjalna:Rejestr?type=&user=&page=Mistrzostwa+Europy+w+Pi%C5%82ce+R%C4%99cznej+Kobiet+2020&wpdate=&tagfilter=&wpfilters%5B%5D=review&wpfilters%5B%5D=patrol | reviewing log ]]) In the diff view, the button "Accept revision" at top of the page seems to be working just fine. As a side note, when it comes to the box on the bottom, the option to "advertise to other users that you are reviewing these changes” seems to be broken for years already.
    • Task
    New rows are added to the `flaggedrevs_statistics` table every time `FlaggedRevsStats::updateCache` is called, but the old values are never removed; only the values for the latest timestamp are ever needed. Can the old rows be purged? For reference, there are currently `1611863` rows in the enwikibooks table, `1611818` of which are for timestamps that are not the latest and thus are never used, and `45` of which are used until the table is updated again. ``` lines=10 MariaDB [enwikibooks_p]> SELECT COUNT(*) FROM flaggedrevs_statistics; +----------+ | COUNT(*) | +----------+ | 1611863 | +----------+ 1 row in set (0.50 sec) MariaDB [enwikibooks_p]> SELECT MAX(frs_timestamp) FROM flaggedrevs_statistics; +--------------------+ | MAX(frs_timestamp) | +--------------------+ | 20201202020039 | +--------------------+ 1 row in set (0.00 sec) MariaDB [enwikibooks_p]> SELECT COUNT(*) FROM flaggedrevs_statistics WHERE frs_timestamp != 20201202020039; +----------+ | COUNT(*) | +----------+ | 1611818 | +----------+ 1 row in set (1.59 sec) MariaDB [enwikibooks_p]> SELECT * FROM flaggedrevs_statistics WHERE frs_timestamp = 20201202020039; +----------------+-------------------------------------+--------------+ | frs_timestamp | frs_stat_key | frs_stat_val | +----------------+-------------------------------------+--------------+ | 20201202020039 | pendingLag-average | 42779539 | | 20201202020039 | reviewLag-anon-average | 1425172 | | 20201202020039 | reviewLag-anon-median | 961228 | | 20201202020039 | reviewLag-anon-percentile:35 | 682757 | | 20201202020039 | reviewLag-anon-percentile:45 | 878580 | | 20201202020039 | reviewLag-anon-percentile:55 | 1146432 | | 20201202020039 | reviewLag-anon-percentile:65 | 1659521 | | 20201202020039 | reviewLag-anon-percentile:75 | 1813621 | | 20201202020039 | reviewLag-anon-percentile:85 | 3447574 | | 20201202020039 | reviewLag-anon-percentile:90 | 3877841 | | 20201202020039 | reviewLag-anon-percentile:95 | 4657014 | | 20201202020039 | reviewLag-anon-sampleEndTimestamp | 1235078705 | | 20201202020039 | reviewLag-anon-sampleSize | 62 | | 20201202020039 | reviewLag-anon-sampleStartTimestamp | 1234473905 | | 20201202020039 | reviewLag-user-average | 857294 | | 20201202020039 | reviewLag-user-median | 708265 | | 20201202020039 | reviewLag-user-percentile:35 | 666534 | | 20201202020039 | reviewLag-user-percentile:45 | 701822 | | 20201202020039 | reviewLag-user-percentile:55 | 778604 | | 20201202020039 | reviewLag-user-percentile:65 | 859203 | | 20201202020039 | reviewLag-user-percentile:75 | 956896 | | 20201202020039 | reviewLag-user-percentile:85 | 1090743 | | 20201202020039 | reviewLag-user-percentile:90 | 1184455 | | 20201202020039 | reviewLag-user-percentile:95 | 1382784 | | 20201202020039 | reviewLag-user-sampleEndTimestamp | 1235078705 | | 20201202020039 | reviewLag-user-sampleSize | 455 | | 20201202020039 | reviewLag-user-sampleStartTimestamp | 1234473905 | | 20201202020039 | reviewedPages-NS:0 | 65228 | | 20201202020039 | reviewedPages-NS:10 | 8819 | | 20201202020039 | reviewedPages-NS:102 | 4029 | | 20201202020039 | reviewedPages-NS:110 | 2294 | | 20201202020039 | reviewedPages-NS:6 | 1007 | | 20201202020039 | reviewedPages-NS:828 | 97 | | 20201202020039 | syncedPages-NS:0 | 63647 | | 20201202020039 | syncedPages-NS:10 | 8817 | | 20201202020039 | syncedPages-NS:102 | 4026 | | 20201202020039 | syncedPages-NS:110 | 2294 | | 20201202020039 | syncedPages-NS:6 | 1007 | | 20201202020039 | syncedPages-NS:828 | 97 | | 20201202020039 | totalPages-NS:0 | 81959 | | 20201202020039 | totalPages-NS:10 | 8921 | | 20201202020039 | totalPages-NS:102 | 4037 | | 20201202020039 | totalPages-NS:110 | 2294 | | 20201202020039 | totalPages-NS:6 | 1771 | | 20201202020039 | totalPages-NS:828 | 97 | +----------------+-------------------------------------+--------------+ 45 rows in set (0.86 sec) ```
    • Task
    In support of {T191231}, FlaggedRevs should be migrated to using Abstract Schema
    • Task
    A config or modify action (not reset) includes the parameters of the applied protection, but the expiry isn't in a meaningful format as far as JavaScript is concerned. See, e.g., https://en.wikipedia.org/w/api.php?action=query&format=json&list=logevents&titles=Wikipedia%3AAdministrators'%20guide%2FProtecting%2FProtect&formatversion=2&leprop=type%7Ctimestamp%7Cdetails&letype=stable&letitle=Wikipedia%3AAdministrators'%20guide%2FProtecting%2FProtect&lelimit=10 ``` "logevents": [ { "params": { "override": 1, "autoreview": "autoconfirmed", "expiry": "20201101171850" }, "type": "stable", "action": "config", "timestamp": "2020-11-01T17:08:50Z" }, ``` The `timestamp` is nice but `params.expiry` is awful. It should be ISO-8601(ish) like the `timestamp` and other core queries (e.g., other logevents details do this properly (e.g. [[ https://en.wikipedia.org/w/api.php?action=query&format=json&list=logevents&titles=Wikipedia%3AAdministrators'%20guide%2FProtecting%2FProtect&formatversion=2&leprop=type%7Ctimestamp%7Cdetails&letype=protect&letitle=Wikipedia%3AAdministrators'%20guide%2FProtecting%2FProtect&lelimit=10 | protect ]], [[ https://en.wikipedia.org/w/api.php?action=query&format=json&list=logevents&titles=User%3AThisIsaTest&formatversion=2&leprop=type%7Ctimestamp%7Cdetails&letype=block&letitle=User%3AThisIsaTest&lelimit=10 | block ]])).
    • Task
    Please add a time based autoacceptance feature to FlaggedRevs. The purpose is to add a time delay before unreg/newbie edits go live and a vandalism patroller can immediately approve or reject that edit. Purpose: Ability to delay all newbie/unreg edits by ~2 hours unless manually accepted by reviewers. A time delay for all newbie edits will help Vandalism patrollers and watchlisters to accept or revert newbie edits before they become live. It is for all edits in a wiki. Unreviewed edits can go live after the delay time (eg. 2 hours), hence there will not be any backlog or a conflict with "editable by anyone" policy. It will facilitate a better alternative to [[https://en.wikipedia.org/wiki/Wikipedia:Delayed_revisions|WP:Delayed revisions]]. It will be a big step in fighting misinformation and vandalism. url: https://en.wikipedia.org/wiki/Wikipedia:Delayed_flagged_revisions
    • Task
    With the conventional FlaggedRevs configuration, anonymous users can't see unreviewed changes, including changes made by them. Normally, anonymous users can see their own changes right after saving them; VisualEditor sometimes causes the page to be reloaded after a save, which makes changes disappear. Given the almost-complete lack of communication about the FlaggedRevs workflow to the editor (there is an edit notice, but VE makes those less prominent; see also T179326), this is a pretty confusing experience. Probably the reload should add `stable=0` to the URL so the edit is shown. FlaggedRevs' communication to the editor is poor and should be improved regardless, but showing how the edit looks seems like a sensible thing to do.
    • Task
    {F32398578} On mobile devices when a not-logged-in user opens an article with an pending review in desktop-mode, the tab for the history (in German: Versionsgeschichte) is missing, see screenshot. Maybe this happens only in languages with longish text in the tabs at the top (Ungesichtete Änderungen = pending changes; Quelltext bearbeiten = edit source(?)) Screenshot is from https://de.wikipedia.org/wiki/Dok2 which today has pending review
    • Task
    Much like `ApiProtect`, having this in the `stabilize` action would be helpful.
    • Task
    The `flaggedpage_config` has a `fpc_select` field that is unused. See codesearch: https://codesearch.wmcloud.org/search/?q=fpc_select&i=nope&files=&repos= Use appears to have been removed by @aaron in 2010 in c6cb71ae089c118ecd024059186c0fcfa75c0762 Can the column be removed?
    • Task
    This autopromote log entry got tagged with "VisualEditor": https://pl.wikipedia.org/wiki/Specjalna:Rejestr?type=rights&page=User%3ATemuera&subtype=autopromote&uselang=en Probably the user's last edit was made with the visual editor. The tag isn't relevant here and shouldn't be applied. (Spotted while working on T237191)
    • Task
    Since "FlaggedRevs" has been migrated to extension registration (`extension.json`), the value of `$wgFlaggedRevsNamespaces` can not be set properly in the `LocalSettings.php`. FlaggedRevs sets `NS_MAIN`, `NS_FILE` and `NS_TEMPLATE` as default for `$wgFlaggedRevsNamespaces`[1]. Unfortunately as `array_merge` is used as a "merge strategy" for this setting by default, there is no way to //remove// any of these again. e.g. setting ``` wfLoadExtension( 'FlaggedRevs' ); $wgFlaggedRevsNamespaces = [ NS_HELP ]; ``` in the `LocalSettings.php` will result in `$wgFlaggedRevsNamespaces === [ NS_MAIN, NS_FILE, NS_TEMPLATE, NS_HELP ]` instead of `$wgFlaggedRevsNamespaces === [ NS_HELP ]` on runtime. Therefore admins can not disable FlaggedRevs for `NS_MAIN,` `NS_FILE` or `NS_TEMPLATE` anymore. Tested with * MediaWiki REL1_35 (15a4675f) * FlaggedRevs REL1_35 (91cae85c) If any possible a fix of this should be backported to `REL1_35` of this extension. [1] https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/91cae85cd39dafe31d17f001648904c70b03e3dc/extension.json#L428-L434
    • Task
    * There are **214** `public static` functions in this codebase. * 12 more are `private static`, 37 `protected static`. * 353 are public but not static. * 13 are private but not static, 155 protected. In total there are 738 named functions (excluding magic functions like `__construct`). In other words, about 3/4 of all the the stuff in this codebase is public. And more than 1/3 of the public stuff is static. All this is essentially #technical-debt. Priorities are: * Make as much code as possible private. When a method is only public to be able to test it, use TestingAccessWrapper. * Split large classes up into smaller ones. E.g. it might be worth to move all hook handlers into separate classes. * Make as much code as possible non-static. * Avoid `global $wg…` as much as possible. Inject Config objects instead.
    • Task
    === Error === `MediaWiki version:` **`1.35.0-wmf.37`** ```name=message Exception: Flagged revision with ID 107684164 exists with unexpected fr_page_id ``` ```name=exception.trace,lines=10 #0 /srv/mediawiki/php-1.35.0-wmf.37/extensions/FlaggedRevs/business/RevisionReviewForm.php(303): RevisionReviewForm->approveRevision(MediaWiki\Revision\RevisionStoreRecord, NULL) #1 /srv/mediawiki/php-1.35.0-wmf.37/extensions/FlaggedRevs/business/FRGenericSubmitForm.php(191): RevisionReviewForm->doSubmit() #2 /srv/mediawiki/php-1.35.0-wmf.37/extensions/FlaggedRevs/frontend/specialpages/actions/RevisionReview.php(116): FRGenericSubmitForm->submit() #3 /srv/mediawiki/php-1.35.0-wmf.37/includes/specialpage/SpecialPage.php(580): RevisionReview->execute(NULL) #4 /srv/mediawiki/php-1.35.0-wmf.37/includes/specialpage/SpecialPageFactory.php(634): SpecialPage->run(NULL) #5 /srv/mediawiki/php-1.35.0-wmf.37/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext) #6 /srv/mediawiki/php-1.35.0-wmf.37/includes/MediaWiki.php(986): MediaWiki->performRequest() #7 /srv/mediawiki/php-1.35.0-wmf.37/includes/MediaWiki.php(543): MediaWiki->main() #8 /srv/mediawiki/php-1.35.0-wmf.37/index.php(47): MediaWiki->run() #9 /srv/mediawiki/w/index.php(3): require(string) #10 {main} ``` === Impact === User unable to submit their content review, and getting a generic internal system error page. The page likely remains marked as unreviewed. === Notes === Noticed one of these for wmf.37 in log triage meeting.
    • Task
    I am creating a open-source wiki that aims to facilitate the communication of medical information during covid-19 pandemic and beyond. To ensure accuracy, users should be aware what edits are not yet moderated. To ensure timely communication, they should still be shown to the readers, preferably on the main page. It will be best to differentiate edits made by doctors vs nurses vs pharmacists, perhaps by using different formatting for edits from different customized user groups. The solution I am imaging is a google-doc style main page with different edits made by different user groups shown in different colours. I am wondering how we can leverage on the existing functionalities from FlaggedRevs to achieve this goal. Thank you! P.S. The wiki is on clinicianwiki.com, in case anyone is interested in contributing to this open source initiative.
    • Task
    Steps to Reproduce: 1. Create a page from an account without editor, in a namespace recognized by Flagged Revs 2. Use the api to review that one revision from an account with reviewer: ``` { action:"review", revid:<revision id> } ``` 3. Now the page is marked as reviewed in recent changes, you can look at verify 4. Move the page to a namespace ignored by Flagged Revs (e.g. User) Actual Results: The page is now marked as Unreviewed in Recent Changes Expected Results: The page should still be reviewed in recent changes.
    • Task
    Whenever I want to edit e.g. links or references in VE/NWE somewhere at the very bottom of the page, the edit window with the dropdown will be overlapped by the FlaggedRevs options in the DataAfterContent element, making it very hard to do a proper selection. See this screenshot from German WP in NWE: {F31817807}
    • Task
    When changing the protection on https://en.wikipedia.org/w/index.php?title=Kingdom_of_England&action=history from semi-protection to extended-confirmed-protection, I submitted the form and was sent back to the "change protection settings" screen with a red "Invalid expiration date." error at the top. I submitted the form again without making any changes, and it redirected me back to the article. However, based on the history, it seems that both protection attempts modified the protection settings in the database. The expected behavior is for the protection form not to throw an error for no reason - and that if it does throw an error for some legitimate reason, then it should not also perform the action that supposedly caused the error. The message shown is `stabilize_expiry_invalid`, which is returned when `PageStabilityForm::getExpiry` considers an expiry to be invalid. FlaggedResv shouldn't try to parse the expiry and return an error if the user is not trying to enabled Pending Changes. Apparently this happens fairly regularly, @Primefac mentioned this being something that they encounter routinely.
    • Task
    Not referring to `$wgFlaggedRevsTags`, but [[https://www.mediawiki.org/wiki/Extension:FlaggedRevs | from what I can see ]], FlaggedRevs doesn't support the `tags` parameter like, say, the edit action API.
    • Task
    Since rEFLR985dc2b5d569df5ccf2567f18bd5f6fbe60f8658 by @Jdlrobson the mw-fr-watchlist-pending-notice message ("there are unreviewed changes on your watchlist") uses the warningbox class which comes with styling by default. In {source EFLR:frontend/modules/ext.flaggedRevs.basic.css, commit=f5d01c4f70b4, line=224-230} we have redundant and deviant styling for this div by class fr-watchlist-pending-notice (more like errorbox). As the fr-watchlist-pending-notice class seems to be used nowhere else I propose to remove it completely. For users who want to hide the message it is possible to access it by id.
    • Task
    I noticed invalid pairs page-revision in //flaggedrevs// table - they are old and different than in //revision// table. https://quarry.wmflabs.org/query/40426 Recently I observed it on delete-restore (also moves may be involved; often to merge histories) operation on pages with already flagged revisions so when restored this table has not updated page id. It makes impossible to mark revisions on restored page (but marked previously) made before deletion.
    • Task
    {F31127339} The “oczekuje na przejrzenie” link (waiting for review) is blown up all over the place.
    • Task
    If I want to review a change at Special:PendingChanges, when pressing the review button on a mobile device (or with the MobileFrontend enabled) I'll be taken to the Special:MobileDiff page without having the option to review that diff. Sometimes I can review the diff but for most of the time, I can't.
    • Task
    https://en.wikipedia.org/w/index.php?title=J.S.S._Academy_of_Technical_Education,_Noida&diff=917234861&oldid=914475481&diffmode=source should have been accepted automatically, but wasn't https://en.wikipedia.org/w/index.php?title=International_Space_Station&dir=prev&offset=20190921172729&limit=20&action=history includes a series of edits by the same user, the first half of which were automatically accepted, before it suddenly stopped being automatically accepted
    • Task
    ```counterexample,name=message Duplicate get(): "test2wiki:flaggedrevs:includesSynced:2195" fetched 4 times ``` ```name=fields type: mediawiki phpversion: 7.2.2 level: WARNING channel: memcached ``` Probably intentional, should be avoided by passing down the value, or (if needed independently) consider process-caching.
    • Task
    Proposal: in the logged comment added to the history in the [[https://en.wikipedia.org/wiki/Wikipedia:Reviewing_pending_changes|Pending change review]] process, for accepted revisions that have no "accept" comment by the reviewer, unlink the word "accepted" and make it plaintext. For accepted revisions that have an "accept" comment, link the word "Accepted" to the log item that contains the reviewer's comment. Alternative UX: To make it more obvious when there is or isn't an accept comment, add another token ('//why//', '//reason//', '//log//', or some such) to the acceptance tag, and link that, instead. Thus, no-comment acceptances would have three words ([accepted by Username]), and commented acceptances would have four: ([accepted by Username ([log-hyperlink|reason)]). Detailed rationale, and real-world examples at [[https://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#Proposal_to_improve_visibility_of_"Accepted"_comment|this discussion]] at [[https://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes|Wikipedia talk:Pending changes]]. (Sorry, still trying to figure out how to find a project or tags...)
    • Task
    Users should not be able to "approve" revisions of a page that predate the configuration of pending changes on the page. Example: pending changes were first added to Prince Harry (https://en.wikipedia.org/w/index.php?title=Prince_Harry,_Duke_of_Sussex&offset=20130909140606&limit=50&action=history) on 24 August 23 However, users can mark prior revisions as accepted. See [ log entries ]( https://en.wikipedia.org/w/index.php?title=Special:Log&dir=prev&offset=20190106230610&limit=2&type=review&user=DannyS712&page=Prince+Harry%2C+Duke+of+Sussex ) in which I approve (and then unapprove) [ the revision before pending changes were configured ]( https://en.wikipedia.org/w/index.php?title=Prince_Harry,_Duke_of_Sussex&oldid=569932419 )
    • Task
    Hi, the Hebrew Wikisource community requests a reconfiguration of the Flagged Reviews extension, **[[ https://he.wikisource.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%98%D7%A7%D7%A1%D7%98:%D7%9E%D7%96%D7%A0%D7%95%D7%9F#Configuration_request_for_Flagged_Reviews | as explained at this link with local consensus]]**. Thank you, Dovi
    • Task
    $wgFlaggedRevsAutoReviewNew - https://www.mediawiki.org/wiki/Topic:Qqv9kybjgisvij1x ~~$wgFlaggedRevValues too~~ Then we can deprecate and remove from the code as back compat.... Basically most of `FlaggedRevs::load()` needs cleaning up...
    • Task
    `$wgFlaggedRevsNamespaces` sets the namespaces in which flagged revisions is enabled, but it doesn't seem that info is exposed to the user like `$wgFlaggedRevsTags` (via the `tags` object in `wgFlaggedRevsParams`). It'd be helpful to have the namespaces as well, and `wgFlaggedRevsParams` seems already set up for it.
    • Task
    Currently FlaggedRevs supports two modes: either all pages have a stable version (that is, readers who are not logged in see the last reviewed revision instead of the current one), or having stable versions is a protection-like functionality that needs to be enabled manually on a per-page basis. The first causes huge backlogs and confuses new editors and possibly harms retention; the second does not really help with vandalism. Ideally we should fall back to the stable version only when we suspect the current version is problematic. To support that, FlaggedRevs should provide hooks or a similar mechanism for other extensions to trigger stable mode on suspicious edits. Potential callers include ORES and AbuseFilter. See also {T203127}. (Note though that FlaggedRevs would cause the page to fall back to the last reviewed revision, not the last revision before the suspicious edit. That might or might not be preferable, but would be a lot more complicated to do.) Some communities //[citation needed]// already do something similar with bots (see also {T57081}), but it would be nice if it could be built into the software. One potential complication is that the check might be too slow to be done before save (that is probably the case with ORES) so the traditional hook model might not work, and some kind of jobqueue-based approach might be needed instead.
    • Task
    If an extension like Extension:FlaggedRevs is used, it should ideally be able to consistently force stable revisions everywhere, but the action=parse API currently doesn't respect extensions like this. Steps to Reproduce: - Install a wiki with Extension:FlaggedRevs installed - Edit a page but keep it unreviewed - Do an API call via action=parse (`/api.php?action=parse&page=<Title>&prop=text&wrapoutputclass=`) Actual Results: The unreviewed most recent version of the page is used for parsing. Expected Results: The stable version as defined by Extension:FlaggedRevs should be used for parsing.
    • Task
    I have a beta enabled. I visited an article on plwiki. Changes were shown on top (before article body). There was no button to flag the revision (pl: oznacz jako przejrzaną). I would expect to have the button directly below diff.
    • Task
    https://ca.wikinews.org/w/index.php?title=Especial:Stabilization&page=Portada&uselang=fr shows `La version stable ; s&#039;il n&#039;y en a pas, alors la révision courante` instead of the [[ https://translatewiki.net/wiki/MediaWiki:Stabilization-def1/fr | real translation of `MediaWiki:Stabilization-def1` system message ]]: `La version stable ; s'il n'y en a pas, alors la révision courante` Related: {T142882}
    • Task
    On en.wp, when you edit an article that has Pending Changes protection and which currently has edits awaiting review, there's checkbox to "Accept this version (includes X pending changes)". When the box is unchecked, the save button says "Submit changes" (which I assume to mean "submit changes for review") When the box is checked, the button says "Save page" while it should say "Publish changes", to match the save button on non-Pending Changes protection-pages. IIRC, this change from "Save page" to Publish changes on normal pages was mandated by Legal some time ago, so it should also be changed here. The text on the button is managed by the updateSaveButton() function in ext.flaggedRevs.advanced.js, which calls mw.msg('savearticle') (https://phabricator.wikimedia.org/diffusion/EFLR/browse/master/frontend/modules/ext.flaggedRevs.advanced.js$153). That's as far as my debugging skills went, but it probably means that only a config change on en.wp is needed, right?
    • Task
    The page preview function shows an unaccepted revision when logged out and viewing pending-protected pages. Very important since some vandalism was briefly visible from the main page due to this bug.
    • Task
    Steps to reproduce: 1. Go to https://de.wikipedia.beta.wmflabs.org/wiki/1._M%C3%BCnchner_SC?veaction=editsource 2. If that's not already the case, make your window small enough that the notice "Nicht markiert" in the top right corner overlaps the text to edit. Expected result: Actually, the notice should not overlap at all, but at least it shouldn't mess up position of syntaxhighlighting. Actual result: {F26226219} Note that the syntaxhightlight and the actual text now differ, as visible in the red underline for "SC", which is one line to low.
    • Task
    # go to an unreviewed article # click on `Edit Scrouce` button # don't make changes but tick the `review this page` checkbox under the page in the saveng # Page will be not reviewed This only happens to the review checkbox, not to the watch checkbox. I think changes should be reviewed then, too.
    • Task
    FlaggedRevs can mark pages as needing review when a transcluded template or image changes (but the text of the page does not). It would be great to have the same for Wikidata.
    • Task
    Consider the following scenario: There is a book in Wikibooks and I want to set its viewing setting to stable by default. Currently I need to open every page inside the book and then set the viewing stability. What I would prefer instead is an option to //cascade// the viewing setting (like how we can do it for articles in full protection mode) so that every linked page inside a particular page is set to that viewing mode. This could also be extended to categories or namespaces, for instance //Category of children's topics//.
    • Task
    To leverage the existing feature extraction infrastructure in [[https://github.com/wiki-ai/revscoring|revscoring]] for FlaggedRevs models, the API extractor needs to be modified such that the //parent// revision is not the most recent, but the most recent //approved// revision. - [x] Refactor parent extraction into separate method - [x] Subclass Revision() for use in FlaggedRevs models - [x] Create API (based on the queries prepared in T196241) - [x] Test - [ ] document - [ ] find a way to integrate it into revscoring without breaking the regular API extractor The API to find the "flagged parent" is available on Toolforge: [[https://tools.wmflabs.org/kokolores/api/v1/de/parent/169737954/]]
    • Task
    == Background The FlaggedRevs rating box (the one discussed in T155878) is at the top of the content area by default, meaning it can affect the layout of the page content (e.g. other elements floated to the right). Hungarian Wikipedia addressed this problem by moving the box to the title, exactly to the place where the indicator icons appeared some years later. However, they use different positioning, meaning that they overlap if both are present. Please create an option (PHP setting) to move the box to the indicators in PHP code. It may require some visual changes to align with the other indicators’ style, especially the help link’s, as they are often next to each other on category pages. {F34176533} My conception about how it would look like: {F34487431} (This is not exactly the same: different icon because it’s a different state, also I don’t want to change whether text is shown or not, but I hope you get the idea.) Beta test link: https://de.wikipedia.beta.wmflabs.org/wiki/FRtest2 == Acceptance criteria [] Make the FlaggedRevs box an indicator
    • Task
    For an ORES model, we are interested in the following two kinds of revisions: The pair (rev 3, parent: rev 0) as //approved// in a revison chain like: - **rev 0** //approved// (auto or manual) - rev 1 - rev 2 - **rev 3** //manually approved// The pair (rev 2, parent: rev0) as //rejected// in a revision chain like: - **rev 0** //approved// (auto or manual) - rev 1 - **rev 2** - rev 3 revert back to rev 0 without approval The methods used in T194594 need to be verified and documented prior to building larger data sets.
    • Task
    MediaWiki: 1.31 FlaggedRevs; latest version on REL1_31 branch Debian Stretch PHP 7.2 ___ I have noticed that some i18n is missing in the "Re-Review this revision" portion of the page. After searching on GitHub, I determined that the said messages are not in the i18n files. ___ To reproduce: 1. Install MediaWiki and FlaggedRevs using the versions above 2. Be sure that you are in the editor or reviewer user group 3. Look at the bottom of a page with FlaggedRevs enabled. You see raw message names Screenshot attached below. ___ {F18445507}
    • Task
    On wikis with Flagged Revisions enabled, a very large number of reviewed edits is available which could be used as both training and test data for ORES models. This has already been done once as an experiment for fiwiki ({T166235}, [[https://github.com/wiki-ai/editquality/pull/112|PR #112]]). There are two corresponding work log entries with some details: - [[ https://meta.wikimedia.org/wiki/Research_talk:Automated_classification_of_edit_quality/Work_log/2017-07-26 | 2017-07-26]] - [[ https://meta.wikimedia.org/wiki/Research_talk:Automated_classification_of_edit_quality/Work_log/2017-08-03 | 2017-08-03 ]] I would like to further explore this approach and see whether # the preliminary findings regarding the usefulness of Flagged Revision data for scoring edits in general hold for other wikis as well # a model trained on past Flagged Revision data can be used for {T165848} In the process, I plan to document a re-usable method to create data sets from Flagged Revision data.
    • Task
    Random article can only lead to Reviewed pages at zh-classical wikipedia.Does not lead to Unreviewed pages please. discussion:https://zh-classical.wikipedia.org/wiki/維基大典:會館#清風翻書 thanks
    • Task
    Due to the fact that FlaggedRevisions does not use OOUI the experience on mobile + Minerva is bad. We should port it to OOUI to fix that. Convert FlaggedRevision interface elements to [[ https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr | OOUI ]]. Example: {F16529253 width=100%}
    • Task
    Some wikis use a mechanism where FlaggedRevs can be configured individually for each page. On the English Wikipedia, this is called Pending Changes. Pending Changes level 1 (PC1) is currently in use. When PC1 is enabled on a page, accepted changes are highlighted in light blue (tested: MonoBook, Modern and Vector skins). The presence of white lines (usually reverted changes) is a helpful visual hint that PC1 is indeed needed and should continue to be used. When PC1 is then disabled, the highlighting of past edits is removed. However, continuing to display that information for those edits to whom it applied when PC1 was active should be the default. Removing the information conveys no discernible benefits, while retaining it more easily shows the extent to which protection measures may be warranted. I suspect but have not tested (for obvious reasons) that if an admin were to misclick and disable PC1 by mistake, the historic record would at once become unrecoverable through the UI accessible to admins, even if PC1 were re-enabled. Only new changes would then be highlighted again. (Additionally, but not quite so importantly, when PC1 is active, the usernames of who accepted certain changes is also displayed, or a note that a change was automatically accepted, for those with sufficient privilege. This display is also lost when disabling PC1.)
    • Task
    Similar to T32750, the Hungarian Community would like to ask an opportunity to ping a user from FlaggedRevs review summary (the optional comment field where you can write notes when you mark an edit as reviewed). [[https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Kocsmafal_(m%C5%B1szaki)&oldid=19349465#Felmer.C3.BCl.C5.91_.C3.B6tletek | The idea ]] was [[ https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Editing/Ping_users_from_the_edit_summary | mentioned ]] on the Community Wishlist. It would affect only those wikis which use FlaggedRevs and would behave the same as T32750.
    • Task
    **A succinct problem statement to give context for why the review was initiated.** This extension has been deployed to prod around seven years ago and after a while it became virtually without any maintainer, Technical debt in this code is unimaginable and in matter of UX/UI it's non-standard and out-dated but any (of my) attempts to to modernize it failed due to out-of-date and non-standard php code. **Current developers/maintainers:** None {icon exclamation-triangle color=orange} **Number, severity, and age of known and confirmed security issues:** T234736 {icon exclamation-triangle color=yellow} **Was it a cause of production outages or incidents? List them.** Found this: https://wikitech.wikimedia.org/wiki/Incident_documentation/20170111-multiversion but it might be not that related **Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?** No, given the nature of the extension, it's very unlikely it will need more hardware any time soon. **Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?** Yes. The extension is a frequent cause of problems like PHP errors and PHP fatals (such as T174803). See more at <https://phabricator.wikimedia.org/project/board/296/query/all/>. **When it was first deployed to Wikimedia production** * In mid-2008 to de.wikipedia.org. (Per <https://meta.wikimedia.org/wiki/Flagged_Revisions>) * In late-2010 to en.wikipedia.org (According to [[https://wikitech.wikimedia.org/wiki/FlaggedRevs_setup/2010-11-17_Rollout_Checklist | this]]) **Usage statistics based on audience(s) served** [[ https://meta.wikimedia.org/wiki/Flagged_Revisions#Flagged_Revisions_on_Wikimedia_projects | More than 45 Wikimedia projects ]]. **Changes committed in last 1, 3, 6, and 12 months** ? **Reliance on outdated platforms (e.g. operating systems)** ? **Number of developers who committed code in the last 1, 3, 6, and 12 months** ? **Number and age of open patches** ? **Number and age of open bugs** ? **Number of known dependencies?** Unknown. The configuration page mentions Echo, Scribunto and some other WMF extensions **Is there a replacement/alternative for the feature? Is there a plan for a replacement?** There is no replacement or alternative mapped or planned. One option would be to undeploy this from production. However, doing so would remove the ability for communities to protect pages in a way that still allows contributions. (In other words, it removes the ability to perform pre-publish edit review.)
    • Task
    Now if a page has Pending changes protection and patrollers add patrol tag to each revision MediaWiki doesn't accept the pending revision. for example: In page [[foo]] we have 5 pending revisions which are patrolled. MediaWiki doesn't show the pending texts to IP's although they are patrolled because the pending revisions are not Accepted.
    • Task
    FlaggedRevs switches out `publishpage`/`publishchanges` (or `save…` equivalents) with `revreview-submitedit`. It does this through the EditPageBeforeEditButtons hook, with the `changeSaveButton` method in FlaggablePageView that has a lot of fragile, ugly hackery to just replace two configured message keys. Can we "just" sub-class EditPage, replace `getSubmitButtonLabel` (to do this more neatly), and provide it out as an API for client editors somehow?
    • Task
    Hi all, We're trying to use FlaggedRevs for managing page revision approvals in our management system. One of the requirements of this system is that several reviewers have to accept new page versions before they are accepted as the stable version. Different pages have different people responsible for approving them: e.g. different experts and different managers, each with their expertise and responsibilities. The workflow we have in mind would look like this: 1. A page is created. 2. A template is inserted into the page. This template defines a number of different reviewers who all have to review the page before it is accepted. E.g. reviewer A, reviewer B, reviewer C. 3. A user changes the page. After submitting his (non-trivial) edit, reviewer A receives a notification (by e-mail) of the edit requesting him to review the page. 4. If reviewer A approves the edit, reviewer B is notified. 5. If reviewer B approves the edit, reviewer C is notified. 6. If reviewer C approves the edit, the page is accepted as the next stable version. Could/should this feature be added to FlaggedRevs, or would it make more sense to write an additional extension that communicates with FlaggedRevs, or should we write an entirely new extension? Thanks in advance for any feedback! Lasse
    • Task
    Articles under pending changes are currently not autoaccepting manual reversions from users that meet the auto accept criterion. First encountered at: https://en.wikipedia.org/wiki/Church_of_England Steps to reproduce: 1. Go to article history 2. Click on the timestamp of a historical revesion 3. Click edit this page 4. Make any change to the text of the historical revision and save. This will result in the edit being placed in the pending changes feed, even if one exceeds the autaccept permission level. This has been confirmed to be the case even for users with the sysop flag.
    • Task
    Finnish Wikipedia is currently testing a bot which stabilizes pages when edit is detected as harmful using ORES or AbuseFilter with a 24 hour stabilization. Currently when page is stabilized the system will duplicate the stabilization log comment to the page history using null-edit. However a side effect of this is that when the page is vandalized there will be at least three edits in the page history: 1.) vandalism itself, 2.) stabilization of the page 3.) and the revert. Second problem about null-edits are that they will "break" rollback feature because rollback will revert the null-edit not vandalism before that. Proposed solution in [[https://gerrit.wikimedia.org/r/#/c/361894/|gerrit:361894]] to fix this is to make null-edits optional. To perform stabilization without null-edit the user must have "silentstable" rights and set the "silent" option to true using api or using the checkbox in the user interface. Links: * [[https://fi.wikipedia.org/w/index.php?title=Toiminnot%3ALoki&type=stable&user=VakauttajaBot&page=&year=&month=-1&tagfilter=&hide_thanks_log=1&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1|VakauttajaBot's stabilization logs]] * [[https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(k%C3%A4yt%C3%A4nn%C3%B6t)#Vakautusbotti|Village pump discussion]] * [[https://fi.wikipedia.org/wiki/Wikipedia:Botit#VakauttajaBot|Bot flag request and comments about the broken rollback feature]] * [[https://github.com/4shadoww/stabilizerbot|Link to the bot source code]]
    • Task
    From production. This is probably another case where there are simply few or no matches, and insufficient indexes (like its parent {T164796}). However, in this case, instead of just being slow it times out entirely. ``` mattflaschen@mwlog1001:~$ grep -A20 WUPWEgpAIDgAAFdx4R8AAAAQ /srv/mw-log/exception.log 2017-06-16 12:59:58 [WUPWEgpAIDgAAFdx4R8AAAAQ] mw1186 enwiki 1.30.0-wmf.5 exception ERROR: [WUPWEgpAIDgAAFdx4R8AAAAQ] /w/index.php?namespace=1&tagfilter=visualeditor&title=Special:RecentChanges&hidecategorization=1&hideWikibase=1&hidelog=1&hidepageedits=1 Wikimedia\Rdbms\DBQueryError from line 1145 of /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source,rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,wl_user,wl_notificationtimestamp,page_latest,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` WHERE ct_rc_id=rc_id ) AS `ts_tags`,fp_stable,fp_pending_since,ores_damaging_cls.oresc_probability AS `ores_damaging_score`,ores_goodfaith_cls.oresc_probability AS `ores_goodfaith_score` FROM `recentchanges` LEFT JOIN `watchlist` ON (wl_user = '26209855' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) INNER JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1') WHERE (rc_bot = 0) AND (rc_type != '0') AND (rc_type != '3') AND (rc_type != '6') AND (rc_source != 'wb') AND (rc_namespace = '1') AND (rc_timestamp >= '20170609000000') AND ct_tag = 'visualeditor' AND rc_new IN ('0','1') ORDER BY rc_timestamp DESC LIMIT 50 Function: SpecialRecentChanges::doMainQuery Error: 2062 Read timeout is reached (10.64.32.25) {"exception_id":"WUPWEgpAIDgAAFdx4R8AAAAQ","caught_by":"mwe_handler"} [Exception Wikimedia\Rdbms\DBQueryError] (/srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php:1145) A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source,rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,wl_user,wl_notificationtimestamp,page_latest,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` WHERE ct_rc_id=rc_id ) AS `ts_tags`,fp_stable,fp_pending_since,ores_damaging_cls.oresc_probability AS `ores_damaging_score`,ores_goodfaith_cls.oresc_probability AS `ores_goodfaith_score` FROM `recentchanges` LEFT JOIN `watchlist` ON (wl_user = '26209855' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) INNER JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1') WHERE (rc_bot = 0) AND (rc_type != '0') AND (rc_type != '3') AND (rc_type != '6') AND (rc_source != 'wb') AND (rc_namespace = '1') AND (rc_timestamp >= '20170609000000') AND ct_tag = 'visualeditor' AND rc_new IN ('0','1') ORDER BY rc_timestamp DESC LIMIT 50 Function: SpecialRecentChanges::doMainQuery Error: 2062 Read timeout is reached (10.64.32.25) #0 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(975): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #1 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(1339): Wikimedia\Rdbms\Database->query(string, string) #2 /srv/mediawiki/php-1.30.0-wmf.5/includes/specials/SpecialRecentchanges.php(403): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) #3 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(584): SpecialRecentChanges->doMainQuery(array, array, array, array, array, FormOptions) #4 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(520): ChangesListSpecialPage->getRows() #5 /srv/mediawiki/php-1.30.0-wmf.5/includes/specials/SpecialRecentchanges.php(166): ChangesListSpecialPage->execute(NULL) #6 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/SpecialPage.php(522): SpecialRecentChanges->execute(NULL) #7 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/SpecialPageFactory.php(579): SpecialPage->run(NULL) #8 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Title, RequestContext) #9 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(862): MediaWiki->performRequest() #10 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(523): MediaWiki->main() #11 /srv/mediawiki/php-1.30.0-wmf.5/index.php(43): MediaWiki->run() #12 /srv/mediawiki/w/index.php(3): include(string) #13 {main} ```
    • Task
    Feedback from {T163197}. On wikis where ORES predictions and FlaggedRevs are both enabled, consider to have good faith edits to be automatically marked as patrolled. This would decrease FlaggedRevs backlog, very high on some wikis.
    • Task
    Flagged revision page review statistics (Special:ValidationStatistics) timestamp "The following data was last updated on 17 April 2017 at 08:07. " tells when page is generated. However the data which is shown on the page can be old . In example Hungarian Wikipedias page reviews statistics says that "The average wait for edits by users that have not logged in to be reviewed is 25 h 59 min; the median is 3 h 38 min. " and based on db average 25.59 has been same from 14.4.2015 and median 3 h 38 from 13.12.2014. The data in percentile table is also years old. - https://hu.wikipedia.org/w/index.php?title=Speci%C3%A1lis:Ellen%C5%91rz%C3%A9si_statisztika&uselang=en Based on tool labs database case is that in backend stats are updated but for some reason something keeps inserting identical values to database. Bug effects least all Wikipedias with Flagged revs enabled. Broken function is likely [[ https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/master/backend/FlaggedRevsStats.php#L245 | backend/FlaggedRevsStats.php:getEditReviewTimes() ]] as only `reviewLag-anon-*` and `reviewLag-user-*` values in flaggedrevs-statistics table in database are broken. Other values are correclty logged to database.
    • Task
    Page review statistics ( special:ValidationStatistics) shows number of users in "editors" user group which means that when name of the group is something different then number is 0. Same thing is with autoreviewed user count. The number what we would want to see is number of users with "review" and "autoreview" user rights which can be added by multiple different user groups. ; Example In Turkish Wikipedia review right come via patroller user group - https://tr.wikipedia.org/wiki/special:ValidationStatistics?uselang=en
    • Task
    If reviewed pages were deleted and then undeleted, then something strange happened: it is marked both as reviewed and non-reviewed. Example: https://ru.wikipedia.org/w/index.php?title=%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80_%D0%A0%D0%B0%D1%84%D0%B0%D0%B8%D0%BB%D0%BE%D0%B2%D0%B8%D1%87_%D0%9A%D0%BE%D1%80%D1%81%D1%83%D0%BD%D1%81%D0%BA%D0%B8%D0%B9&redirect=no Now this redirect page looks OK, but only after unreview and then again review action. New example: https://ru.wikipedia.org/w/index.php?title=%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B9_%D0%9C%D0%B8%D1%85%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%B8%D1%87_%D0%9F%D1%80%D0%BE%D0%BA%D0%B8%D0%BD&redirect=no The problem is that after restoring reviewed page, FlaggedRevs::newFromTitle returns NULL. I can not figure out why It is the same not only for redirects, but for all pages, in all namespaces.
    • Task
    Now that enwiki has stricter requirements for the patrol right than the autoreview right, they won't want this. Generally speaking, this feature doesn't make much sense; if it's desired we could still put it behind a feature flag.
    • Task
    Per https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes, when a user's edit is deferred actively (i.e. in such a way that it is not visible to readers), the user should be notified. The user should also be notified when their edit is accepted, but that's covered by {T54510} (see T54510#2875256 for screenshot). The implementation that's currently being worked on [[https://gerrit.wikimedia.org/r/#/c/316957|this patch]] looks like this: {F5057490} The first notification is shown for edits that were automatically deferred because they matches an AbuseFilter rule. The first secondary link ("AbuseFilter") links to a documentation page about AbuseFilter (if the edit was deferred by ORES, the first secondary link will say "ORES" and link to a documentation page about ORES), and the second one ("Help") links to a documentation page about deferred change. The second notification is shown for edits that were deferred by a bot (or human). The first secondary link is the user who deferred the edit. =New Notification Request Form= Filling out this form will help developers and product people understand your idea and will provide the information required to implement it. To see examples of the types of answers required, [[ https://www.mediawiki.org/wiki/Help:Notifications/Document_a_new_notification_type#Information_required | have a look at this sample form ]]. To understand unfamiliar terms, [[ https://www.mediawiki.org/wiki/Help:Notifications/Glossary | visit the glossary. ]] ==Basic information== - **Purpose of the notification**: Inform users that their edit has been actively deferred. - **Notification name**: Active Deferral - **What triggers notification?:** An active deferral requested via the API or by some automated process such as AbuseFilter, ORES - **"Notice" or "Alert"?: ** Alert - **Notification type (standard, bundled, expandable bundle): ** Standard ==Wording== For a single message -- **header:** Publication of your edit on Pagename was deferred, pending review. -- **body: ** Our robots found a possible problem, so a human will have a look. ==Links== - **primary link target: ** Diff of the edit(s) being deferred - **primary link label (for email display only): ** View changes - **#1 secondary link target:** Userpage of the deferring user if via API, description page of the deferring process if not - **#1 secondary link label: ** Name of the deferring user if via API, name of the deferring process if not - **#2 secondary link target:** Help page on deferred changes - **#2 secondary link label:** Help ==Icon== - **icon name: ** deferred change - **Link to graphic/example:** {F5059457} == Secondary link icon == - **icon name: ** automatic agent - **Link to graphic/example:** {F5098837}
    • Task
    Are there some special pages that are missing or need to be installed from a different extension? I cannot find the Special:RevisionReview page despite having Flagged Revisions installed. Thanks Pete
    • Task
    Global bot Xqbot which fixes double redirects stopped being flagged revs autoreviewed 21.10.2016. Bot is still autopatrolled so global bot -flag works in general. - Edits: https://fi.wikipedia.org/wiki/Toiminnot:Muokkaukset/Xqbot?uselang=en - Autoreviews: https://fi.wikipedia.org/w/index.php?title=Toiminnot%3AAdvancedReviewLog&namespace=0&level=-1&user=Xqbot&status=-1&automatic=1&uselang=en - Autopatrols: https://fi.wikipedia.org/w/index.php?title=Toiminnot%3ALoki&type=patrol&user=Xqbot&page=&year=&month=-1&tagfilter=&subtype=&uselang=en Support for global bot right was added to Flagged Rews at ticket T18792 / 2008 and local workaround is to add local bot right.
    • Task
    Reviewing a version fails if summary field is suppressed. Steps to reproduce: 1. Edit a page as IP 2. Login as administrator and suppress the summary of this revision 3. Try to review the page. Error message: "Unable to review this revision. The target revision does not exist." Testcase: https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Test&diff=16010&oldid=16009 This bug was reported from the German Wikipedia: https://de.wikipedia.org/w/index.php?title=Monica_Seles&action=history The edit on 2016-09-13 itself was good but the summary only was bad and therefore suppresssed.
    • Task
    https://tools.wmflabs.org/rightstool/cgi-bin/rightsstats * autoreview is used on 40 wikis. * autoreviewed just on mkwiki. * autoreviewer on enwiki , ptwiki, zhwiki, zh_yuewiki. We should verify whether they all refer to the same function or is an autopatrolled-like message, then rename as appropriate. As far as I can see, the autoreviewer right on enwiki is the autopatrolled one, which they didn't renamed when they dropped FlaggedRevs
    • Task
    When Special:PendingChanges is transcluded the "watched" parameter which limits the results only to the pages in watchlist doesn't work anymore. It was working at February 2015. Other parameters ("namespace", "level", "category", "size", "limit", "stable") are still working with transclusion. Wikicode example below ``` {{Special:PendingChanges |limit=10 |watched=1 }} ``` - [[ https://fi.wikipedia.org/wiki/K%C3%A4ytt%C3%A4j%C3%A4:Zache/watched-example | Example page in fiwiki ]] - [[ https://fi.wikipedia.org/w/index.php?title=Toiminnot:Odottavat_muutokset&limit=10&watched=1 | Expected result in Special:PendingChanges page ]].
    • Task
    When filtering by category, Special:UnreviewedPages, in the "next" pagination link, includes the sort key for the last title on the page as a URL encoded binary string. Because MediaWiki validates the UTF-8 sequences in, filters out certain characters from, and applies NFC normalization to all GET/POST values arriving at the web interface, this does not work correctly. **Steps to reproduce:** 1. Install FlaggedRevs. 2. Add your user account to a group that has permission to use the special page. By default, the "editor" and "reviewer" groups have permission. 3. In LocalSettings.php, set $wgCategoryCollation to "uca-en", then run maintenance/updateCollation.php --force. 4. Create "Collate test page A" and "Collate test page B" with content `[[Category:Collate test category]]`. Unaccept the revisions if necessary. 5. Go to Special:UnreviewedPages. 6. Enter "Collate test category" in the "Category:" box, then click "Go". 7. Add `&limit=1` to the URL. 8. Click "next 1". **Actual result:** Immediately after step 7, and immediately after step 8, only "Collate test page A" is listed. **Expected result:** Immediately after step 7, only "Collate test page A" is listed. Immediately after step 8, only "Collate test page B" is listed.
    • Task
    Steps to reproduce: * go to random article (I used [[https://hu.wikipedia.org/wiki/K%C3%B6ves_%C3%89va|hu:Köves Éva]]) * make an anonymous edit * view the article while logged in as a reviewer The article will show a warning saying that "Template/file changes in this version are pending review." ([[https://translatewiki.net/wiki/MediaWiki:Revreview-newest-quality-i/en|Revreview-newest-basic-i]]). The correct message would be "N changes in this version are pending review." ([[https://translatewiki.net/wiki/MediaWiki:Revreview-newest-quality-i/en|Revreview-newest-basic]]).
    • Task
    With Flagged Revisions If user without review-right is editing the page where is no pending changes then system will warn editor for his own edits when there is least one edit pending. This works in same way in old wikieditor and visual editor but problem is more pronounced in the Visual Editor. Edit warning messages: - Message 1: "The stable version was checked on 20 May 2016. There is 1 pending change awaiting review." - Message 2: "Notice: Some of the pending changes affect the area of the page you are editing. (show those changes)" {F4032868} {F4032869} How to replicate 1.) Go to page which is reviewed with FR and there is no pending changes with 2.) Edit the page with user without autoreview or review -right and save the edit 3.) Re-edit the same page Suitable test page: https://fi.wikipedia.org/wiki/Merkityt_versiot_-kokeilu/Testisivu_1 How this should work is that the warning is showed only if there is pending changes from other editors than current one. Even better would be if warning could be disabled for users without review right in cases where latest version of the article is shown. This is something which doesn't bother regular user because they are editing with least autoreview right. Problem however is annoying and it effects pretty much to all ip and new users which are doing more than one edit per article.
    • Task
    (Feel free to improve the title. I'm just reporting from de.wiki:) How to reproduce: *go to some article in which the current version is not sighted *make an edit to the article using Visual Editor, set checkmark to the option //Sichte die letzten Änderungen// and save the edit *now the message appears: //1 Änderung dieser Version ist noch nicht gesichtet//. with the diff from the last sighted to the new current version and with the button Sichten at the bottom of the page. (There should be a button //Entsichten//) *when you look at the article history (in a new browser tab) you can see that the new current version is sighted, but the second most recent version is left not sighted (well done) *click the button //Sichten// *now the second most recent version is sighted too, although we haven't seen the diff to this version, but to the new current version. And there is no need to sight the second last version. --Diwas, 00:35, 9. Mai 2016 (CEST)
    • Task
    With [[ https://en.wikipedia.org/w/index.php?title=Tor_%28anonymity_network%29&diff=716699180&oldid=716699110 | this edit ]], the user reverted their edit to the previous, reviewed version, but it was not automatically accepted. This might be because the user didn't use the "undo" feature (I'm assuming tools like Twinkle use it under the hood and just change the edit summary), but it would be nice to be able to detect this.
    • Task
    In the Hungarian Wikipedia, flagged revisions are theoretically used as a counter-vandalism tool (ie. edits should be marked as sighted if they do not contain obvious vandalism, unargued removal of facts, uncited inclusion of facts, formatting errors etc; specifically, edits should be marked as sighted even if the patroller does not have the means or expertise to verify them). In practice that does work well because of lack of capacity and because patrollers don't always follow that rule, so good edits get stuck in a pending state for a long time. If ORES proves accurate in identifying "suspicious" edits, it would be great to use it as input for flagged revisions; ie. only put edits in a pending state if ORES labels them as damaging. Potential poor man's solution: {T57081}
    • Task
    Two changes I'd like to make: a) Always use the simple "icon-based" UI for page review status and remove the preference to control with UI is used. Having some wikis use the old one and some the new one seems like technical debt, and a fair amount of code can be removed. b) Remove the logged-in/logged-out distinction that decides what version the user sees. It should always just be whatever the site/page default is (overridden only by the preference that exists already). The distinction is to artificial and unexpected (Brandon H and Howie F never liked this either).
    • Task
    Special:NewFiles has a "Hide patrolled uploads" checkbox, but that only works with normal patrolling, not FlaggedRevs. There should be an option to filter files by review status.
    • Task
    = Example = # Create a template with some content: http://de.wikipedia.beta.wmflabs.org/w/index.php?title=Vorlage:TestSichtung&oldid=13027 # Now create different content: http://de.wikipedia.beta.wmflabs.org/wiki/Vorlage:TestSichtung # Now mark everything after the first version as unmarked: http://de.wikipedia.beta.wmflabs.org/w/index.php?title=Vorlage:TestSichtung&action=history # Create now a page, where this content is used by a template transclusion: http://de.wikipedia.beta.wmflabs.org/w/index.php?title=Wikipedia:Hauptseite/Test&action=edit # And now the bug: This page shows the unmarked content, instead of the latest stable version: http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite/Test This is a problem, for example some pages at dewiki are configured with autoreview=sysop, so that content is only shown via a template to a user, if the content is reviewed. That was the intention, but since this bug, this is not possible.
    • Task
    Reviewers have to manually reaccept their edits after they revert revisions which are not final. Also, reverting earlier revisions reverts just that and accept all the others. Is that standard behaviour? I'd like to see a system where diffs can be accepted/rejected one-by-one starting from the first unreviewed diff. {F3236289}
    • Task
    When you edit a stable version of page with [[ https://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions | unreviewed changes ]] ([[ https://www.mediawiki.org/wiki/Extension:FlaggedRevs | Flagged Revisions ]]), it always overrides with those unreviewed changes, even if it's not needed. I think, if the user with an editor/reviewer rights edits the stable version, the mechanism should save his edits with this version, excluding the rest. The problem is that now if the user with those rights edits the stable version (even as a minor edit) then it saves automatically with all unreviewed changes **marked** as revieved, which is a big bug.