Page MenuHomeMiraheze

All The Tropes admins have lost page protection functionality
Closed, InvalidPublic

Description

Moderation/admin staff of All The Tropes have have lost the ability to protect pages at levels beyond "all users" and "logged in users", apparently as a side effect of the recent update.

Event Timeline

RhinosF1 triaged this task as High priority.Dec 15 2021, 16:09

@Looney_Toons Would you mind giving my test account 'Reception321' administrator permissions so testing this can be easier?

@Reception123 Going to the wiki shows

User account "Reception321" is not registered.

You'll need to ping it with your test account to create it first.

I'm also a 'crat there and I'm seeing the same issue.

@Reception123 Going to the wiki shows

User account "Reception321" is not registered.

You'll need to ping it with your test account to create it first.

I'm also a 'crat there and I'm seeing the same issue.

Oh yes, of course, {{Done}}. From my main account I'm able to see the admin level protection so that's why I need to debug using my test account.

Okay, granted admin for a week. Good luck.

@labster I'm not sure if maybe I'm misunderstanding the issue but protecting pages at the admin level seems to work fine for me:

(change visibility) 11:52, 16 December 2021 Reception321 talk contribs block protected Test T8444 [Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite) [Delete=Allow only administrators] (indefinite) (test T8444) (hist | change)

I did a little experimentation and determined that the problem is limited to our project namespace: When protecting or changing the protection level on a page in the All The Tropes namespace, all we are offered is "all users" and "all logged in users". Anywhere else in the wiki it's behaving normally.

The issue seems to be related to the $wgNamespaceProtection setting, as when it's set to none the administrator level protection returns. (cc @Universal_Omega )

Unknown Object (User) closed this task as Invalid.Dec 16 2021, 19:55
Unknown Object (User) claimed this task.

This is because the project namespace is protected to admins-only by default via $wgNamespaceProtection in Special:ManageWiki/namespaces (editprotected is exactly what the protect as administrator protects it as). This is intentional and expected behaviour.

Unknown Object (User) moved this task from Backlog to Short Term on the MediaWiki (SRE) board.Dec 16 2021, 19:58
Unknown Object (User) moved this task from Unsorted to Short Term on the Universal Omega board.

So, wait... was the behavior before the update in some way broken or incorrect? Because approximately 18 months ago we had to go through the entire project namespace and manually protect all the pages in it after some random schmuck wandered in and decided to change a few of our policies for us. We've gotten in the habit of manually locking everyone but admins out of those pages since.

So, wait... was the behavior before the update in some way broken or incorrect? Because approximately 18 months ago we had to go through the entire project namespace and manually protect all the pages in it after some random schmuck wandered in and decided to change a few of our policies for us. We've gotten in the habit of manually locking everyone but admins out of those pages since.

Probably yes, since the namespace protection shouldn't allow anyone other than administrators from editing those pages without having to manually protect them

In testing, I set a custom policy on this page. If it's already covered by the namespace protection, how would I remove the custom policy? Set it to "everyone can access" to restrict it to administrators?

It feels all too much like there's too much UX in here to make it actually work the way it's supposed to.

Namespace protection will overrule page specific so yes.