Page MenuHomePhabricator

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

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

Screenshot_from_2014-01-10_15:04:37.png (918×991 px, 145 KB)

Details

Reference
bz59928

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:37 AM
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.

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

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.

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.