Thu, Aug 15
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.
Wed, Aug 14
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:
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.
Tue, Aug 13
I was successful following the instructions above.
Mon, Aug 12
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" the mail icon appears in the toolbar, with a count.
Thu, Aug 8
- 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).
Wed, Aug 7
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.
Mon, Aug 5
@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.
Fri, Aug 2
Thu, Aug 1
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).
Wed, Jul 31
Mon, Jul 29
Sat, Jul 27
Fri, Jul 26
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)
Wed, Jul 24
Tested various combinations of database and system blocks. Behaviour is as Thalia describes above (T212326#5322341).
Tue, Jul 23
Mon, Jul 22
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.
Sun, Jul 21
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:
Jul 19 2019
On the test environment, I can generate and view the epub in the reproduction steps. The problematic SVG displays.
Jul 17 2019
Sorry, moving back as I missed something.
The 'pagetriage' tag is added when...
Jul 16 2019
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.
Jul 15 2019
- When user hits Mark as reviewed, that only marks the page as reviewed and does not send message to creator.
Jul 14 2019
Jul 12 2019
Jul 9 2019
Jul 8 2019
Concentrating on Special:Mute and email-blacklist option.
Jul 5 2019
- 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
Jul 3 2019
Cannot reproduce on Firefox, Chromium, IE11 or Safari.
Jun 29 2019
The email footer now appears fine for me. Including with RTL usernames (converting the username to url encoded hexadecimal in the Special:Mute link).
Jun 28 2019
@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).
Jun 27 2019
Jun 25 2019
@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.
Jun 24 2019
No QA involvement in this. Moving this on.
Issue in T225919#5272162 no longer reproducible.
Jun 21 2019
Retested briefly on beta with Firefox, Safari and IE11. This looks fine.
There is nothing more I want to do with this.
Jun 20 2019
I notice on test.wikipedia.org, when there is a composite block blocking email, Special:EmailUser includes: "Block ID #".
Jun 19 2019
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).
Jun 18 2019
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.
Looks fine on https://eventmetrics-dev.wmflabs.org
Jun 17 2019
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?
Jun 12 2019
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.
Jun 11 2019
For a redirect that has been created either as a result of a page move or someone adding "#REDIRECT [[other_page]]".
Had their own tickets. Did not go into QA.