Disable submit buttons if we know the user can't edit

Authored by Mattflaschen-WMF on Mar 25 2016, 1:49 AM.


Disable submit buttons if we know the user can't edit

For performance reasons, we can not compute this with 100% accuracy
at page load (we could maybe do it when they open the editor, but this

Also show "Not editable" in description when we know it's not editable
(quickUserCan or user is blocked).

However, there is a core variable (wgIsProbablyEditable) that tells you
when they definitely can *not* edit. However, We keep using the
similar 'editable' status for BoardDescriptionWidget since it already
uses a model.

This uses that information to disable save buttons and show the user an
indication of why. Different messages are shown depending on whether
the user is logged in and the type of protection or edit restriction.

Properly handle board description protection when header does not exist.

Centralize most permission checking in the Workflow object. Make sure
we always check the correct title and check for create permissions if
and only if they're creating. Require specifying rigor (controls
speed and whether master can be used).

Remove some redundant permissions checks elsewhere.

I kept the new topic and reply text boxes that show by default, per the
mockup, but removed the reply links, in order to avoid hacking up the
backend actions (we need the replyto id to render the link, but that is
only returned when reply is considered a valid action)

Known issue - The buttons still show for 'user blocked', because in
that case the page is "probably editable" and the new topic and reply
widget are not wired up to their models. The error message on-save
still displays correct.

For no-JS, all the links are now gone (and it says "Not editable")
except new topic. That blocks it on submit.

Remove some dead code in related areas.

Bug: T108762
Bug: T127774
Change-Id: I7507a67e9ca9dfc778f795c96604951e85f9b3f6


Mattflaschen-WMFMay 10 2016, 11:17 PM
rEFLWbc4d038dc48d: Make FlowReplies slightly work