Created attachment 12953
What a blocked user sees when they try to save an edit in VE

Attached:

Created attachment 12954
What a blocked user sees immediately they the source editor loads

Attached:

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