Now with the editor changes, this would be easier to do in AnonWarningWidget (we'd have to generalize that widget for that).

Needs to be specced.

Only at the top? Next to every editor? Wording?

How about this:

The message appears in the box when you click into an entry field, as we do with the anon edit warning.
The background color is the standard pink warning color that we currently use.
The text is the normal text color, not dark red as the current "Blocked" is.
Green post button is grayed out.
Clicking Cancel does not give a warning, even if there's text in the field.

The message says:
Warning: This page has been protected so that <appropriate warning level description>.
Reason: <reason given when the page was protected>.

I don't think we need to do the full-on treatment with the whole log entry; it's a smaller space, and I think it's more info than the person needs at that moment.

@Pginer-WMF @Quiddity Do you have any thoughts? I'm happy to put this in the sprint as Normal if we agree on the message and treatment.

I may be missing some context, so feel free to correct me. Here are some thoughts:

• If users are not able to send a message, we should not allow them to input text or submit. Thus, if they access the message text area it should be disabled (non editable and greyed out) and the submit button should be disabled too.
• The limitation is not the users fault and the user can do little about it. So I'd consider presenting the message in a way that conveys more the idea of "disabled" or "warning" at most rather than "error". That makes me think red may not be the best color for this case.
• Where to show the warning? On the one hand, if the hole board is blocked for participating, the earlier we communicate that to the user the better. It does not make much sense to provide people with options we are not going to let them complete. On the other hand, showing the blocked status too much upfront may add clutter for all the readers that don't participate in the discussion. So I think we can have some clues to indicate the board is blocked and provide more details if the user tries to participate.

Considering the above I was thinking on a solution along these lines:

• In the board info replace the edit action with a "protected" indication.
• On input fields, add an icon and adjust their usual placeholder to indicate the protected status. Users can still click on them (see below).

• If the user tries to edit or post, a warning message is shown. The padlock icon is used and the message should be brief but informative.
• The text area and the submit button are disabled. So users cannot add/modify content and they cannot submit the changes.

Yes, the orange box and lock icon is great.

I think that putting the lock and warning in all of those places feels like overkill, especially for someone who's just reading and isn't intending to reply. Putting your cursor into a reply field is the signal showing the intention, and I don't think it's particularly onerous. I'll put your mockup in the task description, and then I think we're good to go.

Change 279568 had a related patch set uploaded (by Mattflaschen):
Disable submit buttons if we know the user can't edit

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

This first pass doesn't say why they can't edit, since I don't think that information is available on the client-side yet. We can go through and add it later, but I thought it was worth at least giving some indication.

This is what Matt's patch looks like. He says "we should polish the text and use a better icon". @Pginer-WMF , @jmatazzoni , could you guys help with that?

In T108762#2164223, @Catrope wrote:

This is what Matt's patch looks like. He says "we should polish the text and use a better icon". @Pginer-WMF , @jmatazzoni , could you guys help with that?

• I think input fields should become disabled (and look disabled) if the user is not able to contribute.
• Regarding the current message, I'd propose to shortening it and avoid jargon (i.e., mentioning "Flow"): "This board is protected. Only users with the required rights can participate."
• In the screenshot we are telling the user two messages (user being logged out and board being blocked). It would be better to tell the user one message at a time. We may want to provide a single message depending on the context: (a) the board is protected and only logged-in users with the required rights can participate, and (b) the board is protected and only users with the required rights can participate.
• For the specific messages it would be good to know which information do we have. Do we know which rights are required for the user to participate? Do we know the reason for the protection?
• In T108762#1629834 I was proposing the use of a closed pad lock as icon ("lock" icon from the repo).

Usually, role and reasons are mentioned when a page is protected. We should have these reasons on the message, or, at least (because they are sometimes very long with links), a link to the protection log.

In T108762#2164372, @Pginer-WMF wrote:

In T108762#2164223, @Catrope wrote:

This is what Matt's patch looks like. He says "we should polish the text and use a better icon". @Pginer-WMF , @jmatazzoni , could you guys help with that?

• I think input fields should become disabled (and look disabled) if the user is not able to contribute.

Agreed. Will do.

• Regarding the current message, I'd propose to shortening it and avoid jargon (i.e., mentioning "Flow"): "This board is protected. Only users with the required rights can participate."

It might not be protected, so I will split the message.

• For the specific messages it would be good to know which information do we have. Do we know which rights are required for the user to participate? Do we know the reason for the protection?

Sometimes. The initial implementation did not check this (it just checked if are definitely prohibited from editing), but we have:

• Are you definitely prohibited (I'm phrasing it like this because we do not know if they are definitely allowed until they save) from editing? If you log in, etc. you may no longer be prohibited.
• Does it use standard protection (wgRestrictionEdit)? If so, it will tell you what groups you need to be in to edit. Normally, if there is standard protection, it is either "autoconfirmed" (you must have made 10 edits over 4 days (exact numbers vary)) or "sysop" (administrator).

I don't think it's common that logging in is enough to edit protected pages. Normally, you either need to be autoconfirmed, or be an admin.

• User's current groups (useful in conjunction with wgRestrictionEdit).

All of the above is available initially at page load, without any network requests.

Note they might be prohibited from editing for a reason besides standard protection, e.g. lacking createtalk. However, we can fork the messages to have one for standard protection (or even more than one depending on what kind of standard protection).

• In T108762#1629834 I was proposing the use of a closed pad lock as icon ("lock" icon from the repo).

Thanks, I think this is good. The black lock on the orange background looks kind of Halloween-y. I'm not sure if that's a feature or a bug. I can change the colors to whatever you want.

In T108762#2165396, @Trizek-WMF wrote:

Usually, role and reasons are mentioned when a page is protected. We should have these reasons on the message, or, at least (because they are sometimes very long with links), a link to the protection log.

I can get the protection reason from API:Logevents if we think it's useful, and/or link to the protection log.

In T108762#2166354, @Mattflaschen wrote:

Thanks, I think this is good. The black lock on the orange background looks kind of Halloween-y. I'm not sure if that's a feature or a bug. I can change the colors to whatever you want.

In my design I used yellow for the warning (trying not to convey this as an alarming situation, just a warning explaining why some functionality is different than usual). Back then, the recommended yellow was #FFB50D (which provides enough contrast with dark text), which we can still use.
After the latest revision of colors there are is no yellow or orange among the recommended colors. So, I brought that in M82 where several color issues are discussed, to check if there is a different recommendation.

Is the orange you were proposed used in similar kinds of warnings?

In T108762#2165396, @Trizek-WMF wrote:

Usually, role and reasons are mentioned when a page is protected. We should have these reasons on the message, or, at least (because they are sometimes very long with links), a link to the protection log.

If the message is self explanatory and the only problem is that it may be long, showing just one line with the possibility to expand can be a good solution.

In T108762#2168150, @Pginer-WMF wrote:

Is the orange you were proposed used in similar kinds of warnings?

No, sorry. I'll use FFB50D.

In T108762#2168155, @Pginer-WMF wrote:

If the message is self explanatory and the only problem is that it may be long, showing just one line with the possibility to expand can be a good solution.

I would prefer to start with showing the whole thing, and look into the collapse later.

I've updated the spec with specific messages, based on Pau's suggestions with some small adjustments to handle more scenarios.

We could fork the messages even more depending on what kind of protection if that seems useful.

In T108762#2169988, @Mattflaschen wrote:

We could fork the messages even more depending on what kind of protection if that seems useful.

I'll do that now (for the two common ones of autoconfirmed and sysop), since it's in the mockup.

See also T61928: Flow: If blocked, the user has no Reply buttons and the performance question I raised there.

What about the description (header)?

Should we stick to hiding the pencil (thus, no need for CanNotEditWarning in that case, since they will never be able to get to it)?

(I didn't notice this issue before, since the button-hiding is based on the 'edit' action, and that still appeared for anonymous users on protected pages. Whereas, before I was using wgIsProbablyEditable, which is correctly false there. I've made them consistent and am going to try to stop using wgIsProbablyEditable).

Note it doesn't put anything in its place currently. So it's mysterious why you can't edit the description.

In T108762#2170950, @Mattflaschen wrote:

Note it doesn't put anything in its place currently. So it's mysterious why you can't edit the description.

Having a very brief indication that the board is protected makes sense:

Since this is visible even if you were only interested in reading, I'd keep it minimal. If needed, we can provide access to the details from there.

I've removed all the write actions (when they don't have rights to use them).'

However, that also removes the reply links. I can add some code to keep them (which I'm working on now), but it's a little inconsistent internally.

In T108762#2265797, @Mattflaschen wrote:

However, that also removes the reply links. I can add some code to keep them (which I'm working on now), but it's a little inconsistent internally.

I thought of a less hacky way to do this.

In T108762#2213899, @Pginer-WMF wrote:

In T108762#2170950, @Mattflaschen wrote:

Note it doesn't put anything in its place currently. So it's mysterious why you can't edit the description.

Having a very brief indication that the board is protected makes sense:

I'm doing this, but I'm going to put "Not editable", since it could be non-editable for another reason (e.g. a block).

In T108762#2265813, @Mattflaschen wrote:

In T108762#2265797, @Mattflaschen wrote:

However, that also removes the reply links. I can add some code to keep them (which I'm working on now), but it's a little inconsistent internally.

I thought of a less hacky way to do this.

I was going to just render the reply links and forms unconditionally on the client (despite there being no reply action returned from the server).

However, then we don't have the reply to id, which means:

1. We can't render the reply link next to each post (neither the JS nor no-JS can do anything with that without reply to ID).
2. If we render the reply link/form at the bottom (JS turns the link into a form), for no JS you just get a broken link (symptom is that it just links to the board). If we don't render it, the the JS can't transform it into the form.

For now, I went with displaying neither of the reply options. I'm still displaying the new topic form, which doesn't have these issues.

The alternative approach is to modify the backend so that it still returns the reply action even though replying is not really allowed. I consider this a hack, but it could be done if necessary.

I might be mistaken about #2, still looking at it.

I got it to work by having JS render the disabled form, while hiding the useless link from no-JS.

Change 279568 merged by jenkins-bot:
Disable submit buttons if we know the user can't edit

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

Checked in betalabs. There are two paths - for logged in users and anon users; for the logged in users I checked autoconfirmed users and just users. Also, all are five levels for blocking were tested:
Edit action

1. Allow all users
2. Allow only autoconfirmed users
3. Allow only established editors and administrators
4. Allow only template editors and administrators
5. Block all non-admin users

Summary: all functionality is working.

The following notes/suggestions refer to either minor UI adjustments or to some improvements in communicating protected Flow board status more effectively to users.

For anon user: - some of notes apply to logged users also; I will add another comment for logged-in users issues.

• when the board description is collapsed, there is no indication that the Flow talk page is protected
• the switch editor button looks active
• the phrasing is a little bit discouraging? "You currently are not able to participate. You can try logging in". The message should provide more useful information.

• clicking on Permalink option for a topic or reply does not give any indication that no edits can be done. When anon user clicks in the text edit field, a normal waring appears and Reply button is active:

The last issue is about editing wikitext protected pages with VE.
Viewing wikitext page and clicking on View source will normally display clearly the warning that the page is protected and edits are not possible:

However, if VE is offered as an editor option via pop-up and a user clicks on it - the fully "editable" page is presented in VE. The edits cannot be saved though, and the cryptic error message is displayed upon attempting to save.

An attempt to switch back to the source edit just hangs up

1. There are two cases when Reason field if left blank will be displayed as 'Reason:Unknown' - when edit protection has status 'Allow only autoconfirmed users' or 'Block all non-admin users'

2. Resizing the browser window (slightly) messes up the layout of the warning message:

In T108762#2287337, @Etonkovidova wrote:

• when the board description is collapsed, there is no indication that the Flow talk page is protected
• the switch editor button looks active

This is a bug. @SBisson raised this in code review, and I thought I fixed it.

• the phrasing is a little bit discouraging? "You currently are not able to participate. You can try logging in". The message should provide more useful information.

That message only shows when we don't know why the page is uneditable. I will follow up on this in IRC.

• clicking on Permalink option for a topic or reply does not give any indication that no edits can be done. When anon user clicks in the text edit field, a normal waring appears and Reply button is active:

Only after a user made some edits and clicks on 'Reply anonymously', the second warning appears:

Yeah, before this was merged, we broke this out to T134927: Disable edit areas/submit buttons when editing is blocked (e.g. protected board) on topic pages too.

The last issue is about editing wikitext protected pages with VE.

Can you file this separately?

In T108762#2287826, @Etonkovidova wrote:

1. There are two cases when Reason field if left blank will be displayed as 'Reason:Unknown' - when edit protection has status 'Allow only autoconfirmed users' or 'Block all non-admin users'

This is intended, but we could tweak how it handles this case.

2. Resizing the browser window (slightly) messes up the layout of the warning message:

This is because the user-provided content (protection interface message) does not reflow very well.

In T108762#2289561, @Mattflaschen wrote:

In T108762#2287337, @Etonkovidova wrote:

• the phrasing is a little bit discouraging? "You currently are not able to participate. You can try logging in". The message should provide more useful information.

That message only shows when we don't know why the page is uneditable. I will follow up on this in IRC.

I'll just ask here. Was this from "Allow only template editors and administrators"? That is a less common special case (should be even more uncommon for Flow boards) we don't have special handling for.

As you noted, it shows more specific messages for other forms of protection.

@Mattflaschen
"You currently are not able to participate. You can try logging in". - is a general message for non-logged users. It makes sense though - when users log in, they may found that the protected board allows them to add edits.

Change 288515 had a related patch set uploaded (by Mattflaschen):
Hide editor switcher button on VE when switching is disabled

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

Change 288515 merged by jenkins-bot:
Hide editor switcher button on VE when switching is disabled

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

Re-checked in betalabs - the editor switch is not displayed anymore.