Visitar URL original
Fix DateRange Filter last day confusion regression · Issue #8282 · activeadmin/activeadmin · GitHub
Skip to content

Fix DateRange Filter last day confusion regression #8282

Open

Description

@scouttyg

Way back in #3529, ActiveAdmin had an issue where DateTime filter fields were confusing. The main challenge was the wording:

Screenshot 2024-03-19 at 11 17 55 AM

As @timoschilling mentioned (referencing his own image however, not the one above):

With this UI we create a request like ?q[date_lteq]=2014-10-29, put this queries the db with appointments.date <= '2014-10-29 00:00:00', but it should be appointments.date <= '2014-10-29 23:59:59', otherwise it not cover the last date of the range.

This behavior was later fixed / changed in #4504, but then in #8010 it was changed again (back to initial behavior), which @javierjulio did note was a breaking change:

When filtering by range with a datetime column (e.g. created_at), a custom predicate would modify the "to" value so it was always a day after in the generated database query. So if the "from" and "to" filters had the same supplied date, e.g. 2023-07-11, the query would query data in a 24 hour range.

Now that the custom predicate is removed that behavior is not present. To achieve a similar result with this change, the supplied "to" filter value has to be the next day. So going with the earlier example, the "from" is 2023-07-11 and the "to" would now have to be 2023-07-12 instead.

While the workaround provided does indeed work, I don't think it operates by the principle of least surprise -- if the wording of the filter says "Created at less than or equal to 2024-03-01" (emphasis mine), I'd expect the filter to include all entries that have the date 2024-03-01, not just the ones that equal 2024-03-01 00:00:00.

I think this could be mainly fixed via a wording change -- if it instead said "Created at less than or equal to 2024-03-01 00:00:00", I think it would make it at least clear that you would have to add a day to get all the 2024-03-01 entries, and perhaps you wouldn't need to add any special predicates to actually change the searching / filtering behavior.

Expected behavior

When I filter on a datetime field, even when coerced to a date, I expect the resulting entries to include all cases of that date, especially because of the wording "[...] or equal to YYYY-MM-DD".

Actual behavior

Only entries that match YYYY-MM-DD 00:00:00 will be returned for the final date

How to reproduce

Search a datetime filter (e.g. created_at, updated_at) using an ActiveAdmin page.

Activity

  1. changed the title [-]Fix DateRangeInput last day confusion regression[/-] [+]Fix DateRange Filter last day confusion regression[/+] on Mar 19, 2024
  2. letiesperon commented on Feb 21, 2025

    @letiesperon

    @scouttyg Were you able to find a nice workaround? I'm suffering from this too

  3. iangreenleaf commented on Apr 28, 2025

    @iangreenleaf
    Contributor

    @letiesperon I was able to monkey-patch this behavior with the following:

    # config/initializers/ransack.rb
    Ransack.configure do |config|
      config.add_predicate "gteq_datetime",
        arel_predicate: "gteq",
        formatter: ->(v) { v.beginning_of_day }
    
      config.add_predicate "lteq_datetime",
        arel_predicate: "lt",
        formatter: ->(v) { v + 1.day }
    end
    
    # config/initializers/active_admin.rb
    ActiveAdmin::Inputs::Filters::DateRangeInput.class_eval do
      def gt_input_name
        (column && column.type == :date) ? "#{method}_gteq" : "#{method}_gteq_datetime"
      end
    
      def lt_input_name
        (column && column.type == :date) ? "#{method}_lteq" : "#{method}_lteq_datetime"
      end
    end
    
    # config/locales/en.yml
    en:
      ransack:
        predicates:
          gteq_datetime: "Greater or equal to"
          lteq_datetime: "Lesser or equal to"
    
  4. iangreenleaf commented on Apr 28, 2025

    @iangreenleaf
    Contributor

    That said, I would certainly prefer to see this behavior reinstated without a monkey patch. It looks to me like the removal in #8010 was a mistake--that was meant to remove a compatibility layer left over from Metasearch, while the custom date predicates do not appear to be related to that, but rather were a feature-motivated change that happened independently.

  5. tagliala commented on Apr 30, 2025

    @tagliala
    Contributor
  6. lucasfais commented on Oct 1, 2025

    @lucasfais

    That monkey patch is broken with ransack 4.4.0, see #3529 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions