Last modified: 2014-03-26 23:02:26 UTC
When a blocked users attempts to edit a page in the classic editor they see a large, red-bordered notice that tells them: *They are unable to edit, but they can still read *Who blocked them *Why they are blocked (shows them the block log extract) *When the block expires *That they can usually edit their talk page and email other editors and aministrators *What to do if the block is unclear or doesn't seem relevant *How to appeal a block (links to policy and guide) *That they can view and copy the source of a page In contrast when a blocked user attempts to edit a page in VE *No notice appears, and editing works as normal *When they click "Save page" they can review their changes and enter an edit summary as normal When they try to save their edits they see a small white box with a message that tells them: *There was a server problem *Their request was unsuccessful because they have been blocked They can then choose only "OK" which takes them back to the save page dialog. This is very bad because *The message they see appears to say they caused a server error - cue panic mode for non-technical users ("Help! I've broken Wikipedia!" - that is exactly the reaction I would expect from my mother.) *They have wasted potentially lots of time on an edit they cannot save *It doesn't tell them what being blocked means *It doesn't tell them who blocked them or for what reason *It doesn't tell them what they can do to get help - they can't ask questions at the page that seems to be about asking questions for example (see Bug 51875) *It doesn't tell them when the block expires, how they can appeal it or how they can contact anybody. For some users it is even worse that that - saving fails silently: Bug 51999
Created attachment 12953 [details] What a blocked user sees when they try to save an edit in VE
Created attachment 12954 [details] What a blocked user sees immediately they the source editor loads
James suggested I tackle this bug. I messed around with the API for a little bit and assuming I didn't miss anything: I think that if we tried to fill out the 'blockedtext' message properly on the client we'd have to: * Query the API for the user's blockinfo to determine whether or not they're blocked. If they are: ** Query the API for more info about this block which meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute into the message (expiry, user, timestamp). ** Query the API to parse the blockedtext message because it can't be done on the client (even the default message includes stuff mw.msg can't handle) ** Substitute the data we have into the message (and we still won't have $3 - the current IP) *** Mess around with dates/times because they won't be in the right format. Another way we could do this is return the full warning from action=visualeditor&paction=parse (therefore adding no extra API requests) which would cause the client to stop loading. I don't like this idea because obviously that paction is not intended for checking this kind of thing... Or we could ignore the core blockedtext message and use our own "Your username or IP address has been blocked", possibly with the info that just meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason). Or we could add a new API module/paction that can be queried once and provides all the relevant info. I don't like this idea either but it seems the nicest. Thoughts?
(In reply to Alex Monk from comment #3) > James suggested I tackle this bug. I messed around with the API for a little > bit and assuming I didn't miss anything: > > I think that if we tried to fill out the 'blockedtext' message properly on > the client we'd have to: > * Query the API for the user's blockinfo to determine whether or not they're > blocked. If they are: > ** Query the API for more info about this block which > meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute > into the message (expiry, user, timestamp). > ** Query the API to parse the blockedtext message because it can't be done > on the client (even the default message includes stuff mw.msg can't handle) > ** Substitute the data we have into the message (and we still won't have $3 > - the current IP) > *** Mess around with dates/times because they won't be in the right format. > > Another way we could do this is return the full warning from > action=visualeditor&paction=parse (therefore adding no extra API requests) > which would cause the client to stop loading. I don't like this idea because > obviously that paction is not intended for checking this kind of thing... > > Or we could ignore the core blockedtext message and use our own "Your > username or IP address has been blocked", possibly with the info that just > meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason). > > Or we could add a new API module/paction that can be queried once and > provides all the relevant info. I don't like this idea either but it seems > the nicest. > We already put random junk in the paction=parse response, I wouldn't be opposed to adding blocked-ness to that. Another paction would be OK too, but then we'd have to make two API requests. There are significant speed benefits in combining everything into one API request. I think we should stop kidding ourselves that paction=parse is a clean, only-does-one-thing action, and perhaps rename it if we want, rather than trying to split it into separate actions, because the latter would just make client-side performance worse.
(In reply to Roan Kattouw from comment #4) > We already put random junk in the paction=parse response, I wouldn't be > opposed to adding blocked-ness to that. Another paction would be OK too, but > then we'd have to make two API requests. > > There are significant speed benefits in combining everything into one API > request. I think we should stop kidding ourselves that paction=parse is a > clean, only-does-one-thing action, and perhaps rename it if we want, rather > than trying to split it into separate actions, because the latter would just > make client-side performance worse. Yes, since writing that comment I decided to just add it in to paction=parse, especially since talking to James - he wants this to be an edit notice like the others. I probably should have left a new comment about it. The problem now is coming up with a nice way to fit the autoblockedtext message (blockedtext is okay) in to the edit notices popup.
Change 119204 had a related patch set uploaded by Alex Monk: Show blockedtext message in edit notices https://gerrit.wikimedia.org/r/119204
Change 119204 merged by jenkins-bot: Show blockedtext message in edit notices https://gerrit.wikimedia.org/r/119204
