In Google Calendar, when changing a repeating event's time, it gives one the option to only apply the change to the selected repeating date plus any dates that follow it.

When used this automatically changes the repeat length of the existing event to have finished with the last occurrence and creates a new event with the exact same details, albeit with altered date/time details.

Might something like this be possible to implement with the Date module?

Comments

arlinsandbulte’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev

+1. I would like to pursue this further.
Maybe even eliminate repeat exceptions in favor of something like this.

KarenS’s picture

We can't eliminate repeat exceptions I don't think. This topic would be quite difficult and I'm not sure I have the energy to even attempt it. If someone gets all excited and comes up with a patch, maybe. But any patch that does this will probably be pretty complex and hard to review. Keep in mind that we need a UI that will handle this nicely, the resulting dates, whatever they are, have to be stored, and the logic has to make its way into a RRULE that our code can understand. If it involves creating a new node, we have to keep them connected so they appear to be a single node OR we have to switch completely over to a system that creates one date per node, which itself is going to be massively complex. Just thinking about what it would take to make this work wears me out.

I agree it would be nice, but....

arlinsandbulte’s picture

Oh, yeah. I know, not easy, but potentially worth it IMO.
Consider this on my "Ultimate Wish List." I don't expect this to happen soon...

Here is a detailed explanation of this (wish list) proposal. It really mimics Google Calendar's method of handling repeating dates and exceptions.

When editing a node with a date field that uses a repeat rule, upon saving, three options should be presented:
1.) Update All Nodes
Pretty much standard as is right now. Nothing really special about this option.

2.) Update only this instance
Selecting this option does 3 things:
a.) The original node is saved, no changes or edits are applied, but the the end date of the repeat rule is modified to end before the 'current' instance.
b.) A new node is created and saved. All edits are applied to this node, but the repeat rule is stripped away.
c.) A new node is created and saved. Fields and properties of this node are identical to the original node before the edit, except the repeat rule is modified to start after the 'current' instance.

3.) Update only this instance and all instances following this instance.
Selecting this option does 2 things:
a.) The original node is saved, no changes or edits are applied, but the the end date of the repeat rule is modified to end before the 'current' instance.
b.) A new node is created and saved. All edits are applied to this node, but the repeat rule is modified to start on the 'current' instance.

If this were implemented, exceptions might be eliminated, IMO.
Repeat rules might be able to be simplified.
Performance might be improved, as not every date repeat value would need to be stored, and there might be a method to query directly against a repeat rule....

KarenS’s picture

There are also a bunch of modules that have tried to solve this, see http://drupal.org/node/894680. There is also http://drupal.org/project/ical.

We either need to let one of them take this over or I suppose use them for ideas.