Page MenuHomePhabricator

Reply links appear for users who can't edit the page
Open, Needs TriagePublic

Description

Reply links appear for users who can't edit the page (e.g. because it's protected and the user is not logged in).

We previously fixed this in T240582 but it came back, looks like we broke it in rEDTO64392af48530: Add reply links on the server (T252555).

(Reported by @Ryasmeen in T273554)

Testing instructions

Scenario #1: protected talk page

  1. Visit a talk page that is protected
  2. Notice [ reply ] link are: A) visible and B) appear as they normally do
  3. Click any [ reply ] link on the page
  4. Verify a modal dialog appears with error message similar to this (the exact wording will differ on different wikis):

Scenario #2: person is blocked from editingmoved to T270803

Done

  • What's described in the "Implementation details/testing instructions" section above is implemented

Event Timeline

Change 668193 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Only show reply buttons if user can edit the page

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

The patch above proposes hiding the reply links if the user can't edit the page. We should discuss with @iamjessklein and @ppelberg what this means for the UX.

@Esanders / @matmarex:, can y'all confirm: Beyond someone who is logged out landing on a talk page that is protected, who – if anyone – else would be impacted by the decision we are making in this task?


⚠️ Note: the questions below can be disregarded for now. Reason: I suspect I misinterpreted the scope of this change and would like to make sure I understand it clearly before purusing the below...

Questions

  • 1. Does the below accurately and exhaustively describe what people who are logged out *currently* see/experience when viewing a page that is protected? [i]
    • Article page
      • People will see the article content WITHOUT any edit affordances being visible. Read: no section [ edit ] links and no Edit tabs atop the page.
    • Talk page
      • What people can see and interact with on a talk page is NOT impacted by the protection level of the content page to which the talk page is related.
  • 2. @matmarex, what is leading you to propose hiding [ reply ] links? I ask this question considering the following:
    • Protecting talk pages goes against convention at some wikis, and perhaps many others. [ii][iii][iv]
    • Few pages in the talk namespace seem to be protected at the wikis I checked:
    • Being able to talk on the talk page of a protected page (a mouthful!) seems like an important way for people to suggest edits to a page they cannot directly edit.

i. Example of a protected page: https://en.wikipedia.org/wiki/Barack_Obama
ii. Talk pages are not usually protected, and are semi-protected only for a limited duration in the most severe cases of vandalism. | en:Wikipedia:Protection_policy#Article_talk_pages
iii. Discussion pages are generally unsecured except in some exceptional circumstance. (English via Google Translate) | ru:Wikipedia: Partial page protection
iv. An administrator can completely block a banned user discussion page if that page, the only page that the member has the ability to edit, is being continuously mis-modified. (English via Google Translate) | vi: Wikipedia: Provisions for page locking

Esanders renamed this task from Non-functional reply links appear for users who can't edit the page to Reply links appear for users who can't edit the page.Mar 10 2021, 1:50 PM
Esanders updated the task description. (Show Details)

The same logic would apply to blocked users, so it's not just protected talk pages.

The same logic would apply to blocked users, so it's not just protected talk pages.

I see.

Requirements
I think it's important that the "People impacted" (listed below) are aware:

  1. They are not able to edit, comment on or start a new discussion on the page they are viewing
  2. Why they are not able to do what is described in "1."

With the above said, I default to @iamjessklein to express what she thinks might be the best approach to making the "People impacted" aware of the information listed in the "Requirements" section above.

People impacted

  • People who have been blocked from editing Wikipedia [i]
  • People who are logged out who are viewing a talk page that's been protected [ii]

Note: in Gerrit, @Esanders raised the idea of it potentially being worthwhile to treat [ reply ] links differently from [ edit ] links in this context. I understood Ed as suggesting this because we have thought, and continue to think, of [ reply ] links as a way to help Junior Contributors recognize talk pages as places to communicate with other editors. With this said, I do not think the approach we take in this context should be constrained by the "[ reply ] links as signposts" notion, because I think it is unlikely for a Junior Contributor seeking to make good faith edits to find themselves in either of the scenarios the decision we are making here will have an impact on.


i. "Blocking is the method by which administrators technically prevent users from editing Wikipedia. Blocks may be applied to user accounts, to IP addresses, and to ranges of IP addresses, for either a definite or an indefinite time, to all or a subset of pages. Blocked users can continue to access Wikipedia, but cannot edit any page they are blocked from (including, if appropriate, their own user pages)." via en:Wikipedia:Blocking policy
ii. "Protection is a technical restriction applied only by administrators, although any user may request protection. Protection can be indefinite or expire after a specified time. The are different kinds of protection are detailed below, and they can be applied to the page edit, page move, page create, and file upload actions." via en:Wikipedia:Protection policy.

If a contributor is logged out we should provide on-page messaging telling them to log in order to engage in the conversation.

Option 1: Show reply links but have them disabled but provide a message to the Contributor explaining why and how to log in.
Option 2: Don't show reply links but have a general message on the page explaining why and how to log in.

My preference is Option 1 because it provides contextual guidance to the contributor.

Conversation with @Esanders:

Ed thinks that this is a duplicate issue to T270803

There are a few complications:

  1. There are a few reasons why someone might not be able to reply (not being logged in, protected page, user banned)

Proposed Solution:

  • Reply link (and future button) is enabled, before we draw anything on the page we draw a modal
  • Modal options:
    • message with login prompt for logged out users
    • call to action where they can learn more about why they were blocked and links to contest it, something similar to:

  • message with a lock for protected content

Note: this is not ideal, because it happens after the user clicks the link/button but it's better than having absolutely no indicator.

  1. Pages could be made up of multiple pages (transcluded sections) so you might be able to edit the subpage but not the first page in that cluster.

Proposed Solution: Do the same as the solution above, however, the tradeoff with this is that because of the nested nature of the replies, some links within a cluster could have different access levels (and so for each reply link we have the different messages).

So in a nutshell, we can't do Option 2 from T276393#6917560 (no links but banner message), but we can do Option 1 (show links but with lots of special situation handling).

Conversation with @Esanders:
So in a nutshell, we can't do Option 2 from T276393#6917560 (no links but banner message), but we can do Option 1 (show links but with lots of special situation handling).

@iamjessklein, the context you and @Esanders shared is helpful and leading me to think that for now we ought to hide the [ reply] links entirely for people who have been blocked from editing Wikipedia and for people who are logged out and are viewing a talk page that's been protected.

Here is what's leading me to propose hiding [ reply ] links in these scnearios:

  1. I think we can assume that it is unlikely for a Junior Contributor seeking to make good faith edits will find themselves in either of the scenarios the decision we are making here will have an impact on. See Question 2 in T276393#6899170.
  2. I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.
  3. Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.


Note: I recognize that moving forward with hiding the [ reply ] links we would be defying the Requirements I put forth in T276393#6907279. I think that's okay considering the above.

I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.

I don't know if we can say what the likelihood of this happening is for blocked users, especially now we have partial blocks.

Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.

Leaving the links in and showing the error message is probably the easiest solution at this point, as it what we have implemented already for cases when the reply tool doesn't work due to complex templates.

We can keep the modal's simple and just show a text message "... because you are blocked" or "... because this page is protected" in the first iteration.

Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.

Leaving the links in and showing the error message is probably the easiest solution at this point, as it what we have implemented already for cases when the reply tool doesn't work due to complex templates.

We can keep the modal's simple and just show a text message "... because you are blocked" or "... because this page is protected" in the first iteration.

What @Esanders is proposing sounds like a good first step. I've updated the task description with these implementation details.

  1. I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.

I think it’s worth noting that nothing prevents this from happening the other way round, that is, the main page is not protected, but the transcluded page is. For example I recently came across a wiki (unfortunately I don’t remember which) where old request pages (requests for rights, as far as I remember) are protected. If these requests are transcluded for a short time after being closed, comments within these transcluded parts cannot be replied to, while eventual comments on the main page can. Probably this is also rare, but not impossible either.

Change 668193 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/DiscussionTools@master] Only show reply buttons if user can edit the page

Reason:

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

Change 674658 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

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

I set up a demo wiki for testing: https://patchdemo.wmflabs.org/wikis/a8da9c890a/. Instructions:

  • Log in as: [with password 'patchdemo1']
    • Alice (who is an administrator) [edit: I forgot to make this user an administrator, fixed now]
    • Bob (who is a normal user)
    • Mallory (who is blocked)
  • Test on pages:
  • Try both tools:
    • Reply tool
    • New topic tool

Example error messages (same as the ones shown in wikitext editor):

Note that the error messages on Wikimedia wikis are going to look different, since many wikis customized them (especially the large ones).

Note also that they mention editing pages, rather than adding replies or new topics. I think this is acceptable, but more importantly, I think we should not try to customize them because that's going to conflict with each wiki's customizations. If we made custom error messages, they would probably never be adjusted to link to each wiki's protection or unblocking policy etc., and even if we worked with the communities to do that, they would inevitably drift away over time and become outdated.

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Test wiki on Patch Demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Change 674658 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

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

I logged in as Mallory, and https://patchdemo.wmflabs.org/wikis/a8da9c890a/w/index.php?title=Talk:Normal_board&action=edit gives me:

[5db0d179a84316700496fd73] /wikis/a8da9c890a/w/index.php?title=Talk:Normal_board&action=edit RuntimeException: SFS IP file contents and file md5 do not match!

Backtrace:

from /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(222)
#0 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(86): MediaWiki\StopForumSpam\DenyListUpdate::fetchDenyListIPsRemote()
#1 /srv/patchdemo-wikis/a8da9c890a/w/includes/libs/objectcache/wancache/WANObjectCache.php(1600): MediaWiki\StopForumSpam\DenyListUpdate::MediaWiki\StopForumSpam\{closure}(boolean, integer, array, NULL, array)
#2 /srv/patchdemo-wikis/a8da9c890a/w/includes/libs/objectcache/wancache/WANObjectCache.php(1432): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
#3 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(90): WANObjectCache->getWithSetCallback(string, integer, Closure, array)
#4 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(44): MediaWiki\StopForumSpam\DenyListUpdate::loadDenyListIPs()
#5 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListManager.php(67): MediaWiki\StopForumSpam\DenyListUpdate->doUpdate()
#6 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/Hooks.php(142): MediaWiki\StopForumSpam\DenyListManager::isDenyListed(string)
#7 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookContainer.php(330): MediaWiki\StopForumSpam\Hooks::onGetUserPermissionsErrorsExpensive(Title, User, string, string)
#8 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#9 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookRunner.php(2037): MediaWiki\HookContainer\HookContainer->run(string, array)
#10 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(507): MediaWiki\HookContainer\HookRunner->onGetUserPermissionsErrorsExpensive(Title, User, string, string)
#11 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(457): MediaWiki\Permissions\PermissionManager->checkPermissionHooks(string, User, array, string, boolean, Title)
#12 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(307): MediaWiki\Permissions\PermissionManager->getPermissionErrorsInternal(string, User, Title, string)
#13 /srv/patchdemo-wikis/a8da9c890a/w/includes/EditPage.php(736): MediaWiki\Permissions\PermissionManager->getPermissionErrors(string, User, Title, string)
#14 /srv/patchdemo-wikis/a8da9c890a/w/includes/EditPage.php(598): EditPage->getEditPermissionErrors(string)
#15 /srv/patchdemo-wikis/a8da9c890a/w/includes/actions/EditAction.php(71): EditPage->edit()
#16 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(531): EditAction->show()
#17 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(315): MediaWiki->performAction(Article, Title)
#18 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(913): MediaWiki->performRequest()
#19 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(546): MediaWiki->main()
#20 /srv/patchdemo-wikis/a8da9c890a/w/index.php(53): MediaWiki->run()
#21 /srv/patchdemo-wikis/a8da9c890a/w/index.php(46): wfIndexMain()
#22 {main}

(I first tried clicking on a [reply] link on the page, and I got the same error message, but without stack trace and without mentioning that it’s a RuntimeException.) I’m pretty sure that’s not how it’s supposed to work. 🙂

On Talk:Normal_discussion I managed to get the block message, and it actually consists of (permissionserrorstext-withaction: 1, (action-edit)) (the same goes for protected page message). If you change it to (permissionserrorstext-withaction: 1, (action-reply)) (and define the action-reply message), it will use the correct term in vanilla MediaWiki, and probably most Wikimedia wikis as well, unless permissionserrorstext-withaction is customized in a very unusual way (e.g. with a {{#switch: for all possible values of parameter $2). Is there a way to list all customized versions of a given MediaWiki message across Wikimedia?

I saw that as well, but it seems to have disappeared by itself now… It must be a problem with either the StopForumSpam extension (not currently enabled on Wikimedia wikis, but I was asked to add it to Patchdemo for testing), or with Patchdemo itself, and not with the changes from this task. Anyway, I disabled the extension on that demo wiki just in case, to make sure everyone can test this.

On Talk:Normal_discussion I managed to get the block message, and it actually consists of (permissionserrorstext-withaction: 1, (action-edit)) (the same goes for protected page message). If you change it to (permissionserrorstext-withaction: 1, (action-reply)) (and define the action-reply message), it will use the correct term in vanilla MediaWiki, and probably most Wikimedia wikis as well, unless permissionserrorstext-withaction is customized in a very unusual way (e.g. with a {{#switch: for all possible values of parameter $2).

Hmm, that's a good point, changing that message is probably doable (although I'm afraid it's more difficult than it looks – by the point we display the message, we can't replace the message keys it was generated from, and 'action-edit' itself comes from code that checks whether the user is allowed to perform the 'edit' action, so we'd either need to define and check for the 'reply' action instead, or add a way of replacing the message without changing the logic).

However, I was mostly thinking about the more specific messages shown below that intro:

Is there a way to list all customized versions of a given MediaWiki message across Wikimedia?

I use this: https://global-search.toolforge.org/?q=.&regex=1&namespaces=8&title=Blockedtext. I don't know if it's perfectly reliable, but it gives 317 results for this one. ;)

matmarex updated the task description. (Show Details)