Part of T211038: Create integration/edge-to-edge ensuring blocked users cannot edit Wikibase entities but for the special pages.
Special pages:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Addshore | T211038 Create integration/edge-to-edge ensuring blocked users cannot edit Wikibase entities | |||
| Resolved | Addshore | T211120 Create integration/edge-to-edge ensuring blocked users cannot edit Wikibase entities via Special Pages |
Note: users can block and unblock themselves (I just tested it on my local wiki), so we should be able to test this using the regular test account, assuming that’s an admin. (To be safe, make the block expire soon, so that we don’t leave an indefinitely blocked user behind if a test fails.)
Change 477825 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Add browser test for special pages with blocked users
Change 478019 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Check permissions and blocked in MergeItems and RedirectEntity
Moving to Review column, because the first two patches are ready for review, I think. The third part will have to wait for the wdio-wikibase package to be extracted (T200011).
Change 478019 merged by Michael Große:
[mediawiki/extensions/Wikibase@master] Check permissions and blocked in MergeItems and RedirectEntity
Change 477825 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add browser test for special pages with blocked users
Apparently we decided at some point that these tests should only run on the nightly browser tests, not in regular CI runs. Does anyone remember why? They don’t take particularly long, if I interpret the gate-and-submit CI output correctly (less than ten seconds).
I believe the point of running those not per-commit, but say once a day was brought as the counterweight to a possible concern that having additional browser tests will lead to siginificant slow down of per-change CI jobs.
If this is not the case at this point, I guess it doesn't make sense to build additional browser test infrastructure.
sure, go ahead (probably needs at least three patches, one to make one of the lexeme special pages – don’t remember which – check the “blocked” status on load, just like here, and then one to move the relevant code in Wikibase into the npm module and one in WikibaseLexeme to load it from there and add the tests)
Note: users can block and unblock themselves (I just tested it on my local wiki)
Side note: I was worried that this might just be an unintended weird edge case, but apparently it’s intentional and we can rely on it staying that way, per T150826:
Self-blocks (e.g. User:AdminApples blocks User:AdminApples) have always been able to (and will continue to be able to) unblock themselves.
Change 483075 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/WikibaseLexeme@master] Check if user blocked on Special:MergeLexemes Load
Change 483075 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Check if user blocked on Special:MergeLexemes Load