[PP-1] Views Date Filter Datetime Granularity Option

Created on 8 April 2017, over 7 years ago
Updated 19 May 2023, over 1 year ago

Problem/Motivation

1. Create a content type with a Datetime field
2. Create some sample data with the content type
3. Create a simple view that has one exposed filter for selecting the Date
4. The exposed filter will force you on the 'is equal to' operator to make an exact match on specific datetime fields prior to listing

Cases:
1. Site allows users to create specific meeting times but the client wants search by month or day
2. Views does not allow the user to select the granularity of the search against the Datetime field, you can select the between operator, however if you have separate start/end dates it becomes more complicated since you would have to have the operator work between 4 specific dates... ugh.

Proposed resolution

Add simple form element to date exposed filter to allow the user to select the granularity of their date input

Remaining tasks

  1. Land ✨ [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter Needs work which is itself blocked on these 2:
  2. More robust tests (see #57, #61.
  3. Fixed in #79.
  4. Sort out timezone bugs from #66.
  5. Update summary with screenshots of the current UI, and flesh out "User interface changes" section in more detail.
  6. Decide if we want granularity to work on timestamp fields, too. If so, implement the required changes to core/modules/views/src/Plugin/views/filter/Date.php.

User interface changes

Add a new form element to the views exposed filter

API changes

Data model changes

Original report by generalconsensus

✨ Feature request
Status

Postponed

Version

10.1 ✨

Component
DatetimeΒ  β†’

Last updated 2 days ago

Created by

πŸ‡ΊπŸ‡ΈUnited States generalconsensus

Live updates comments and jobs are added and updated live.
  • VDC

    Related to the Views in Drupal Core initiative.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs screenshots

    The change alters the user interface, so before and after screenshots should be added to document the UI change. Make sure to capture the relevant region only. Use a tool such as Aviary on Windows or Skitch on Mac OS X.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡΅πŸ‡±Poland Graber

    The core date filters have many issues apart from this one and from my experience issues like this take years and years to progress, some look like they'll never be solved (check the entity reference filter issue for example where infra doesn't cope with the count of comments and d.o. results in a 404 every second request).
    I thought it'll be best to start from contrib hoping it'll be a part of core one day.

    It addresses the granularity issue by introducing "date" / "date and time" selector where date is converted to day range / ranges.
    https://www.drupal.org/project/date_filter β†’

  • @omarlopesino opened merge request.
  • First commit to issue fork.
  • @omarlopesino opened merge request.
  • πŸ‡ͺπŸ‡ΈSpain omarlopesino

    I had problems with #110 patch: the filter was not working correctly when filtering by month granularity at some specific months.
    Patch #128 works for me and do not have that problem. But the tests do not pass. So I've created an MR applying patch from #128 fixing the issues that were producing the tests to fail; https://git.drupalcode.org/project/drupal/-/merge_requests/3552

    I've also attached the patch + interdiff in case someone needs to check it.

  • πŸ‡¨πŸ‡¦Canada classiccut

    I ran into issues saving the a view using a date filter with granularity when using the latest patch. I tracked the problem down to the views filter schema. The patch incorrectly sets the granularity property as integer in the schema, whereas it should be set to string. Changing the schema granularity property type to string fixes the issue. I'm uploading a new patch that fixes this. Other than that, this patch seems to be working great, thanks all!

  • last update about 1 year ago
    29,653 pass
Production build 0.71.5 2024