Create views filter plugin for date range fields

For #2699477: Steps towards handling end dates in Calendar 8 we'd need some specific date range arguments.

At the moment we just add arguments filtering on a date range's start date, this gives problems for events overlapping multiple months.
For our use case I think there's 2 options:

• We allow configurable operators on existing date arguments. (This has been touched in #2544832: Views argument for the datetime module should use maths.).
  Once #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields is in we could create an arguments for both the start date en end date and set the operator to ">=" and "<="
• We create a new date range argument which filters between the start date en end date.

To be clear, I don't think we need the "Calculated Date" argument as proposed in #2544832: Views argument for the datetime module should use maths., I'm just talking about the configurable operators which is talked about in that issue.

I needed something like to be able to create a calendar view with date ranges. For now I opted for my first suggestion.
This patch if far from complete but I might unblock some people in #2699477: Steps towards handling end dates in Calendar 8.

Keeping to postponed until #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields is in.

#2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields is in.

There's no reason this is postponed anymore, right? Needs work given patch #4, "needs tests", etc, but someone could start moving this forward at this point, no?

Thanks,
-Derek

The attached patch builds on #4 and implements approach 2: i.e. it provides an operator to filter on date range. In fact solution 1 requires two arguments in a Calendar view, which was breaking pagers in my installation.

To achieve this cleanly the patch adds a DateRange argument extending the existing Date one. It also provides a subclass for each supported granularity, to be consistent with Datetime, however I'm not sure why we need this and we don't just provide a granularity selector on the parent class.

Tests still missing as this will likely need at very least some refinement.

Re-rolled.

Great, thank you! I'll review this further, but so far RTBC +1

Re-rolled 2924061-10.patch for 8.6.16

Actually, ignore me, 10 should still apply cleanly to 8.6.16, composer decided to mess with me by bumping my core version to 8.7 which is where the patch failed to apply

#14 is working for me with 8.7.1 while #16 failed to apply.

#14 working for me as well & #16 failed to apply on 8.8.x branch, also no interdiff added for #16 so removing this patch from the issue for now. @codeclarified - if you want you can add your patch again with an interdiff so that It will be really helpful for reviewers to review (See here details about how to create an interdiff).

Both #14 and #16 fail to apply for me on 8.7.3

Scratch that, I wasn't applying them correctly.

This sounds very useful but I can't quite follow what this patch is supposed to do beyond "specific filters that take into account both start and end date". Would it be possible for someone to please update the IS with a full explanation of the goals here? For example, what filters, arguments and sort options it will offer.

Or will specific filters etc. be possible via plugins with this patch?

Hi, the patch works if I create a field using the Drupal UI. It doesn't if the field has been created programmatically. Do I need to implement something extra on my code?

The following is the field definition on my Entity:

    $fields['date'] = BaseFieldDefinition::create('daterange')
      ->setLabel(t('Event Date'))
      ->setDescription(t('Event start/end date.'))
      ->setDisplayOptions('view', array(
        'label' => 'above',
        'type' => 'string',
        'weight' => 2,
      ))
      ->setDisplayOptions('form', array(
        'type' => 'daterange_default',
        'weight' => 2,
      ))
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE)
      ->setRequired(TRUE);

I've also reported the problem on the following issue: https://www.drupal.org/project/drupal/issues/2786577?page=1#comment-1337...

So far, the patch in #14 adds datetime_range variants of the argument handlers. It can filter on both start and end value at once (via the "Range intersects" operator in the new datetime_range* argument handlers), and allows configuring an operator for datetime field arguments in the first place.
However, the new datetime_range argument handler does so far only seem to support the intersect_range operator, and only adds an empty condition for all other operators? Potentially useful filtering might include queries such as (START and END being the argument/filter inputs):

The results I'm looking for must have started on/before (or on)/after (or on) START and complete on/before (or on)/after (or on) END

What I'm missing so far is

1. a filter plugin (similar to the argument handler)
2. a sort plugin (e.g. sort by duration, since start/end sorting is already possible in Core)
3. an update to the config schema for the new handlers & options (see datetime.views.schema.yml)
4. possibly support for optional start/end dates (see #2794481: Allow end date to be optional)

I've added some filters in Views Daterange Filters. It would be good to add the equivalent ones here as a minimum.

I'm having the expected results by applying patch from #14 and adding two contextual filters in my view. Both filters refer to the same date field (date range starting date to be exact). The first one contains formula "greater than or equal" and the second one has formula "less than or equal". Now I add URL parameters to my view like 2020-01-01/2020-02-01 and I get rows with date from Jan 1st to Feb 1st.

Maybe this explanation could help someone write the issue summary in a meaningful way.

Everybody uses dates, but date management in D8 is very very much worse than date management in D7: How is it possible ? Is it a (stupid) choice ? A mistake ? An oversight ?
I dont understand, because many unnecessary gadgets have been added into D8.

#29: Drupal 8 core was almost a complete re-architecture. As such, modules generally had to be rewritten. So in order to make D8 shippable within a reasonable time frame, minimal requirements were set for planned features, which includes date functionality. Enhanced features were left for later.

Rather than complaining about it, you can help move things along by either directly helping with these issues yourself (by uploading patches, etc.), or paying someone else to do it. That's how open-source software development works.

Drupal 8 core was almost a complete re-architecture. As such, modules generally had to be rewritten.

OK, and for what ? A modern gaz factory (french expression) ?

So in order to make D8 shippable within a reasonable time frame, minimal requirements were set for planned features, which includes date functionality. Enhanced features were left for later.

How many years or major versions will we have to wait for a decent date module ? D10, D11, ... ?

Rather than complaining about it, you can help move things along by either directly helping with these issues yourself (by uploading patches, etc.), or paying someone else to do it.

Well done man, the argument that kills. Rather, I suggest you do it right, starting with the basics: managing dates is part of the basics.

I understand your frustration @brulain but I think you should stand down; this isn't how we cooperate and get stuff done around around here. Maybe Drupal isn't for you?

I agree that development of the date ecosystem has been hit and miss with Drupal 8. Hopefully this will improve as we move forward.

And yes, I agree that dates should be part of the basics; but the trouble is dates are not basic, they are very complicated. Time zones, different faith calendars, not to mention different ways of storing such information in a database.

Picking fights doesn't help. Please stop.

Thanks for your answer @MrPaulDriver.

I understand your frustration @brulain but I think you should stand down; this isn't how we cooperate and get stuff done around around here.

This is more than frustration: it hasn't changed for 4 years.

Maybe Drupal isn't for you?

So Drupal (8) isn't for me because the date module is still pathetic.

I agree that development of the date ecosystem has been hit and miss with Drupal 8. Hopefully this will improve as we move forward.

I do hope it will improve and not regress: but when ?...

And yes, I agree that dates should be part of the basics; but the trouble is dates are not basic, they are very complicated. Time zones, different faith calendars, not to mention different ways of storing such information in a database.

I know that. But Drupal 8 implements many other more complex features (maybe more attractive): it is a matter of choice and prioritization.

Picking fights doesn't help. Please stop.

Yes, sometimes it does.
I stop here, all is said. I have to be patient and have faith.

Here's a try for the filter plugin for date range field:

I tried this with the most common application that I believe a date range filter could have: event search.

I may have over-engineered this in an effort to cover all possibilities.

Here's a list of the possibilities based on the following diagram:

• Event starts before my search date (Event 1,2,3 & 9)
• Event starts on or before my search date (Event 1, 2, 3, 4 & 9)
• Event starts on my search date (Event 4)
• Event starts on or after my search date (Event 4, 5, 6, 7, 8 & 10)
• Event starts after my search date (Event 5, 6, 7, 8 & 10)
• Event ends before my search date (Event 1)
• Event ends on or before my search date (Event 1 & 2)
• Event ends on my search date (Event 2)
• Event ends on or after my search date (Event 2, 3, 4, 5, 6, 7, 8, 9, 10)
• Event ends after my search date (Event 3, 4, 5, 6, 7, 8, 9, 10)
• Event happens on my search date (Event 2, 3 & 4)
• Event happens between my search start & search end date (Event 10)
• Event happens between my search start & search end date (Including outer limits) (Event 4, 5 & 10)
• Event happens during the time between my search start & search end date (Event 3, 4, 5, 6, 9, 10)
• Event happens during the time between my search start & search end date (Including outer limits) (Event 2, 3, 4, 5, 6, 7, 9, 10)

What this patch does:

- Adds a new all-in-one filter for date range field (in addition to existing ones for end and start date components of the field) to cover all above possibilities.
- Uses HTML5 date field for exposed form for the field with date only storage.
- Uses combination of HTML5 date & time field for exposed form for the field with date & time storage.

Things still to do:

- Add argument (from #10) & sort plugins.
- Add tests
- Update hook to add schema for sites where this module is already installed

Gotchas:

- Filter for a field with both date & time storage doesn't work properly because states don't work for datetime field. See: https://www.drupal.org/project/drupal/issues/2419131

Added a couple of comments and removed a debug statement.

Arrggghhh... I created the patch for 8.8.x.
Will upload a new patch for 9.x version as well.

Thanks for your work on this!

However, I think this is turning into big scope creep. For example, we should fix #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter generally, not have daterange-only filters do it differently/better than date filters.

1. +++ b/core/modules/datetime_range/datetime_range.views.inc
   @@ -6,12 +6,12 @@
   +use Drupal\datetime\Plugin\Field\FieldType\DateTimeItem;
   

   This looks unused (which is good, since I don't think we should care at the Field API level about anything in here).

2. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +   * Constructs a new Date handler.
   

   s/Date/DateRange/

3. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +   * Do some minor translation of the exposed input.
   

   I think this wants {@inheritdoc}, instead.

   Maybe move this to an inline comment at the start of the body?

4. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +    // Rewrite the input value so that it's in the correct format so that
   +    // the parent gets the right data.
   

   "the" would fit on previous line.

5. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +    $rc = parent::acceptExposedInput($input);
   

   "$rc" is a bit terse as a variable name. Can we be more verbose / self-documenting?

6. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +        'title' => $this->t('Starts on/at'),
   ...
   +        'title' => $this->t('Ends on/at'),
   

   "on/at" seems weird.

7. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +  /**
   +   * Provide a list of all the operators.
   +   */
   +  public function operatorOptions($which = 'title') {
   

   A) Missing @param docs for $which.

   B) Missing docs for @return

   C) s/Provide/Provides/

8. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +  /**
   +   *
   +   */
   

   @todo ;)

9. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
   @@ -0,0 +1,673 @@
   +        '#type' => 'date',
   ...
   +        '#type' => 'datetime',
   ...
   +        '#type' => 'date',
   ...
   +        '#type' => 'datetime',
   ...
   +        '#type' => 'date',
   ...
   +        '#type' => 'datetime',
   

   Slick, but basically out of scope. Or at least we should postpone this on solving it for 'date' filters, first. See #2648950.

10. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
    @@ -0,0 +1,673 @@
    +    // Get the user input in date/time storage format for proper
    +    // comparision in the sql query.
    

    A) s/comparision/comparison/

    B) Would fit on previous line (and maybe "in", too).

    C) s/sql/SQL/

11. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
    @@ -0,0 +1,673 @@
    +    // See the following comment on drupal.org issue for logic behind
    +    // all the following combinations:
    +    // https://www.drupal.org/project/drupal/issues/2924061#comment-13684573
    

    Nice, but I don't think this will fly. ;)

    A) You want @see if you're linking to a URL.

    B) I doubt core committers will go for this as a substitute for actual inline docs that explain WTF is going on. ;)

12. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
    @@ -0,0 +1,673 @@
    +    switch ($this->operator) {
    +      case 'starts_on':
    ... (basically, the whole rest of the patch)
    

    This sure seems like a lot of code and complication. Maybe this is the only way. Haven't had my face deep in the views date* handling recently, so I don't know off the top of my head if this is all necessary, if it already basically exists elsewhere, etc, but raising flag of "wow, do we really need all this?"

13. +++ b/core/modules/datetime_range/src/Plugin/views/Filter/DateRange.php
    @@ -0,0 +1,673 @@
    +  /**
    +   *
    +   */
    +  protected function startsOn($startDateField, $value) {
    ...
    +  /**
    +   *
    +   */
    +  protected function startsBefore($startDateField, $value) {
    

    Lots of missing PHPDocs here. Not flagging them all. Probably not worth documenting until we decide if we actually need all this.

14. Definitely still 'Needs tests'.

Thanks again for your effort on this! I think maybe 'postponed' is best, and we make sure existing date* filters use a date form element first. Then we can circle back and do all this. But I won't unilaterally make that decision.

Cheers,
-Derek

p.s. The bot flagged 20 code style errors at https://www.drupal.org/pift-ci-job/1721356 -- those will eventually need to be addressed, too (might be some overlap with what I already pointed out above).

Yeah, let's postpone this and get all hands on deck at #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter (and its blockers 🤦‍♂️).

Thanks,
-Derek

Also, since #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields is already in (and there are a bunch of views handlers of various types for datetime_range) the scope of this is only the dedicated datetime_range filter plugin, right?

we should fix #2648950: [PP-3] Use form element of type date instead textfield when selecting a date in an exposed filter generally, not have daterange-only filters do it differently/better than date filters.

Couple of thoughts on this (I might be wrong and missing something here):

1. Date filter is currently an extension of the numeric filter, which makes sense since there is just one data point for comparison. However, Date range filter has two data points for comparision which makes it a little differnt. Shouldn't that warrant that we treat this differently than date filter.
2. While date field is being worked on to use datetime form element, can't we work on this in parallel?

This sure seems like a lot of code and complication. Maybe this is the only way. Haven't had my face deep in the views date* handling recently, so I don't know off the top of my head if this is all necessary, if it already basically exists elsewhere, etc, but raising flag of "wow, do we really need all this?"

Yep, I do believe I over-engineered it. But I do believe we should work on it so that we provide at least the following major filtering functionalities for something like events search:

1. Events happening on a particular date. (What can I do on Sunday?)
2. Events happening during a date range. (What can I do next week?)

Lastly, Thank you for your review of the patch. I'll definitely be more careful in future to avoid all the mistakes I did in this patch.

#37:

But I won't unilaterally make that decision.

#39 (45 minutes later) - I do what I just said I wouldn't do. 🤦‍♂️
#41: You're totally right, these can definitely happen in parallel. 👍Thanks for (rightfully) pushing back.

Thanks for the patch, and you're welcome for the review. 😉 No worries about mistakes in the patch. That's why we have such a thorough review process / culture. It's how we learn. ;) Vastly better to contribute something (with "mistakes") and have to improve it, than to not contribute at all (a far greater "mistake").

Thanks/sorry,
-Derek

#39 (45 minutes later) - I do what I just said I wouldn't do.

No worries at all!! Happens to the best of us.

Vastly better to contribute something (with "mistakes") and have to improve it, than to not contribute at all (a far greater "mistake").

Amen!

Added to Bug Smash Initiative because I think a lot of people (also me) thinking it is already integrated/possible to filter for a core provided date_range field based on start and end date with views.

Example: Display all events x days before they start and until they end.

Haven't figured out how to configure this with a date_range field and views yet. Please correct me if I'm wrong (currently really late in germany now...)

@dipakmdhrm , @dww , I have made changes to the patch based on the inputs by #37.
Also I found some problem while saving the view with some default values to the filter config form, it was mainly happening because the the filter schema expects value as "String", but the Datetime was storing drupalDateTime() object to it.
I have added a solution to it , and also added test scenarios to test the new plugin.

Please review !.

Thanks

Fixing some Cspell issues and coding standards.

Working on re-roll

Tried to fix some of custom command failure errors

Needs to add "Doc comment" for some methods in file "DateRange.php" to fix the "custom command failed" Issues.

Update the patch as per #52. Please have a look.

Turned out problems on our project originated elsewhere and patch from #14 still works fine. Added the current work to a fork, maybe it'll be easier to review.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.