Also make sure @Catrope is a member of the project
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Mattflaschen-WMF | T152443 Set up test instance for Deferred Changes | |||
| Resolved | • Mattflaschen-WMF | T152584 Add Vagrant role for FlaggedRevs |
Event Timeline
Comment Actions
I'm up to #11 of https://wikitech.wikimedia.org/wiki/Help:MediaWiki-Vagrant_in_Labs#Setting_up_your_instance_with_MediaWiki-Vagrant .
It's weird, though, my new proxy shows as:
deferred-changes.wmflabs.org http://10.68.22.160:8080
even though the backend is just a drop-down. All the others show the backend with a text host name.
It says at https://wikitech.wikimedia.org/wiki/Help:Proxy that DNS takes 30-60 minutes to propagate, and that we need to manually change security groups. I don't remember this being the case before, maybe it's only if you don't choose 'web'.
It should be available at http://deferred-changes.wmflabs.org/ at some point, then I just need to change the password.
Comment Actions
People can use https://www.mediawiki.org/wiki/Manual:CreateAndPromote.php to create users for themselves (I did change the password, since it's a public site).
Comment Actions
Thanks Matt! I've registered as Quiddity, please give that account bcrat so I can op people as needed.
I've added the relevant links to the main page, ready for when flaggedrevs is enabled. (Hopefully I understood the situation correctly :)
(For Cenarium's benefit, I'll note Matt is not working today and part of tomorrow.]
Comment Actions
I created a sysop+bcrat account for myself, and then made you sysop+bcrat too.
I've added the relevant links to the main page, ready for when flaggedrevs is enabled. (Hopefully I understood the situation correctly :)
Yes you did, FlaggedRevs is not installed yet. No extensions are, actually. I'll use vagrant roles to install a few common ones, but there's no role for FlaggedRevs so I'll have to install that manually.
Comment Actions
This looks great, I've made an account there too (Cenarium).
For the configuration, we may add this to local settings:
$wgFlaggedRevsDeferral = true; $wgGroupPermissions['sysop']['review'] = true; $wgGroupPermissions['reviewer']['defer'] = true; // so reviewers can test the defer API $wgGroupPermissions['*']['abusefilter-view'] = true; $wgGroupPermissions['*']['abusefilter-log'] = true; $wgGroupPermissions['sysop']['abusefilter-log-detail'] = true; $wgGroupPermissions['sysop']['abusefilter-modify'] = true; $wgAbuseFilterEmergencyDisableCount['default'] = 200000000; // to disable the emergency threshold
We can also test with $wgFlaggedRevsProtection = false at some point, as both cases need testing.
(side note: there's currently a bug in contributions due to https://gerrit.wikimedia.org/r/#/c/325169)
Comment Actions
All done.
I enabled both protection and deferral in the FlaggedRevs config, and I created four example pages:
- Test BLP page is protected with the equivalent of PC1: edits by non-autoconfirmed users are not shown until reviewed. I also edited the page as an anon to demonstrate this.
- Test deferred page has an anon edit that has been actively deferred.
- Test deferred page 2 has two edits by a non-autoconfirmed user that have been actively deferred.
- Test passive deferred has an edit by a non-autoconfirmed user that has been passively deferred.
Feel free to create more, knock yourselves out, but please leave these four alone for the time being.
For a complete picture, also view these pages when logged out (or from an incognito window): you'll see that actively deferred edits are not displayed to anons (though you can click "Pending changes" to see them), but are displayed to reviewers.
I've also installed Echo, to demonstrate the notifications that users get when their edit is actively deferred. You can log in as "Noob user" with the password "noobnoob" to see the notification this user got when their edits to "Test deferred page 2" were deferred. There are currently no notifications when an edit is reviewed; there's a patch for this, but it doesn't cherry-pick cleanly on top of the deferred changes change.
If you're going to do your own testing, here are a few things you should know:
- If you need a non-autoconfirmed user, feel free to create a new one
- All users can use Special:Userrights to add themselves to the following groups:
- Confirmed: causes you to be treated as autoconfirmed
- Reviewers: gives you the right to review changes
- Bots: gives you the right to passively defer changes (see instructions below)
- Rollbacker: gives you the right to actively defer changes (you must also be in the Bots group)
- If you want to defer an edit, you need to do that through the API (because it's meant to be for bots). Here's the easiest way to do that:
- Go to Special:ApiSandbox#action=defer
- Click "action=defer" in the side bar on the left-hand side
- Fill out the form:
- title: The name of the page you want to defer edits on
- pageid: Leave blank
- user: The name of the user whose edits you want to defer
- override: If you want to defer passively, leave this disabled. If you want to defer actively, enable this. (Remember to give yourself sufficient rights, see above.)
- comment: The reason for the deferral to put in the log (optional)
- token: Click the black inward-pointing triangle on the right-hand side of the text box, and it should fill itself with gibberish
- Click the blue "Make request" button on the top right
- If you don't see an error message and instead see a summary of the values you entered, the edit was successfully deferred. You can verify by looking at the history of the target page: the deferred edits should stand apart from the others, and be marked in red.
@Cenarium: How does deferring from AbuseFilter work? I installed AbuseFilter because I figured we'd want to test with it, but do I need to run a patched version of it or do something else special?
Comment Actions
@Catrope: There is no need to patch AbuseFilter, this is handled from FlaggedRevs. You can create an abuse filter and you will notice two new actions to defer passively or actively.
Comment Actions
@Catrope: I couldn't change my userrights. Also, could I have admin so I can create abuse filters to demonstrate?
Then, I think we may invite enwiki users to help in testing. May I also have crat to give admin to enwiki admins?
Comment Actions
Also, maybe I can rebase the deferred changes patch on top of the review notification patch?
Comment Actions
I don't know how to fix this part.
Also, could I have admin so I can create abuse filters to demonstrate?
Then, I think we may invite enwiki users to help in testing. May I also have crat to give admin to enwiki admins?
Done and done.
Comment Actions
Thanks Quiddity.
Also, you shouldn't give 'abusefilter-private' to admins, this reveals IP addresses.
Comment Actions
If you could, yes please. The conflicts didn't look terrible, but they were over my head.
It seems like all IP edits come from 10.3.0.1 anyway, but I've revoked this right just in case.
This seems to be due to a recent regression in Special:Userrights, probably from rMWd87a4eaa19aa: Allow all users to view Special:UserRights, I'm debugging this now.
Comment Actions
Looks like it was fixed in MW core since then, and I just needed to run git pull. Every user should now actually be able to add themselves to those groups.
Comment Actions
I wrote a role for that (T152584). It's up for review, and checked out on the test instance (you can also use username Reviewer, password vagrant, from the role)