Add datetime selector to Special:Block to select expiration
Open, LowPublic5 Story Points

Description

Problem

When blocking a user via Special:Block it would be helpful to have a calendar as datetime selector to select a specific day and hour in the future as expiry time. This avoids typing a (english) timestamp in the correct format inside the duration field, when not using the default block duration from the drop down list.


Acceptance criteria
  • On Special:Block, add a buttonSelectWidget in front of the expiration dropdown.
    • This element should be skipped in the tab ordering of the block page.
  • The first button option should be a pencil icon, which should be selected by default.
    • When it is selected the expiration dropdown and text field should behave as they do today.
  • The second button option should be a calendar icon.
    • On click it should replace the dropdown and text field with a DateTimeInputWidget widget allowing the user to provide a calendar date and time. (YYYY-MM-DD HH:MM:SS)
    • On submit of the block, the system should calculate when block length between the current datetime and the selected datetime.
  • Error messages
    • The widget should not allow the user to select a date in the past (use an error message if needed)
    • The widget should display a red border if the contents are invalid (if possible)
    • If the system cannot compute a block length, on submit of the block the 'Expiry time invalid.' error message can display
  • Temporary Config flag
  • No change for no-JS users
  • Toggling between the two options (pencil + calendar) should not result in any data loss. Whatever is selected when the user submits the block should be submitted.
  • Should work on RTL and LTR wikis

Mockups
Note that in these mockups the order of the pencil and calendar icons are incorrect, and the calendar input is just a dateinput, when it will be a datetimeinput.

We'll want to add the DateTimeInputWidget which will be hidden behind a buttonSelectWidget, as seen on UploadWizard.

The default state would be the pencil, which would provide the same functionality as Special:Block has today:

On click of the calendar icon, it would change the list dropdown to the DateTimeInputWidget, like such:

The block would still be saved the same way, the calculation would happen before 'Block this user' is clicked.

There are a very large number of changes, so older changes are hidden. Show Older Changes
jrbs added a comment.Feb 16 2018, 12:43 AM

Pong. What are you looking for here - some feedback? :)

Ping.

Yes please! On my comment above, which I've also copied into the ticket description.

TBolliger updated the task description. (Show Details)Feb 16 2018, 12:47 AM

I plan to post this on the Meta and ENWP blocking consultation today for feedback.

TBolliger added a comment.EditedFeb 22 2018, 5:47 PM

An alternate UI treatment could be like UploadWizard:

This is already OOUI compliant, so I think we should proceed with this tactic, with the pencil as default. I'll try to whip up a few mockups today.

TBolliger updated the task description. (Show Details)Feb 22 2018, 10:08 PM

We should re-use the existing OOUI element, as seen on UploadWizard. The default state would be the pencil, which would provide the same functionality as Special:Block has today:

On click of the calendar icon, it would change the list dropdown to the dateInputWidget, like such:

The block would still be saved the same way, the calculation would happen before 'Block this user' is clicked.

]

It's been requested that we use a DateTimeInputWidget to allow users to calculate the time, too. We'd need to decide which timezone it would pull from.

TBolliger updated the task description. (Show Details)Feb 23 2018, 8:59 PM
TBolliger updated the task description. (Show Details)Feb 23 2018, 9:06 PM
TBolliger updated the task description. (Show Details)Feb 27 2018, 7:43 PM
TBolliger updated the task description. (Show Details)Feb 27 2018, 7:46 PM
TBolliger set the point value for this task to 5.

If more javascript is added to Special:Block, please make sure that it doesn't cancel any previously input data. It's annoying enough that the dropdown selections and other input is discarded as OOUI finishes doing its thing. It's frustrating to be forced to fill things over and over or to wait for all the unnecessary things before using the special page.

TBolliger updated the task description. (Show Details)Feb 27 2018, 8:07 PM

If more javascript is added to Special:Block, please make sure that it doesn't cancel any previously input data. It's annoying enough that the dropdown selections and other input is discarded as OOUI finishes doing its thing. It's frustrating to be forced to fill things over and over or to wait for all the unnecessary things before using the special page.

I've added "Toggling between the two options (pencil + calendar) should not result in any data loss. Whatever is selected when the user submits the block should be submitted." to the acceptance criteria

dbarratt claimed this task.
TBolliger updated the task description. (Show Details)Mar 9 2018, 10:49 PM

David, I added a new requirement (which is usually implicit, but I wanted to make it explicit):

Should work on RTL and LTR wikis

In the first bullet I say "on LTR wikis" but that is just to reference the placement of the button relative to the dropdown.

dbarratt added a comment.EditedMar 10 2018, 4:43 PM

@TBolliger

On click it should replace the dropdown and text field with a DateTimeInputWidget widget allowing the user to provide a calendar date and time. (YYYY-MM-DD HH:MM:SS)

and then:

On click of the calendar icon, it would change the list dropdown to the dateInputWidget, like such:

The DateInputWidget does not have the time select, but it has the design in the mock, the DateTimeInputWidget does have the time select, but has a different design. Which would you prefer?

@dmaza So it looks like the "right" way to do this would be to create a new Widget that is a combination of the other widgets... I could just mod the page with JavaScript but that seems really hacky and brittle, so while it's more work to create a widget, it seems like the right thing to do.

If more javascript is added to Special:Block, please make sure that it doesn't cancel any previously input data. It's annoying enough that the dropdown selections and other input is discarded as OOUI finishes doing its thing. It's frustrating to be forced to fill things over and over or to wait for all the unnecessary things before using the special page.

I created T189382: OOUI JS loads too slowly on Special:Block for this since it seems like a bigger issue.

TBolliger updated the task description. (Show Details)Mar 10 2018, 6:12 PM

The DateInputWidget does not have the time select, but it has the design in the mock, the DateTimeInputWidget does have the time select, but has a different design. Which would you prefer?

DateTimeInputWidget

The user should be able to select a date and time for the block to end. My doctored screenshots use the incorrect UI. Please use DateTimeInputWidget.

The user should be able to select a date and time for the block to end. My doctored screenshots use the incorrect UI. Please use DateTimeInputWidget.

You got it.

dbarratt added a project: I18n.EditedMar 20 2018, 10:21 PM

While I was doing this, I was transferring the fixed datetime (from the datetime picker) into a relative datetime to be sent to the server, I discovered that the value is being run through PHP's strtotime which describes itself as:

Parse about any English textual datetime description into a Unix timestamp

which is being used in SpecialBlock::parseExpiryInput()

And then I realized that the form can only accept English strings, which a careful reading of the problem statement of this issue would have revealed:

This avoids typing a (english) timestamp in the correct format inside the duration field, when not using the default block duration from the drop down list.

If I understand this correctly, the problem (the bug) is not a UX issue (that the user has to specify a relative time), but instead an I18n bug (in which, the input must be specified in English).

To determine if this is correct... do English speakers want the date picker? Or would they continue to use the drop downs / relative input?

The solution then, should be to fix the relative input to be I18n. I do not think the solution should be to create a new feature which would only exist as a workaround to a bug and would have to be supported. On top of that, if we implement this feature, we'd still have to fix the I18n bug in the relative input!

I propose that the drop down uses translated strings for the labels that are displayed to the user (I noticed that it doesn't right now), and the value (that is sent to the server) is a ISO 8601 time interval. When the user selects "Other", two inputs will be displayed, one that allows the user to specify a number and another select form field that allows the user to specify the unit (i.e. "days", "weeks", "years", etc.) in their language.

This provides a more consistent UI, fixes the I18n bug, reduces the scope of this issue, and does not introduce any new features. The only downside is that I'm almost done with the date picker, but regardless, I don't think it's worth the cost of implementation, especially when we'd have to open up a new ticket to fix the I18n bug.

I think offering both the datetime expiration picker and a length dropdown is valuable to all wikis regardless of language. Some blocks are for common infractions — e.g. someone vandalized, they get blocked for ~30 hours. But some blocks are more nuanced — e.g. two users are in conflict, block them until we can synchronously discuss it on wiki.

I'm very curious why this didn't come up during our blocking consultation. Did we not get enough non-English participants? Granted, the page on Meta was in English but we reached out to 10 Wikipedias of 10 different languages and did see some language-specific feedback. Just not about this.

I'd really like to hear from @kaldari about this, but my current instinct is to implement the datetime picker on top of the existing (arguably flawed) system and open a new task to talk about proper i18n support.

I've given this some thought, and I think @dbarratt's idea makes a lot of sense. 99% of blocks use the pre-set values, so I don't think we need to build a complicated UI for handling the other 1%. As David mentions, the datetime picker idea is basically a workaround that doesn't completely solve the problem. I think what's really needed is an easy way to enter non-pre-set values without having to resort to English. The easiest way to do that is probably the system David describes. While we're in there, I would recommend moving "Other time:" to the bottom of the list (since it's the least used and most difficult of the options), i.e. moving Ipbother after Ipboptions. But that's just a thought.

BTW, you can get the translated time unit names from the cldr extension I believe. Take a look at the TimeUnits.body.php file.

I'm very curious why this didn't come up during our blocking consultation. Did we not get enough non-English participants? Granted, the page on Meta was in English but we reached out to 10 Wikipedias of 10 different languages and did see some language-specific feedback. Just not about this.

In general, because the AHT team is working on the Blocking tools, I think most people are more focused on items that are more relevant to mitigating harassment. We didn't do a general call for people to tell us everything that they have problems with related to the blocking tools.

I think offering both the datetime expiration picker and a length dropdown is valuable to all wikis regardless of language. Some blocks are for common infractions — e.g. someone vandalized, they get blocked for ~30 hours. But some blocks are more nuanced — e.g. two users are in conflict, block them until we can synchronously discuss it on wiki.

I'd really like to hear from @kaldari about this, but my current instinct is to implement the datetime picker on top of the existing (arguably flawed) system and open a new task to talk about proper i18n support.

If I remember correctly, the idea for a datetime picker came from de:wp. If so, let's check in with the people who wanted the feature to understand which solution(s) are needed to fix the issues that they were having with the current way to set the time.

Sydney remembers correctly, I brought that in from a discussion on de:wp that unfortunately sprang up just a few days after the closing of the blocking consultations. The length dropdown menu with a flexible option would help solve a lot of the problems, but would still require some outside calculations for one common use-case on de:wp - reinstating a block that was lifted to allow the user to take part in public discussions on his/her request for unblocking. Here the datetime expiration picker would be perfect. But the length drowdown might have a wider range of applications across all wikis.

TBolliger added a comment.EditedMar 21 2018, 6:58 PM

We talked about this at length in today's AHT standup. We agreed to complete this task (T132220) as currently described. Fixing the i18n issues that David discovered and helpfully described in T132220#4066969 is another important problem to address, but will likely require a lot of discussion on wiki as it could be interruptive of existing workflows on the current interface. David will create a new task.

Also, I'm going to file a new task to gather some data on how blocking tools are use — how many wikis customize MediaWiki:Ipboptions and what are the most common lengths described? What is the distribution of block lengths, per wiki? How many blocks naturally expire vs. are manually unblocked? Etc. Edit: I've created the ticket here: T190328: Generate statistics on blocking usage

dbarratt updated the task description. (Show Details)Fri, Mar 23, 4:04 PM
dbarratt updated the task description. (Show Details)Fri, Mar 23, 7:26 PM
dbarratt updated the task description. (Show Details)Fri, Mar 23, 7:33 PM
dbarratt updated the task description. (Show Details)Sat, Mar 24, 1:42 AM
dbarratt updated the task description. (Show Details)Sat, Mar 24, 2:24 PM
dbarratt updated the task description. (Show Details)Sat, Mar 24, 3:36 PM

Change 422063 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Create Expiry Widget with Date Time Selector

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

Probably should add some tests, but uhh, not sure where...

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

So, we can enable this on a wiki-by-wiki basis?

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

So, we can enable this on a wiki-by-wiki basis?

Yes, but the config defaults to being enabled, so you have to intentionally disable the feature (on a per-wiki basis). :)

Ah ok gotcha gotcha. I think it's fine to just release to all wikis, but should probably hear from @SPoore about a release strategy.

David — Is there any way you can set up a test environment? Maybe CommTech Wiki? (see Niharika's recent email)

David — Is there any way you can set up a test environment? Maybe CommTech Wiki? (see Niharika's recent email)

http://commtech.wmflabs.org/wiki/Special:Block

TBolliger updated the task description. (Show Details)Tue, Mar 27, 11:33 PM

I can't QA "Temporary Config flag" but everything else hits the Acceptance Criteria!

For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.

For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.

Good plan.

Amire80 moved this task from Untriaged to Date and time on the I18n board.Mon, Apr 2, 11:56 AM

The Timeless oddity I mentioned:

Also getting the following JS warning when switching from 'other time' to any of the other options:

Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.

@Samwilson — Curious if this happens for this widget on all uses in Timeless, or just on Special:Block.

Can you make another ticket, if you feel this is worth addressing? I'm not sure if Timeless bugs are the best use of AHT's time right now...

Also getting the following JS warning when switching from 'other time' to any of the other options:

Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.

So I saw this before I sent the patch and I'm not sure what the best way to resolve it is (if it should be resolved at all). I need to parse legitimate dates from the text fields to the date selector (which doesn't throw the deprecation warning), but one of the dropdown values (or any other non-specific value) is going to fallback to Date() and then ultimately fail (which is fine, there's nothing we can do about that). The problem is, I can't think of a reliable way to determine the difference between something JavaScript can understand verses something it cannot understand.

I guess I could just attempt to parse with Date() and if successful, pass that object to moment? That would bypass the deprecation warning, but it would also not give moment an opportunity to parse it itself. I figure, if the feature is removed in the future, it (shouldn't?) matter because every time I see the deprecation, the Date() parsing failed anyways, so the removal of the feature, shouldn't result in any problems.

A bigger issue is the console.log() that happens, and older versions of IE do not have the console object, so the notice will throw a fatal error, but I assume moment is first checking for console.log before attempting to use it.

It's probably fine to leave the deprecation warning in, but maybe there's a way around.

Am I reading things correctly: the date only needs to be passed to Moment when the relativeField is "Other time", and not for the other ones? But it's hard to check for that in that spot because the relativeField's change event is getting its value from itself *or* the other text input, so the only way to check is to see if it parses as a date? Maybe it'd be possible to decouple those a bit, and see if it's 'other' or not, and then parse the date.

It's probably fine to leave the deprecation warning in, but maybe there's a way around.

Am I reading things correctly: the date only needs to be passed to Moment when the relativeField is "Other time", and not for the other ones? But it's hard to check for that in that spot because the relativeField's change event is getting its value from itself *or* the other text input, so the only way to check is to see if it parses as a date? Maybe it'd be possible to decouple those a bit, and see if it's 'other' or not, and then parse the date.

Uhh... so... basically any wiki can specify their own options, and technically anything that strtotime() supports will work. I'd like to change this to use a standard (non-english) format in T190449.

But yeah, even with that, it would be transferring a relative date to a precise one (and that obviously wont work well in reverse), so we could just limit it to only working when the "other" is selected, but if a wiki removes all of the options, then it's only a text field.

There's also nothing that stops someone from specifying a relative date in the other field, so I can write "2 days" and that will work (since strtotime() can parse that without a problem).

So I think we should try to parse it the best we can (with moment? with Date()?) since there isn't an equivalent to strtotime(), and if it fails, no big deal.

I mean the alternative is is that we don't even try, but I think trying makes a better UX.

The date selector field expands all the way to the right but the trash/bin icon is left aligned after the date making the field looks funny. The input should probably not expand all the way to the right

This is a defect of the DateTimeInputWidget. It was actually wider by default and I made it shorter. I like it lining up with the other fields... maybe the trash can should be right aligned? Would that fix the problem?

So you can't make the field smaller? Maybe set a max width? or create two columns in that row? If there is nothing you can't do the fine.

So this is how it is by default:

and I made it shorter in order to make it all line up:

Are you saying it should be even shorter?

What are your thoughts @TBolliger?

Don't forget the calendar pop-up is an even different size!

I think leaving it as it is on http://commtech.wmflabs.org/wiki/Special:Block is fine.

A nitpick and not an error, but it might be confusing for someone to see the T and Z on the date format after you have selected a date

That's actually the date format that DateTimeInputWidget provides, but I could reformat it into something else... but it would need to be something that is 1) Not exclusively English and 2) Understandable by strtotime()

I'm talking about the format you get when you switch to the textfield (pencil) after you pick a date on the time picker.

Right, so the problem is, is that you need to be able to switch back and forth between the two and it needs to be able to parse the format. I don't care what format we use, but it needs to be consistent.

Here's what we have right now:

but that does not translate to other languages:

this is what I went with:

@TBolliger, so @dmaza is saying that we should not change the format because that's not part of this ticket (and could anger some people, especially on English), but on the flip side, maybe it's a good opportunity to use a language neutral format? What do you think?

I don't anticipate too many people will actually toggle back-and-forth repeatedly. Sure, it's possible and yes, we should provide the best experience but I don't think this is the most crucial detail to split hairs over.

In cases like this, I try to emulate existing patterns on wiki. There are plenty of other places that already show datetime — history, contributions, etc. And this is what they look like with the default preferences:

But as we know, T190449: Expiration field on Special:Block only accepts English input which makes displaying the month name (rather than number) for non-EN communities less than ideal. But if this is the existing behavior than I will agree with Dayllan and not change the existing behavior. We can fix the i18n issues in T190449.