Special:Investigate is on thegoodplace.

Bytes with Edit Summary:

WWT link no longer appears on the preview page.

I have found a way of reproducing this issue, although it is not terribly realistic. It requires write access to the database. Therefore, I can only reproduce on my local system.

Placeholder when sending to reviewer: "Write a helpful note for $reviewer."

Before an article has been reviewed, you can only send a message to the creator (obviously).

I guess this is fine. I don't really know...

Which hooks get fired for which actions (now, on testwiki):

@ifried @MusikAnimal I have noted some potential issues below. I am sure there are more, as there are probably always going to be exceptions to any rules. It depends how fussy we want to be.

1. There are some articles in which content in tables is highlighted. For example, https://tr.wikipedia.org/wiki/Carter_Burwell?uselang=en, the bullet points are formatted using a table. They are made opaque, but they are highlighted if you hover over them. This may be true of other elements. There is probably a large number of unusually formatted wiki articles which we have not anticipated.
2. Some elements which are not highlighted are not being made opaque, for example templates when they appear in paragraphs (e.g. translation templates, unit conversion templates). E.g. "Japonca" in the first sentence here https://tr.wikipedia.org/wiki/Himiko.
3. The scope of the opacity is not always consistent. For example, in the references section of https://en.wikipedia.org/wiki/Minehunter, the numbers (and the caret) are not opaque. In other articles, (e.g. https://tr.wikipedia.org/wiki/Carter_Burwell?uselang=en) they are.

Not opaque:

4. Something weird here (https://en.wikipedia.org/wiki/Xun_Huisheng):

This looks fine to me. I am happy to move this along.

In the Chrome Store, we can now see three extra languages: "English", "português (Brasil)" and "português (Portugal)".

@Samwilson Small nitpick. We seem to be warning about descriptions that are 132 characters or greater, and truncating up to the 131st character. Should it not be strictly greater than 132 characters?

After installing it in the Firefox Add-Ons repository, the extension ID is reported as {7c53a467-2542-497a-86fb-59c2904a56d1}. @Samwilson are the curly braces intentional?

@Mooeypoo I find that, after saving in VE, WWT does not activate properly when I click the "Who Wrote That?" link.

In T233969#5696170, @Ammarpad wrote:

@dom_walden, updated to this

Much of the testing has been done as part of related bugs/tasks. There is not much else left for me to do.

@Niharika At the moment, a user will be reported as blocked even if the block is hidden (and the check user does not have rights to see hidden blocks).

@dmaza Submitting the Special:Investigate form on a wiki without CentralAuth, I see in the logs:

[error] [f7d4d69c1c92ecf5b9e28a69] /core/index.php/Special:Investigate   ErrorException from line 83 of /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php: PHP Notice: Undefined variable: globalUser
#0 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(83): MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(61): MediaWiki\CheckUser\PreliminaryCheckService->getGlobalUser(User)
#2 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(44): MediaWiki\CheckUser\PreliminaryCheckService->getAttachedWikis(User)
#3 /var/www/html/core/extensions/CheckUser/includes/specials/pagers/PreliminaryCheckPager.php(59): MediaWiki\CheckUser\PreliminaryCheckService->getPreliminaryData(array)
#4 /var/www/html/core/includes/pager/IndexPager.php(616): PreliminaryCheckPager->doQuery()
#5 /var/www/html/core/extensions/CheckUser/includes/specials/SpecialInvestigate.php(120): IndexPager->getNumRows()
#6 /var/www/html/core/includes/htmlform/HTMLForm.php(694): SpecialInvestigate->onSubmit(array, OOUIHTMLForm)
#7 /var/www/html/core/includes/htmlform/HTMLForm.php(586): HTMLForm->trySubmit()
#8 /var/www/html/core/includes/htmlform/HTMLForm.php(601): HTMLForm->tryAuthorizedSubmit()
#9 /var/www/html/core/extensions/CheckUser/includes/specials/SpecialInvestigate.php(41): HTMLForm->show()
#10 /var/www/html/core/includes/specialpage/SpecialPage.php(575): SpecialInvestigate->execute(NULL)
#11 /var/www/html/core/includes/specialpage/SpecialPageFactory.php(607): SpecialPage->run(NULL)
#12 /var/www/html/core/includes/MediaWiki.php(298): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#13 /var/www/html/core/includes/MediaWiki.php(967): MediaWiki->performRequest()
#14 /var/www/html/core/includes/MediaWiki.php(530): MediaWiki->main()
#15 /var/www/html/core/index.php(46): MediaWiki->run()
#16 {main}

Acceptance criteria

• Form header: Search for usernames, IP addresses or IP ranges
  • All three types will be added in a single text field. We should auto-complete the usernames and still allow IPs/ranges that become "capsules" once they are valid by regex. We did this with Interaction Timeline and should be able to do it here as well.

After this, the widget should:

• Show no menu if the current input is not a valid IP address/range and doesn't complete to a username (as before)

After applying patch in https://gerrit.wikimedia.org/r/552269, I am now limited to entering 2 users/IPs in the Special:Investigate form.

Acceptance criteria from T236226:

• The extension should be called "WhoWroteThat for Wikipedia (BETA)"

Acceptance Criteria:

• Release the beta extension for Chrome Web Store
• The extension should be called "WhoWroteThat for Wikipedia (BETA)"

1. Looking at the entry on the Chrome Store in English, the description includes some raw HTML: If you find any issues, please report them on <a href="https://phabricator.wikimedia.org/tag/who-wrote-that/">our Phabricator board</a>.

@Samwilson I am seeing some differences between how this appears in the Firefox Add-On repo and in the Chrome Store. For example, the name is slightly different ("Who Wrote That? (BETA)" vs. "WhoWroteThat for Wikipedia (BETA)"). Is this due to the Firefox release being slightly older?

Following the reproduction steps in the description, I can no longer reproduce the bug.

In T234483#5628182, @Mooeypoo wrote:

A followup would need to make the animation conditional so it isn't as jumpy in the cases where it shouldn't appear. I'm leaving that for the followup ticket, though: T234463: WWT: Only Show Loading Animation in Revision Details Pop-up If Data Not Yet Loaded

In T200938#5677004, @Niharika wrote:

Since it's such a narrow use case, I think it's safe to close it. Any objections?

In T205130#5584173, @Niharika wrote:

I believe all known defects with Partial blocks have been filed already. @dom_walden would you like this to be kept open?

In T238240#5664193, @dbarratt wrote:

In T238240#5664155, @dom_walden wrote:

I don't see anything currently that uses HTMLUsersMultiselectField at the moment.

I believe this is used on https://test.wikipedia.org/wiki/Special:Preferences in the "Prohibit these users from emailing me" field as well as on https://test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo in the "Do not display notifications from these users" field. I believe these fields are enabled through config (I can figure out the configs if you would like).

I don't see anything currently that uses HTMLUsersMultiselectField at the moment. I don't think there is anything for me to test until other CheckUser work is complete.

• A user without the necessary permissions sees a permission error, whether blocked or not

In T230455#5661232, @HMonroy wrote:

@dom_walden we reviewed your concern during standup and since it's not very likely to happen (it has not been reported by any user) @ifried decided that it is safe to leave it as is for now. This possible case has been there since the beginning. Thank you!

In T236702#5618179, @Prtksxna wrote:

Is this something that we get from a separate API call or do we have it as soon as the popup loads?

In T231508#5642830, @Mooeypoo wrote:

The second behavior should be fixed when https://github.com/wikimedia/WhoWroteThat/pull/80 is merged

The mobile error message drawer should be updated to handle the following situations:

1. The blocker is a local user. Link to their user page.

On Beta, testing username, IP, autoblocks and cookie blocks. The "Details" link appears and links to the correct block ID in Special:BlockList.

Tested:

• Database blocks
• Composite blocks
• $wgProxyList System Blocks
• $wgDnsBlacklistUrls System Blocks

I can no longer reproduce this following reproduction steps, on my local VM MediaWiki 1.35.0-alpha (68d87db) 04:22, 1 November 2019.

On https://en.wikipedia.beta.wmflabs.org I created a number of autoblocks with different block reasons, including templates, other forms of wikitext, HTML tags and that had no block reason.

In T231357#5625810, @MaxSem wrote:

@dom_walden, looking at the above nomination:

• Log page - not sure if edit summary was present before
• Discussion page
• Template on the page itself
• Creator notification

Templates look to be working to me.

In T232512#5624890, @ifried wrote:

@MaxSem @dom_walden I just tested this on https://en.wikipedia.beta.wmflabs.org/. It appears that the message is displayed if someone just enters a username (correct behavior). However, if someone just enters the email address, the message is not displayed (incorrect behavior). Rather, they are directed to the next screen (see below), which says, "If this email address is associated with your account, then a password reset email will be sent."

@Tchanders I am finding on beta and test that the "Details" link in mobile block messages has an empty href.

Special:CentralAuth now looks like:

@HMonroy When there is no "Articles for deletion" log for today's date (e.g. Wikipedia:Articles for deletion/Log/2019 October 30) and I attempt the AfD action, I see the Log page for today has not been created yet! popup. If I click "OK", the AfD action continues. It adds the {{afd}} template to the article and posts on the creator's user_talk page (although it does not create the deletion page Wikipedia:Articles for deletion/$article_name).

@Tchanders Testing on beta, for autoblocks the comment_text still appears to be stored in the DB in the expanded form.

@Mooeypoo The revision popup isn't working for image thumbnails for me anymore. Did work in commit a50f43374005791b7683404ea58413e81ec4279e.

@Mooeypoo After this change (which I think is this) the revision summary animation does not appear for tokens you have already clicked. Instead, you see the revision summary blinking in and out.

I used the namespace parameter to filter the results returned by the API.

Comparing my local version of InteractionTimeline running in docker with the production version, I am seeing very few differences except the content being narrower.

I have been able to run this locally with docker. I guess that means it is ok.

For 3 users who all have the same email.

The password reset email now looks like (on Gmail's web client):

@HMonroy Just checking, because I didn't explain it very clearly in T230455#5541869, have you also investigated the weird behaviour where the articleinfo hook gets fired when you review/unreview, but only after first opening the "Page info" flyout?

A user who is "Account is hidden from the global users list" does not appear in Special:GlobalUsers, but the user is not blocked from doing anything.

It should be noted that DatabaseBlock::newFromTarget (used here) chooses the most specific IP block. Blocking an IP range from creating accounts might not have the desired affect if there are more specific IP blocks which allow account creation. This is only in the case of wanting to block admins from creating accounts, which we may not want to do in the first place (as mentioned above).

Comparing https://en.wikipedia.beta.wmflabs.org to https://test.wikipedia.org.

A loading animation now appears in the revision details popup, regardless of whether there is an edit summary associated with the revision.

We now show the contributor name or IP in the infobar.

Block error message for Special:EmailUser now looks ok for composite blocks, including in non-default language (French).

In T234874#5554160, @Mooeypoo wrote:

For testing, you can now use, in the console:

wwtDebug.launch();
wwtDebug.dismiss();

In T231508#5605714, @dom_walden wrote:

@MusikAnimal If you go directly to the VisualEditor (e.g. https://tr.wikipedia.org/w/index.php?title=%C4%B0Pad_Mini_4&veaction=edit), the "Who Wrote That?" link appears briefly and the guided tour popup appears and remains (unless you have previously dismissed it).
In the brief period in which the "Who Wrote That?" link appears, if you are quick enough you can click it and have the infobar appear. Leaves it in a weird state where model.enabled == false but model.active == true. This does not appear to interfere with VisualEditor.
I don't see these problems when I go first to the article and then click "Edit".

@MusikAnimal If you go directly to the VisualEditor (e.g. https://tr.wikipedia.org/w/index.php?title=%C4%B0Pad_Mini_4&veaction=edit), the "Who Wrote That?" link appears briefly and the guided tour popup appears and remains (unless you have previously dismissed it).

@MusikAnimal @ifried If the edit has no edit summary, do we still want to show the bytes difference? We did before

As part of T227007#5598774 I tested how block error messages look in most of the places in the code that we changed, including in different languages. Missing, I think, SpecialRevisionDelete and SpecialUserrights.

In T227007#5598814, @Daimona wrote:

In T227007#5598774, @dom_walden wrote:

Note that I was unable to get the block action working for the AbuseFilter extension.

Happy to help! What exactly didn't work?

It should be noted that in block messages now the name of the target of the block and the blocker are surrounded by \u202a and \u202c, which I believe are for bidirectional support (e.g. see https://en.wikipedia.org/wiki/Unicode_control_characters#Bidirectional_text_control and https://en.wikipedia.org/wiki/Bi-directional_text#Table_of_possible_BiDi_character_types).

In T227007#5594595, @dom_walden wrote:

We have made a change to how we get and set block reasons. Therefore, I tried to test as many places where blocks get created or displayed, comparing beta with test (before the train, that is) or on my local environment (where I don't have permission on beta).

@Tchanders On beta, with an autoblock like so:

In T231357#5578946, @MaxSem wrote:

Production templates are already prepared.

@Tchanders On beta (1.35.0-alpha (c35f385) 06:57, 21 October 2019), attempting to create a block (happens on submit):

In T235906#5587865, @JHedden wrote:

@dom_walden I verified that your account is now working again, please let us know if you're still unable to connect to the replica databases.

• CheckUser is installed and running on thegoodplace wiki.

Retested on https://commons.wikimedia.beta.wmflabs.org and https://wikidata.beta.wmflabs.org.

The problem in the description no longer occurs.

Acceptance Criteria:

• Always display an integer value for percentage of page written by author (within the revision details pop-up)

In T234483#5567101, @ifried wrote:

3. The user clicks on 'Who Wrote That?' link to load it again