Page MenuHomePhabricator

Flow: If blocked, the user has no Reply buttons
Open, NormalPublic

Description

As a blocked user, there are no Reply buttons at all, so I cannot find any error message, Nor any explanation of why the Reply buttons do not appear.

Performance question (see comment): Should we be checking blocked status at view time? We could check via AJAX when they click into the field, but if the perf is not that bad, we might not need to worry about it.

A blocked user can't edit its page but leave a message on the page is the way to appeal from a block.

See also bug T61927: Flow: Improve the blocked-user error message

Details

Reference
bz59928

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz59928.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

The WMF core features team tracks this bug on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/flow/cards/711, but people from the community are welcome to contribute here and in Gerrit.

No longer true.

My mistake. It's true for logged-in users, just not for IP users.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 28 2015, 1:39 AM
revi added a subscriber: revi.Jan 19 2016, 4:03 PM

UX-aside (which indeed is unintuitive), should we be checking this before they save?

Core:

  • checkUserBlock, indirectly called from userCan and quickUserCan
    • SkinTemplate calls it with quickUserCan (rigor 'quick'), which means it gets skipped.
    • When you visit the edit page (but before you save it), it uses rigor 'full', which means it does check the block status, but from a slave (it is checked from master on save).
  • Flow checks (from a slave) to generate the list of actions, which happens on every visit to the talk page.

I'm not sure if this is right, or not. Flow doesn't really have the same concept of edit page and I'm not sure how serious the performance issue is. Flow deals with Varnish poisoning by not checking either blocked status or quickUserCan for anons (since one anon being blocked does not mean "user is blocked" should be cached in Varnish). It seems like it should still check quickUserCan, though, so I'll change that to start with.

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 1 2016, 9:25 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 1 2016, 9:26 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 6:10 PM

Mentioned on IRC: a block user can't edit their talk page. Which is problematic a bit when you are supposed to edit this page to appeal from the blockage.

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 7:01 PM
SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.Jul 20 2018, 6:06 PM