Support date_recur field type.

On ics_field 3.0.0, this patch does apply cleanly, however it creates an error that's thrown on most pages and results in my having to drop the database because even config import can't undo it.

Steps to reproduce:

1. Apply patch.
2. Add a Calendar download field to content type that has a date_recur field
3. In field settings, select the date_recur field. The error will thrown after the AJAX request. In watch dog you'll see: Error Drupal\Core\Field\FieldException: Attempted to create an instance of field with name field_ics_download on entity type node when the field storage does not exist. in Drupal\field\Entity\FieldConfig->getFieldStorageDefinition() (line 316 of /app/docroot/core/modules/field/src/Entity/FieldConfig.php) This error will be shown on most subsequent page loads.

I'd also say that in order to actually support date_recur, we would want to add recurring events to the ICS file using RRULE. The date_recur module actually stores the RRULE string in the database in the field table, so we should be able to get it from there.

I realized my previous comment is unrelated to this specific issue so I created a new one: https://www.drupal.org/project/ics_field/issues/3436571 🐛 Field storage does not exist error Active

I've open a merge request:

https://git.drupalcode.org/project/ics_field/-/merge_requests/18#6bc0130...

Patch:

https://git.drupalcode.org/project/ics_field/-/merge_requests/18.patch

It expands on the patch from #4 to fully support date_recur field type by adding an RRULE property to the generated ICS file. With the addition of the RRULE property, every occurrence of an event will appear on the calendar, instead of only the first. This is what someone using a date_recur field would expect.

Other changes

Refactored dateslist/dates_list array structure

The dateslist/dates_list array structure is refactored from something like this:

[
  "1970-01-01 01:00:00 Europe/Zurich",
  "1971-02-02 02:00:00 Europe/Zurich",
]

To something like this:

[
  [
    'startdate' => "1970-01-01 01:00:00 Europe/Zurich",
    'enddate' => "1970-01-01 02:00:00 Europe/Zurich",
    'rrule' => 'RRULE:FREQ=DAILY;COUNT=10'
  ],
  [
    'startdate' => "1971-02-02 02:00:00 Europe/Zurich",
    'enddate' => "1971-02-02 03:00:00 Europe/Zurich",
    'rrule' => 'RRULE:FREQ=WEEKLY;COUNT=5'
  ],
]

This is because of the need to associate an RRULE with each start date of a multi value field. Additionally, an RRULE needs an end date, so that has been added as well. This may interfere/overlap with this issue. ✨ Include end date / time in ICS file. Needs work

I have not actually tested a multi value field, so this needs reviewing. With a date_recur field there is no need for multiple values since it allows you configure a pattern of occurrences based on the start date rather than several explicit start dates.

I tried to fix the tests, but I don't have a way to run phpunit at the moment so I probably messed up.

Fixed Outlook compatibility

The current version of the module generates ICS files that are incompatible with Outlook. Outlook will not import them. I have no idea how, but somehow I stumbled on a fix for this with my changes. Originally I was looking into fixing this the way that the addtocal_augment module fixed it, by not setting timezones, and instead setting dates using UTC 🐛 ics import problems due to malformed VTIMEZONE definition Fixed . However, that turned out to not be necessary.

I found that Composer will not apply the patch generated from the merge request, so here is a manually created patch.

New patch that fixes passing incorrect parameter type to \Eluceo\iCal\Property\Event\RecurrenceRule::setUntil

Realized my change to \Drupal\ics_field\ICalTimezoneGenerator::getMinMaxTimestamps was causing the file to be generated without BEGIN:DAYLIGHT, TZOFFSETFROM etc. Fixed with this patch.

This made me realize why my changes appeared to fix Outlook support. It's because prior to this patch I had accidentally removed the TZOFFSETFROM property. This module formats TZOFFSETFROM incorrectly, which Outlook (at least Outlook for Mac) then refuses to import. By accidentally removing that property entirely I had "fixed" Outlook. Now I realize there's a separate issue for this: https://www.drupal.org/project/ics_field/issues/3004699 →