Custom data for recurring event instances

Thanks for filing this issue. It's definitely on my list of priorities. Being able to associate a fieldable entity with a Smart Date instance would allow for specifying the kind of information you describe, and could also make it easier to use Smart Date for things like registration.

I have considered a number of possible approaches to achieve this, including:

• Create a new reference field type, that would allow referencing not just an entity but a field delta, or perhaps keyed to the rrule (recurrence rule) instance. The latter approach might be more reliable. The advantage of this approach is that it would probably be more flexible, but would likely require leveraging Inline Entity Form and possibly other modules
• Provide a purpose-built, fieldable entity designed specifically to referenced as a field for recurring date instances. This approach would likely be easier to set up, but less flexible in the ways it could be used

Any thoughts on these approaches, and which would better suit your needs?

Suppose we decided to just use nodes as the additional entity type, and in the field configuration you could pick a content type. We would want to support IEF-style creation of related content inline, and ensure that when viewing a child node, it would also show data from the parent instance, e.g. time, location, etc.

Would there be problems or limitations to just deciding to use nodes for this purpose?

The separate nodes approach was how Date Repeat Entity handled this for Drupal 7.

It found it worked pretty well and would say it is just the ticket for the example use case of publishing a meeting agenda.

When the module detected the creation of a repeating date sequence it generated separated dated nodes for each instance. Each node could then be customised as needed.

There was a configuration page where it was possible to to select which bundles should be treated in this way. And there was also a mechanism to dealing with with changes to dates

In the case of registrations, I have some reservations about whether this would be the right approach for consecutive events repeating by minutes or hours.

Interesting perspective. Not right for registration for more frequent events because of the number of nodes it would create?

1. Number of nodes is one concern.
2. Many registration events have bookable sessions; a conference say. I worry it could get a bit complicated, with views and reports.

Not saying not right, just some doubts.

Performance is certainly an important matter and so too is flexibility and fitness for purpose. Whist I have some doubts about the suitability of nodes for all use cases, there are also many scenarios where this will be the right approach.

In my work with schools I have found they have two distinct use cases for registrations.

1. Activity bookings.
One of my school clients runs a busy program of before and after school clubs. Essentially this is childcare for working parents.

There are four sessions each day, with a total daily capacity of 90 places. Each place must be booked and paid for by a parent. That adds up to about 16,000 transactions every year.

The transactional side of things can be handed off Drupal Commerce or a payments module. Whilst the registration side of things needs to be capable of good reporting, and of maintaining a booking history for each parent. Smart Date can play an import part by generating the bookable instances.

This use case is much the same as selling tickets for an event. Separate nodes can work well here, especially where each repeat might have a different theme; speakers at a conference for example.

2. Parent/teacher meetings
In the case of a primary school, a teacher will have a number of slots, repeating every 10 minutes for meeting with parents. Each slot must me agreed and confirmed in advance

In the case of a senior school, the process is much the same, but may need to be coordinated with availability of multiple teachers, during the same session.

This use case is more like that of an appointments system and it is here that I am not convinced that a node per bookable instance is the right approach.

The new functionality in Smart Date for hourly repeats and by minutes is also a good fit for this use case.

To me it's probably subjective as to whether or not the instance should really be immutable. If I have a six-week lecture series and the start gets delayed two weeks, should the application assume that the first two instances were cancelled and two new ones added, or should it assume that all instances are now two weeks later?

I think that as with all things date and time there will be specific cases where some people want each capability, but to me it seems perfectly reasonable to have it relative to the series.

Yikes. This is reminding me of a bad dream.

https://www.drupal.org/project/recurring_events/issues/3091075

@MrPaulDriver thanks for the additional context, definitely useful to leverage similar discussions that have already happened.

One thing worth mentioning here is that Smart has Override entities which can be used to make make an instance effectively "frozen", in the sense that further modifications to the series won't shift the time and date of the instance. If your preference is to make a specific instance no longer impacted by changes to the series, creating an override is a relatively simple way to do it.

I should also mention that Smart Date's Overrides include the ability to set an entity id. To date, this hasn't really been used. The original intention was that if someone wanted to completely override an instance (change title, author, description, whatever) it could effectively allow an instance to act as a self-contained entity where anything could be changed from the parent entity.

I should add that I've been thinking about a plugin architecture for Smart Date where a submodule (or companion module) could alter or supplement the output for a delta as its render array is assembled. In theory this could be used to put in "add to calendar" links, data from an associated override entity (e.g. talk title, speaker, etc), registration links, what have you.

In theory we could also add some kind of way for a submodule to throw errors when the parent series is edited, but perhaps if the use of overrides is sufficient then this wouldn't be necessary.

Looks like there's a couple other similar requests:

#3152300: Option to add notes to event instance?
#3122340: As an end user, I like to edit the body field of each of the recurring events

I commented on those indicating it might be best to close them as duplicates of this one.

I personally have a use case involving cancelling individual instances and providing a cancellation reason. Up to this point, I have been using a custom date field and widget to provide this ability:

I'm looking at migrating into Smart Date because I need recurring date functionality. Doing so means I'm going to lose this ability to cancel individual occurrences.

As you're probably aware, Smart Date Recur does give you the ability to cancel instances, in the "Manage Instances" modal, so what what you're really lacking is the ability to add a reason.

The data model for overriding/cancelling instances already allows for an association with an entity. What's currently lacking is a UI to create or associate an entity, and a way to use this association when dates are rendered. I built the Date Augmenter API partly to help solve the second part, but my next major initiative for Smart Date is a submodule (probably) to provide this UI and likely a Date Augmenter Plugin, to allow showing a configurable view mode (or perhaps just the label, linked) for an associated entity when rendering a date.

If you'd be interested in helping with this effort I could start a new issue/set of issues to flush out some of the details.

Ooooh interesting. I didn't realize overrides were content entities. I'll take a closer look into it this week and see how well this would work for us. If so, I can likely help get some code contributed to make it happen.

I'm not sure I would want to create a whole separate entity type just for storing the cancellation reason and then find a way to associate that entity with the override entity. I think it would be more straight forward for me to modify the base field definitions for the existing override entity to add a field for cancellation reason, then form alter the override form to add a widget for it.

There is a smart_date_override table that stores modified instances. The smart_date_rule table stores the generated instances as json.

What if there was a smart_date_instances table instead of smart_date_override, and it held all generated instances?

There would be a content entity based on this table, and it could be fieldable.

The ability to attach fieldable entities to Smart Date instance is what the Date Content Augmenter was made for. Closing this issue as outdated, since that module is designed to resolve this use case.