5103 catch bad date ranges

[wjwb-us]

Resolves #5103

Description

Improves the handling of invalid date_range parameters in the Purchases page and other index pages that use the date range filter.

With this change:

• Invalid date ranges are now gracefully handled.
• When invalid input is detected, the system falls back to the default dates specified in date_range_helper.
• A flash.now[:error] message is shown to inform the user that the input was invalid and the default was used instead.

Alternatives considered:

• Ignoring invalid input entirely (no feedback) — but this would be confusing for users.
• Locking input to only allow input though the selector - not used for accessibility reasons.
• JS regex check considered - deemed insufficient since requests can bypass client-side validation via direct URL manipulation.

Type of change

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

How Has This Been Tested?

• Manually tested the Pages that use date_range filter input
• Verified that:
  • The app does not raise an error
  • The default date range is applied
  • A helpful flash error is shown
• Added an RSpec tests for pages that use date_range filters

Screenshots

[cielf]

Hmmm.. The behaviour of the date range widget is definitely a little off, but it looks like it already was. Sometimes if you change the content of the date range to something that is not valid it 'silently' reverts back to what it was before, and sometimes it triggers the error and reverts to the default.

What we have here will prevent the 500 error, which is the desired outcome.

In an ideal world, we'd get feedback and a consistent result (either the default or reverting to what was before) in all these cases.

@wjwb-uk -- are you interested in digging deeper on this pull request, and making the whole thing work consistently with feedback, etc? That might be a bit of scope creep.

If not, would it be easy to have it revert to what was there before instead of the default?

[wjwb-us]

@cielf Happy to dig a little deeper tonight. I hadn't noticed the silent reverts to old values, my gut is telling me it's something to do with the client side date picker.

To revert to the previous value after an invalid input, we’d need to store the last valid range somewhere, I'm thinking either in the session or passed along with the form as a hidden input. I feel like the hidden input is probably the cleaner solution here, since it keeps things stateless and works well with existing param based filtering. I’ll take a closer look and see if I can make the behavior more consistent with that approach if that sounds good to you?

[cielf]

I'm not the last word on technical approaches - but from a functional pov, I don't think it really matters whether we revert to a default or to what was there (will be the same in most cases), as long as we're consistent.

[wjwb-us]

Merging main back in as I've been on vacation for a few weeks will revisit this week :)

[cielf]

Argh! @wjwb-uk I'm sorry -- it looks like we had a duplicate issue for this (see #4922), which is being actively worked on.

[wjwb-us]

@cielf No sweat, these things happen. Will close merge request and pickup another issue :)