[#4922] handle invalid date ranges in date range input

[danielabar]

Resolves #4922

Description

Fixes the issue where under very specific circumstances, a user could enter invalid data into the date range input (used to filter many views like Donations, Purchases, etc.) and have that data submitted to the server. In this case, an error would be raised and result in 500 Server Error page.

It was difficult to reproduce because most of the time, Litepicker.js (library which is bound to the date range input) is active and has its own validation logic for date ranges, such that if something invalid is entered, it will not update the state of the input, which results in it going back to the default value when user blurs away, so their invalid data never sticks around.

But if user tabs into the date range field, then the Litepicker.js events are not registered. In this case, the user can type in whatever they want without Litepicker being aware of it. Then if user hits Enter, the invalid date range will be submitted to the server. Server side logic was raising an error in this case. This has been fixed to gracefully handle it with a flash notice. See app/helpers/date_range_helper.rb.

Also, if a user tabs or clicks away from the date range field (after having tabbed in and entered invalid data), then some new client side JS has been added to alert them. See app/javascript/controllers/date_range_controller.js

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

For automated testing, the shared example spec/support/date_range_picker_shared_example.rb was modified to add cases for server and client side error handling of invalid input. This is run by all system tests that cover filtering: Transfer management, Donations, Purchases, Requests, Distributions, Adjustment management.

Quick way to focus on just these: bundle exec rspec spec/system -e "when entering an invalid date range"

For manual testing:

1. Log in as org admin
2. Navigate to Purchases -> All Purchases (should work the same for any form that uses date range for filtering)
3. Press the tab key multiple times until the focus is on "Purchase date range" field
4. Type in something invalid like "nov 08 - feb 08"
5. Hit Enter - should get the flash notice with date range reset to default

Repeat steps 1 - 3, but then instead of hitting Enter, click or tab away (you still need to tab in to the field though) - this time an alert displays.

In either case, you can click into the date range and fix the invalid date, then submit the form and it should work.

Screenshots

[danielabar]

Note some system tests have been failing on CI (Ferrum unknown target exception), but all tests pass locally.

[cielf]

Given how hard it is to recreate, I'm surprised how frequently we get them! (one or two a month) There's probably some one person who just does things this way.

Thank you for sussing it out! It LGTM functionally (in a perfect world, we'd have the same behaviour no matter how they got there, but this will do IMO). Over to @dorner for technical wisdom, etc.

[dorner]

One admin question, otherwise looks good to me.

Not sure what's going on with the system specs, but they seem to be failing consistently. We need a way to fix them if we want this merged.

[dorner]

Was this added by accident? I don't see it used.

[danielabar]

This adds a data-test-id to the filter button which is used in the shared example system spec:

page.execute_script("document.querySelector('[data-test-id=\"filter-button\"]').click();")

Normally would simply use the Capybara click method with text "Filter", but due to event handling required to reproduce this issue, had to use execute_script with querySelector. And there wasn't an easy way to select a button by its text. So this was to ensure that the test is clicking the correct button, in case there should be more buttons added to any of the pages in the future.

[danielabar]

Actually, after working through the CI failing tests, this is no longer needed, removed.

[danielabar]

One admin question, otherwise looks good to me.

Not sure what's going on with the system specs, but they seem to be failing consistently. We need a way to fix them if we want this merged.

I've seen those kind of test failures on CI (Ferrum::NoSuchTargetError), on this and other projects that use Cuprite, but usually they resolve with a re-run. And all the tests do pass locally so this is a strange one.

I even tried running the tests locally with the same seed that's failing on CI, in case there's a specific sequence of test execution that causes the failures:

bin/rspec --seed 18633

But still they pass locally.

There have been some commits on main since this PR was submitted so I could try to rebase (or is that not allowed after PR is submitted?) and see if that makes a difference.

[danielabar]

Update on system tests: I temporarily commented out the new invalid date range tests, and then all the tests pass on CI: https://github.com/rubyforgood/human-essentials/actions/runs/15084551153

Will investigate...

[danielabar]

First failure is for the date range, so possibly something here is causing a cascade of failures:

Shared Example Group: "Date Range Picker" called from ./spec/system/purchase_system_spec.rb:83

     1.1) Failure/Error: expect(page).to have_css(".alert.notice", text: "Invalid Date range provided. Reset to default date range")

          Ferrum::TimeoutError:
            Timed out waiting for response. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the :timeout option to a higher value might help.
          # ./spec/support/date_range_picker_shared_example.rb:120:in 'block (3 levels) in <top (required)>'

[cielf]

Just FYI -- we had 3 different people run into this this week. Still seems weird, but people who do a lot of data entry probably use tabs to move around more than I do.

[danielabar]

Still investigating CI test failures - unfortunately since it passes locally, need to commit a bunch of temp changes to the test to see how it fails on CI.

Issue seems to be that JS runs overall slower on CI, and it's difficult to simulate exact user interaction in scenario that triggers server side validation. So when trying to simulate user submitting invalid data to server, when CI runs, the blur event is being triggered before form is submitted, so it displays the JS alert instead of the flash notice.

Continuing to investigate...

[danielabar]

@dorner @cielf Fixed the date range system tests that were failing on CI. Since it could only be reproduced on CI, ended up with a bunch of experimental commits on this branch. I know we're not supposed to rebase after PR is submitted, so I could leave them, or if you prefer, I could clean them up.

[cielf]

@dorner's call on that, methinks.

[dorner]

I'm good with this!

[github-actions]

@danielabar: Your PR [#4922] handle invalid date ranges in date range input is part of today's Human Essentials production release: 2025.06.01.
Thank you very much for your contribution!