For hidden contributors, the revision details popup now looks like:

With my Admin user ("Dom walden") on both https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page and https://test.wikipedia.org/wiki/Main_Page I cannot see the "Add to the New Pages Feed" link.

On beta, using the API I am able to enqueue pages in the Article, User and Draft namespaces. These are the only supported namespaces on beta.

Using the API, I cannot requeue pages in the Article, User or Draft namespaces that are already in the queue.

I am not sure I can do much here to test this. However, as I tested T232512 and PasswordReset appears to be working fine, I am going to say this task is OK as well.

Acceptance Criteria:

• If a user attempts to enter information in one field (i.e. username or email address) rather than both fields when the password reset preference is enabled for the associated account, a message should appear at the top of the page: "Both username and email address are required to receive a temporary password via email."

Comparing the headers returned by https://en.wikipedia.beta.wmflabs.org and http://test.wikipedia.org/ for as many pages as I could find (mostly special pages).

In T233594#5556842, @dbarratt wrote:

It looks like instances of RedirectSpecialPage and ActionRaw are not getting the block cookies. For RedirectSpecialPage I'm not sure this is an issue because the user will get the cookies after the redirect is complete...

In T233594#5555856, @dbarratt wrote:

In T233594#5555784, @dom_walden wrote:

For logged in users with autoblocks against their accounts

Is the block against the user or against the IP address? I was under the impression that logging in would bypass the autoblock (unless your user account is the target of the block).

@Krinkle @Tchanders @dbarratt For logged in users with autoblocks against their accounts, I think there are a few places we are missing setting block cookies:

• Special:AllMyUploads
• Special:MyContributions
• Special:MyLanguage
• Special:MyTalk
• Special:MyPage
• action=raw

@MaxSem I cannot get this to work on beta for Miscellany for Deletion (for User namespace pages).

The new checkbox appears in Special:Preferences in https://en.wikipedia.beta.wmflabs.org.

In T231577#5548110, @Niharika wrote:

Oh I meant on https://commons.wikimedia.beta.wmflabs.org and https://wikidata.beta.wmflabs.org/

@Krinkle After this change, on my local machine I am seeing more pages return Cache-Control: no-cache, no-store, max-age=0, must-revalidate (where before they would return something like private, must-revalidate, max-age=0).

Which hooks get fired for which actions:

In T233164#5539298, @ifried wrote:

Great, thanks for the update, @HMonroy! I'm tagging @dom_walden, so he's aware of the status as well.

Testing on:

• https://nl.wikipedia.beta.wmflabs.org MediaWiki 1.34.0-alpha (0174952) 1 okt 2019 10:34
• https://test.wikipedia.org MediaWiki 1.34.0-wmf.24 (9d74db9) 17:04, 25 September 2019

In T232093#5495779, @dom_walden wrote:

This suggests to me that perhaps the problem is the missing metadata. I have tried to find pages in the queue with missing metadata, but have yet to be able to reproduce the problem.

Now, when enqueuing an article (clicking Add to the New Pages Feed), in Special:Log we log the fact that the article's state is unreviewed:

In T231595#5523040, @ifried wrote:

@dom_walden & @Samwilson:
When I tested links in templates, they seemed to (at least sometimes) still work. For example, on this page (https://en.wikipedia.org/wiki/SOLRAD_2). I clicked on " Solar X-Ray," and I was redirected to the https://en.wikipedia.org/wiki/X-ray_astronomy#Stellar_X-ray_astronomy. Was this because it was not only a new page, but it was also a jump within the page (so perhaps the code didn't recognize it in the same way)?

In T232460#5510255, @Mooeypoo wrote:

@dom_walden I just re-tested this in an effort to figure out what's going on, and I can no longer reproduce it...
Can you retest? I tested both the extension and user script.

@MusikAnimal @Mooeypoo There is an odd behaviour I cannot understand. After opening the "Page info" flyout the articleinfo hook fires, which is fine. But afterwards, each time I mark the page reviewed/unreviewed (without refreshing), the articleinfo hook also fires. First time once, second time twice, third time 4 times, then 8, etc.

A particularly bad example is the link [[Olympia]] in the fourth sentence here: https://tr.wikipedia.org/w/index.php?title=%C3%89douard_Manet. In the revision details we attribute that link to a revision which does not even include the word "Olympia".

Acceptance Criteria:

• Links in the article content should not work (i.e. they do not redirect users to other pages)
• Links in the templates should not work (i.e. they do not redirect users to other pages)

Wrapping looks good for IPv6 and long usernames as well.

As Sam has tested the import script in T226070#5466961, and the latest patch only affects import, there is no more testing I can think of doing.

@ifried Are you using the gadget? I was using the extension. I tried briefly with the gadget, but could not reproduce either.

The edit summary and number of bytes changed is now shown in the Revision Details Popup.

Also, I am not sure what happens when we hit WikiWho API's request limit. From https://api.wikiwho.net/:

Currently, there is a limit of 2000 requests/day for unregistered users, and also a 60 requests/minute limit for all users.

Bug in description no longer appears to occurs.

Acceptance Criteria:

• Create a new section entitled "Date range" (in bold) in the filters view, which should appear below "Potential Issues"

One other error condition I have seen is where WhoColor identifies a revision as vandalism, returning a 200 response with payload like:

{
info: Requested revision (777478614) is detected as vandalism by WikiWho.
success: false
...
}

Now both the badges for number of possible issues and the number of previous comments don't get in the way of the Page info icon.

In T232093#5494588, @DannyS712 wrote:

Okay, so I did some debugging:
Steps to reproduce: sort by oldest first in the feed, view the oldest, and try to advance

There does not appear to be any testing necessary for this task on its own.

I have briefly retested some blocking functionality, just in case regressions have been introduced.

Admin (who has blocked themself) can delete and undelete revisions via Special:RevisionDelete if partially blocked.

I tested closing from the sidebar and from the Infobar on Firefox 60, Chromium 73 and Safari 12.

In T207485#5335656, @kaldari wrote:

@Niharika, @Mooeypoo - Note that at one point there was a cron-jobbed maintenance script (updatePageTriageQueue.php) running on the production servers that automatically removed any pages from the pagetriage_page table...

Special:EditTags (or the action=editchangetags from the revision history page)

• Can add tags to revisions of pages unless blocked from that page or its namespace
• If sitewide blocked, cannot tag a revision unless it is of user's own User_talk (and user is not blocked from latter)

In T231417#5481365, @ifried wrote:

@dom_walden I was able to reproduce the bug on English Wikipedia. Should I be testing on some other environment?

I am seeing a difference in how popups position themselves on the page, possibly related to this change.

I can no longer reproduce the original bug, even if closing and opening the tool multiple times.

In T226761#5445055, @dom_walden wrote:

• The "Who Wrote That" link should be the last in the order of tools (i.e. do not change the current order)

Except on https://tr.wikipedia.org/wiki/, where it is second last...
...Do we mind?

Requirements:

• Add a Guided tour style pop-up (first-time use only until dismissal)
• The pop-up should appear after the extension is installed
• Include the following header text in the pop-up: "Who Wrote That? installed!"

I tested calling php maintenance/importImages.php from the command-line with the --check-userblock parameter (which tells it to check if the user is blocked) and --user $user, where $user had a variety of blocks.

Checking out the WIP patches from T200938, after this change blocks including the Main namespace are displayed in Special:CentralAuth as a separate bullet point (Main).

IP addresses display correctly in the revision details popup. The "talk" and "contribs" links are correct.

Acceptance Criteria:

• When WWT is activated, disable all links in the content area.

Regression (testing changes made to AbstractBlock and DatabaseBlock):

• Can create a hidden block, gets applied to user correctly when editing an article.

Also affects Category tags.

I believe this is due to this bug I raised: https://github.com/wikiwho/WhoColor/issues/17

It also appears to affect Category tags (bottom of https://de.wikipedia.org/w/index.php?title=Totem_Pole_(Monument_Valley)&oldid=191968433, #token-1797).

In T229692#5462539, @Niharika wrote:

Thanks @dom_walden for explaining. I agree that it seems like we have fixed a bug here. I think we should make a note that we found the behavior wasn't as expected and we fixed it with this ticket on the extension talk page (https://www.mediawiki.org/wiki/Extension_talk:TorBlock) so third party users who might be active there can see it.

In T229692#5459379, @Tchanders wrote:

But, it will change the behaviour of default installs.

@dom_walden It was our intention to keep the conditions for removing a block the same with this patch (so IP blocks are removed because they were removed before). Is there something that we've inadvertently changed?

• The text (in white) should read (as default) "API Error: Please refresh the page or try again later."
• For 200 OK, the text should read: "API Error: Please try again later."

By setting $wgTorDisableAdminBlocks = true (which is default), any IP blocks that coincide with Tor exit nodes will not get applied, including System blocks.

If a user is hidden via Special:CentralAuth, any blocks they have (unless they are hidden blocks) will be overridden by a system block.

Good catch.

The changes above bring copyright violation logging in alignment with how we log other PageTriage actions.

Testing on Firefox 60, Safari 12 and IE11, Sam's latest patch looks fine. If you click on the part of the mail icon which overlaps the round "i" button will open the "Page Info" flyout.

• Query the WhoColor API for the new DOM (marked up)

Requirement:
• Add a link/button to toggle WhoWroteThat view on/off on the sidebar, under "Tools"

Expiry date of block cookies (when looked at in the browser) is the same as the blocks expiry date (after normalising the timezone).

In T207893#5431725, @WMDE-leszek wrote:

thanks @dom_walden ! So are we fine to conclude this is now resolved?

If I attempt to modify a block cookie (e.g. changing the hash value, block id, invalid format) it gets cleared when I attempt to edit a page (either using VisualEditor or source editor) or create an account.

In T207893#5429435, @dbarratt wrote:

Oversight on my part, it looks like the creation code (in both patches) is using AbstractBlock::isSitewide() instead of AbstractBlock::appliesToNamespace() (as is outlined in the task description). Using the former means that someone who is blocked from a namespace will be allowed to create an item in that namespace, using the latter will ensure they are blocked properly from that namespace.

When I submit the Special:Mute page on beta, on deployment-eventlog05.deployment-prep.eqiad.wmflabs I see the event logged in /srv/log/eventlogging/all-events.log as:

{
  "dt": "2019-08-21T15:27:53Z",
  "event": {
    "emailsAfter": true,
    "emailsBefore": false,
    "notificationsAfter": true,
    "notificationsBefore": false
  },
  "ip": "172.16.4.119",
  "recvFrom": "deployment-cache-text05.deployment-prep.eqiad.wmflabs",
  "revision": 19265572,
  "schema": "SpecialMuteSubmit",
  "seqId": 6204900,
  "userAgent": {
    "browser_family": "Firefox",
    "browser_major": "60",
    "browser_minor": "0",
    "device_family": "Other",
    "is_bot": false,
    "is_mediawiki": false,
    "os_family": "Linux",
    "os_major": null,
    "os_minor": null,
    "wmf_app_version": "-"
  },
  "uuid": "d52b1f9858bf5ff59e00d58f151cee20",
  "webHost": "en.wikipedia.beta.wmflabs.org",
  "wiki": "enwiki"
}

Requirements:

• When WWT is activated, a blue information bar should appear at the top of the article.
• The information bar should be displayed below the links ("Read," "Edit," "View History," "Article," or "Talk") and above the article title.

Testing on https://en.wikipedia.beta.wmflabs.org/wiki/

On wsexport-test, I created a number of pdf/epubs/etc. and saw the statistics rise as appropriate.

Might this be another example of the issue discussed in this bug T216283#5133746?