Date formatting
Status
Agreed
Result
Will be handled as bugs - Zak will forward to Stripes team - no timeline for development though
This wiki page is to collect expectations on date entering and formatting.
Requirement | Analysis Notes | Notes from AI discssion | Proposed pattern | Submitted by OR has use case for institution / customers | Date added | Implemented in Release | |
|---|---|---|---|---|---|---|---|
| 1 | User should be able to type in own locale and get the correct date displayed | 2022-05-10 vs 05/10/2022 vs 10.05.2022 | agreed | @Martina Schildt from AI discussion | May 10, 2023 | ||
| 2 | User should be able to type in own locale without punctuation and get the correct date displayed | user must type the punctuation mark rather that system automatically supplying it as the user types standard in most systems and generally online when filling out forms etc. | agreed | @Martina Schildt from AI discussion | May 10, 2023 | ||
| 3 | User should be able to search for from date without having to enter a to date | In cases where a user wants to find everything from a given date till today If no to date is supplied, the filter should act like the user has entered today as date | agreed | @Felix Hemme | May 24, 2023 | Ramsons Dev teams just need to implement work for their date range widgets. | |
| 4 | User should be able to search for to date without having to enter a from date | In cases where a user wants to find everything until a given date If no from date is supplied, the filter should act like the user has entered an really early date (e.g. 1900 or 1970) as date | agreed | @Felix Hemme | May 24, 2023 | ||
| 5 | Date picker should use a consistent method of entering month and year | Currently, the month can be selected using a dropdown menu, but to select a year, the user has to browse through options. | AI SIG agreed, but this is very difficult to change. Workaround: User should be able to type in own locale without punctuation and get the correct date displayed agreed | @Felix Hemme | May 24, 2023 | ||
| 6 | User should not need to press "Apply" button in order to apply the date filter new The “apply” button should be applied with a return key strike - across all apps | As soon as a date has been entered by the user, the result list should update accordingly and only display search results that match the filter, without having the user to click "Apply" first. That seems like an unneccessary step. | This is not doable due to accessibility issues The alternative would be to scroll back to top and do "search" → cumbersome @Martina Schildt After AI discussion we adjusted the requirement: the “apply” button should be applied with a return key strike - across all apps agreed | @Felix Hemme | May 24, 2023 | ||
| 7 |
Tickets created
Scenario 3 from this ticket (TO without FROM) describes: “Show an error message - Requires a From date or whatever is the error message today.”
So at least from this part it does not look like it has been fully implemented.
Hey @Felix Hemme - can you share details as to where you experience this issue?
The requirement listed on the App Interaction wiki page is: “User should be able to search for to date without having to enter a from date”. This is not in scope of STSMACOM-838. It is only about accepting a from date without a to date. But now that I take a look at UISINVCOMP-20 having just one of the two dates it is included there, so both requirements should be met now.
Hey Felix - although the story focuses on the from, John Coburn did work to support only the end date. Now we just need teams to apply this work across all date range filters.
stripes-force - this issue should have been implemented with https://folio-org.atlassian.net/browse/STSMACOM-838 and dev teams just need to implement work for their date range widgets.