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

I see in the API calls any spaces at the start or end of input being removed.

The change appears to be functionally equivalent to what we had before.

I am blocked from https://wikidata.beta.wmflabs.org/wiki/Special:NewLexeme even if I am only partially blocked.

SVGTranslate appears to still be working :). I am able to download, login, upload, switch translation, switch preferred language and search. I have not seen any JS errors in the browser console.

The problematic URL:
https://tools.wmflabs.org/svgtranslate/login?callback=http%3A%2F%2Ftools.wmflabs.org%2Fsvgtranslate%2Foauth_callback%3Fredirect%3Dhttp%3A%2F%2Ftools.wmflabs.org%2Fsvgtranslate%2FFile%3ACloud_types_en.svg

I can access and submit the Special:NewItem and Special:NewProperty forms unless I am partially blocked from the Main or Property namespace (resp.)

I could not reproduce on Firefox, Chromium, IE11 or Safari 11.

In T207452#5412046, @ifried wrote:

...Does clicking on the other icon (i.e. the count of potential issues) result in opening the "Page Info" flyout?

I was successful following the instructions above.

I also have not been able to reproduce this bug on Production.

When the article's Talk page has an edit(s) with the tag "pagetriage"[1] the mail icon appears in the toolbar, with a count.

• Turn on the bot and make sure:
  • The text is all in Persian.

Without JS, it is not longer required to enter a value into the "Other" field (unless the "Other" dropdown is selected).

I used a script to load in SVGTranslate the most recent 500 images (of any type) uploaded to commons and check the error message that was returned.

In T229779#5394995, @ifried wrote:

@dom_walden When this work is released to beta, can you verify that it's working as expected? Thank you!

In T224468#5394268, @dmaza wrote:

@dom_walden can you confirm that the issue is fixed tho? (Block list and log incorrectly report "cannot edit own talk page" for some blocks) I'll take a look at how the form displays the errors anyway

@dmaza Would it be better if the error message appeared underneath the "Editing their own talk page" checkbox?

I am no longer able to reproduce this bug using the steps in T223769#5373460, on Chromium 73 and Safari 12.1.

@Samwilson The other login link you see when logged out ("Log in to enable uploading") still links to https://tools.wmflabs.org/svgtranslate-test/login. Does that need to be changed as well?

Concentrating on $wgAutopromote and $wgAutopromoteOnce.

In T216245#5387071, @Niharika wrote:

I am not sure what is actually the expected behavior. Should autoblocks even be spread when opening the editor? If so, we might need a separate API action for doing that… (in VE we can add that code to action=visualeditor, but this doesn't fix the issue for mobile wikitext editor). Or maybe action=query&prop=revisions should also spread autoblocks?

What's the case for the classic editors at the moment? I think that they don't spread the block when the editor is opened, is that correct?

A similar thing happens for the 'patrol' action (e.g. you can use pagetriage to mark a page as reviewed even if you have two sitewide blocks against you).

In T226789#5341543, @dom_walden wrote:

We are only missing the tag being added to entries in the Potential copyright violation log. I am not sure if this matters, but will raise a separate bug.

In T228736#5372919, @dbarratt wrote:

In T228736#5370925, @dom_walden wrote:

The only thing I notice is that the order of "Details" and "OK" are incorrect (compared to how they were previously). If you like, I can just raise a separate bug for this.

Please. :)

In T228534#5354883, @Tchanders wrote:

	Not blocked	Partially blocked	Sitewide blocked
beaurocrat	Success	Success	Success
sysop	Success	Blocked error	Blocked error

In T216245#5368871, @Ryasmeen wrote:

@dom_walden: Is it working for you now? :)

In T228736#5368856, @Ryasmeen wrote:

@dom_walden: Could you check if the fix is working for you?

Did a variety of actions:

• Review and unreview
• Send message to creator
• Add a tag
• Mark for deletion (speedy and proposed)

I can reproduce this by creating a GlobalBlock of an IP range via the API.

Testing on my local environment, adding scores directly into the ores_classification table. I can see the tags 'Attack', 'Spam' or 'Vandalism' appear in the "Page info" as appropriate.

A user's current translations are cached in the browser until they:

• Open another SVG (this is new),
• Start editing a translation in another tab, or
• Switch to another translation (in some circumstances; we do warn users of this)

Tested various combinations of database and system blocks. Behaviour is as Thalia describes above (T212326#5322341).

On Special:Block, I changed the target back and forth between username, ip and range so different checkboxes became enabled/disabled, making sure the previous state was preserved.

I tested that I could submit sitewide blocks and partial blocks with and without namespace restrictions. Both with and without JS.

Special:Mute adds and removes from the user_properties table (also visible in Special:Preferences#mw-prefsection-echo).

Oh, you do also see the Special:Mute link on your own user, user_talk, etc., pages, taking you to Special:Mute for your own user. I don't know what happens when you mute yourself. Not sure if this is a problem.

On the side rail, I see the link for Special:Mute/$user on:

• User:$user
• User_talk:$user
• Special:Contributions/$user
• Special:Block/$user
• Special:CentralAuth?target=$user

On the test environment, I can generate and view the epub in the reproduction steps. The problematic SVG displays.

Sorry, moving back as I missed something.

In T226789#5341909, @DannyS712 wrote:

... Also, since (as far as I can tell) the log is only interacted with through the api, it appears that the tag is indeed added (see the logActivity function) but there simply haven't been any entries created since the patch was merged. If you want to give User:DannyS712 (on the beta cluster) copyvio-bot rights, I can test it out.

The 'pagetriage' tag is added when...

With javascript disabled, I am only allowed to enter numbers of valid namespace. I checked that this included both the hardcoded/default namespaces and custom namespaces.

Using MessagePoster I was allowed to add a tags parameter to api.php?action=edit, which tags the edit (like so). The other POST parameters were the same as before. The parameter is optional; without it the POST is the same as before.

In T228021#5335585, @greg wrote:

What is your wikitech.wm.o username?

In T227218#5326919, @Niharika wrote:

Yeah, I'd like to keep this in Dom's column until it has been tested - whether on Beta or in Prod. I believe it went out with the train today.

• When user hits Mark as reviewed, that only marks the page as reviewed and does not send message to creator.

In T227167#5326927, @Niharika wrote:

@dom_walden Just to clarify - the beta has the generic message in your screenshot above - shouldn't it be the other way around? Beta should be running the more recent code.

In T224245#5315324, @dbarratt wrote:

@dom_walden Does the state (when loading the Special:Mute page or via the API) reflect what it should? (i.e. if it's globally set to true but locally set to false does it display as true?)

Concentrating on Special:Mute and email-blacklist option.

In T225686#5294833, @Samwilson wrote:

...The book Les_Merveilles_de_la_science still doesn't work though, because it times out; that's better than failing I guess.

Actual:

• You are allowed to progress to the editor. If you attempt to save an edit, you will see a generic error, with no block details

I have only been able to reproduce this when I:
a) am already on the edit page when my user is blocked, or
b) have unsaved edits

In T227218#5304506, @MusikAnimal wrote:

Actually, there's no way to QA this unless you simulate the copyvio locally by adding the tag manually in the database. See T207847#5297073

Cannot reproduce on Firefox, Chromium, IE11 or Safari.

In T226790#5294836, @Samwilson wrote:

This is merged and on the staging site. There's no real QA required other than keeping an eye out for anything completely not working any more. There may be some changes in error display for some types of error.

The email footer now appears fine for me. Including with RTL usernames (converting the username to url encoded hexadecimal in the Special:Mute link).

In T225293#5293485, @MaxSem wrote:

They look fine to me :O

@HMonroy After checking out your patch, when I click the "Mark as reviewed" button it becomes disabled and there is a little spinner, but nothing happens (in the UI) after this to indicate the action has been successful (which it has).

In T225293#5291134, @MaxSem wrote:

@dom_walden, please poke me next time it malfunctions, I'll try debugging it live. Moving it from the kanban board until then.

@dmaza The email footer I see now (in my MUA at least) is: To manage email preferences for Steve please visit <http://192.168.122.72/T218265/index.php/Special:Mute/Steve>.

@dbarratt @Krinkle I notice that if $wgBlockDisablesLogin = true and the user's IP is blocked (but not the username) they are prevented from sending emails, even if the IP block does not apply to emails.

No QA involvement in this. Moving this on.

Issue in T225919#5272162 no longer reproducible.

Retested briefly on beta with Firefox, Safari and IE11. This looks fine.

There is nothing more I want to do with this.

In T208685#5267807, @dom_walden wrote:

Just waiting for the above patch to be +2ed before moving this out of QA.

I notice on test.wikipedia.org, when there is a composite block blocking email, Special:EmailUser includes: "Block ID #".

In T166337#5265534, @Andrew wrote:

There are files in /tmp/calibre_2.75.1_tmp_imITvt on tools-sgewebgrid-lighttpd-0921.tools.eqiad.wmflabs but it looks like they're being actively created/deleted so that's maybe fine... I don't see /tmp litter on other hosts.

I checked that:
+ Marking a page with "Speedy deletion" or "Proposed deletion" will mark it as Unreviewed (or keep it marked Unreviewed if it was previously Unreviewed).
+ Marking a page with "Articles for deletion" will mark it as Reviewed (or keep it marked Reviewed it if was previously Reviewed).

I am in the process of testing this, and so far so good. The issue raised in T225872 (user block cookies) no longer occurs. Nor does its counterpart for IP block cookies.

@Andrew I don't think I have access to any of the lighttpd nodes. Would you be able to check that there are no old files belonging to tools.wsexport-test in /tmp, please?

I have not been able to reproduce this problem.

In T207439#5260007, @MusikAnimal wrote:

I was not able to reproduce this problem. I tried in Firefox and Chromium. Could someone else confirm?

Looks fine on https://eventmetrics-dev.wmflabs.org

Generating random combinations of blocks including:
+ Username, IP and IP ranges, autoblocks
+ System blocks (e.g. $wgProxyList, $wgDnsBlacklistUrls, $wgApplyIpBlocksToXff, Tor)
+ Global blocks
+ Blocks set from cookies
and testing different actions anonymously and while logged in (e.g. editing, account creation, sending email).

Testing IP and Autoblock cookies locally, looking at:
+ Does the cookie get set at the right time?
+ Do the cookies get cleared at the right time?
+ Is the block applied correctly from the cookie?

Sorry, wrong task.

Are we fixing the mobile message in this bug?

I don't see the link when I am an anonymous user or a non-admin user. I do when I am logged in as an admin.

For a redirect that has been created either as a result of a page move or someone adding "#REDIRECT [[other_page]]".

• T223667 - XTools - @MusikAnimal
• T219328 - Event Metrics - @MaxSem

Had their own tickets. Did not go into QA.