Page MenuHomePhabricator

If a user is prevented from editing a protected page (due to being in the wrong user group), there should be a link to the protection log, or other relevant information
Closed, DeclinedPublic

Description

Currently, if you open a page which you can't edit because you're not an administrator or autoconfirmed (and this page is protected), you only see the message that this page is protected to prevent vandalism. This statement may be inaccurate though, and sometimes, the administrator (or whoever protected the page) wrote much more information on why he/she protected the page, which is visible in the page protection log. We should make that information available to the user, for example by linking to the page protection log in this case.

Event Timeline

Florian created this task.Apr 7 2015, 3:31 PM
Florian claimed this task.
Florian raised the priority of this task from to Needs Triage.
Florian updated the task description. (Show Details)
Florian added a project: Readers-Web-Backlog.
Florian added a subscriber: Florian.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 7 2015, 3:31 PM

Change 202424 had a related patch set uploaded (by Florianschmidtwelzow):
Add link to history page, if the user can't edit a page

https://gerrit.wikimedia.org/r/202424

Nnemo added a subscriber: Nnemo.Apr 9 2015, 12:30 PM

Change 202424 abandoned by Florianschmidtwelzow:
Add link to history page, if the user can't edit a page

Reason:
@JKatz: I rethought this, especially because of I146800e176e12d70ccb93d5d5ade934bc31740b3, and i think we should rethink the actual handling. There are several reasons (at least two), why an editor can't edit a page, but we always think (at the moment), that the user can't edit, because the page is protected (and in reality, maybe, the user is blocked). I will work on this separation first to give the user the correct reason, why he/she can't edit a page and after this, i will try to use the ContentOverlay and add a screenshot to the bug, ok? :)

https://gerrit.wikimedia.org/r/202424

Change 210950 had a related patch set uploaded (by Florianschmidtwelzow):
Show a better error message, when the user can't edit a page due to the false group

https://gerrit.wikimedia.org/r/210950

The above change would look like:

I'm a little confused here and missing the 'why'. What value does this give to the user? What is the goal of this? Do we expect this will increase edits? Build a better understanding of the project?

I'm not sure adding a link for the user to the history page is the best idea - what if the page was protected a year ago? How do I find that information? Why does it matter to know upon clicking edit? Why can't we just say "view the edit history to know more? in a standard toast."

Wouldn't it be better to say "This page has been protected because of "X"?"

Wouldn't it be better to say "This page has been protected because of "X"?"

Sure, that would need a new Api module or we extend mobileview, because we can't get the protection reason via the Api as far as i know :/

The value would be to give the user a concret reason, why he can't edit a page to better understand, _why_ the page was protected :)

But why does it matter the reason that it's protected..? There's no action I can take right? It's just a fact. :-)

It's an information, right, but maybe you want to leave a comment on the talk page saying, that the reason for the protection is gone, or better: With the reason you can better decide if it makes sense to ask on the talk page :)

And i think in favour of our openess we should at least give a rudimental way to find out the information you're looking for (in this case: the reason for the protection) :)

Still playing 'devils advocate' [1] :)
I'd say the information is already available - you can click history link and find it, but I'd say the majority of people don't really care. For example, most of the time I don't care. I don't even click on an edit link for a protected page usually... usually you can guess the reason e.g. it's an article that might be vandalised frequently or is in the news etc...

I'd argue that most people that do care would know to look at the history page and then ask on the talk page...

I think we generally have to be very vigilante about what JS is loaded on the mobile site. We should only have a finite set of futures that are truly essential to the viewing experience. To add anything from now on I think we have to have some hard conversations about what is the minimum experience we should be giving our users here.

I'd be interested in other people's thoughts as obviously this is just my opinion :-)

[1] https://en.wikipedia.org/wiki/Devil%27s_advocate

I agree with Jon that the page history may not be very useful in this case. However, just stating that "This page is protected to prevent vandalism" (the currently used message) is even worse. For starters, many page protections are actually not because of vandalism, but e.g. because of edit wars between disagreeing but good-faith editors (cf. this list on enwiki). The software shouldn't call these people vandals.

Wouldn't it be better to say "This page has been protected because of "X"?"

Sure, that would need a new Api module or we extend mobileview, because we can't get the protection reason via the Api as far as i know :/

Per https://www.mediawiki.org/wiki/API:Logevents , the page protection log can actually be accessed via the API, see (examples - the protection reason is in the "comment" field). This information can certainly be useful to the user who is trying to make the edit. More generally I would argue that it's also a matter of transparency as basic value of Wikipedia - we don't want to present admin actions as a black box with Kafkaesque connotations ;)

It might be worth reviewing how the same issue has been solved on desktop. It involves the system message MediaWiki:Protectedpagetext which is often modified locally (example: English Wikipedia ) to include a link to the protection log alongside other information.

By default, that system message on desktop includes the needed user right as parameter ("This page is currently protected so that only administrators can edit it" vs. "This page is currently semi-protected so that only established registered users can edit it."), because "protected" is never absolute - some people can always still edit the page. A clean solution on mobile should do the same. That said, a simpler version like the following would already be a great improvement:

"Editing of this page has been restricted for the following reason: " + the reason string from the protection log

Desktop actually allows you to view source so maybe we should do the same but have some kind of interstitial with the details? It would simplify the init script for editor.js that would be great. Would be good to have @JKatzWMF and @KHammerstein thoughts on this

Nnemo added a comment.Jun 1 2015, 12:44 PM

But why does it matter the reason that it's protected..? There's no action I can take right? It's just a fact. :-)

It matters, because it is an exception. Wikipedia claims to be "the encyclopedia that anyone can edit".

Change 210950 merged by jenkins-bot:
Show a better error message, when the user can't edit a page due to the false group

https://gerrit.wikimedia.org/r/210950

Change 210950 merged by jenkins-bot:
Show a better error message, when the user can't edit a page due to the false group
https://gerrit.wikimedia.org/r/210950

Perhaps I'm misreading the diff, but it appears that the patch still links to the edit history, even though it was explained above why this isn't very helpful and that we may want to use the protection log instead. (CC @bmansurov as code reviewer)

@Tbayer: Damn, sorry! I totally overlooked your comment :( But you're right, the actual merged change redirects to the pages history, not to the protection log, but it would be an easy change to point the link to the protection log.

I don't think, that the protection reason should be in mobile (it's not in desktop, too), but i think, that a link to the protection log of the page is a more valueable target for the link. I don't think, if different messages (semi-protected, fully protected...) is valueable enough to be used on mobile, if I think about the target audience :)

Let's make the protection log the target for now, as it seems the most easy thing :) Looking forward to further comments!

@Tbayer, thanks for the comment.
Taking

"This page is protected to prevent vandalism" (the currently used message) is even worse.

into account I think this is a step to the right direction. I don't see any disadvantages of the new patch compared to just a simple toast message. In fact, we can build upon the patch and add more features.

Note there is a typo in the merged patchset - "wherther"

Change 217901 had a related patch set uploaded (by Florianschmidtwelzow):
Change link target from histry to protection log

https://gerrit.wikimedia.org/r/217901

@Jdlrobson: Yep, saw this in the above change, too. I'm not sure, what you think about the link change, would you say, that i upload a fix for this typo in a separate change? The messages aren't in translatewiki.net now, so we can change it like we want :)

@Florian can you include a screensho of the drawer and the log in a comment? I would like @KHammerstein to take a look before we merge. Thanks!

Cta:

Protection Log:

@JKatzWMF, the first patch is already merged. We should act quick and decide whether we can deploy this or not. We still have time to revert until the next deploy.

@bmansurov @Florian I can't make head or tails of this edit log...everything besides the title and first sentence is gibberish.

i do not think we should surface this. anyone who can understand it will be able to get their by clicking on history. I do not think it is acceptable to suggest that unsuspecting users be taken to this page.

This should not be deployed until we can figure out how to present the message in terms a new user would understand.

also, kaity had this to say about CTA message:

Can we change that toast to read "this page is protected. See protection log for more information"
"Wether a reason was given or not" sounds confusing

Change 217977 had a related patch set uploaded (by Bmansurov):
Revert I59122b568cd353ca5c3aba0a28522effb15cfab4

https://gerrit.wikimedia.org/r/217977

Revert ^. We can change the toast message in a follow-up patch once the revert is merged.

Change 217977 merged by jenkins-bot:
Revert I59122b568cd353ca5c3aba0a28522effb15cfab4

https://gerrit.wikimedia.org/r/217977

also, kaity had this to say about CTA message:
Can we change that toast to read "this page is protected. See protection log for more information"
"Wether a reason was given or not" sounds confusing

That message without any link to the protection log sounds very confusing to me, especially newcomers would feel a bit hoodwinked, right? :)

@Florian yes, this would be for when we got the link to the log included. I think that will require a page that has the reason in plain english (or whatever language) and a link to the advanced version if you're so inclined.

@Florian yes, this would be for when we got the link to the log included. I think that will require a page that has the reason in plain english (or whatever language) and a link to the advanced version if you're so inclined.

As discussed above, it's entirely possible to extract only the rationale for the current protection, via the API. On desktop, English WP (and I guess most other projects) link to the entire log instead, but I don't see a compelling reason for that, especially if we want to reduce the amount of text that needs to be read in order to understand the current protection.

Change 217901 abandoned by Florianschmidtwelzow:
Change link target from history to protection log

Reason:
the base change was reverted, see ongoing task discussion

https://gerrit.wikimedia.org/r/217901

Jdlrobson triaged this task as Low priority.Sep 16 2015, 6:44 PM
Jdlrobson changed the task status from Open to Stalled.Sep 23 2015, 7:44 PM

if we have something usable on mobile to link to T95305 should be a good way to solve this.
Otherwise I suggest we decline this bug - I don't see a clear path forward.

Tbayer renamed this task from If a user is blocked from editing a page (due to the false group), there should be a link to the history to If a user is prevented from editing a protected page (due to being in the wrong user group), there should be a link to the protection log, or other relevant information.Nov 24 2016, 1:15 AM
Tbayer updated the task description. (Show Details)
Jdlrobson closed this task as Declined.Jun 2 2017, 8:50 PM

Doesn't look like we can find a way forward here. Reflecting reality and declining.