First off, excellent module! All around (UI, functionality) it's a huge improvement over other repeating date/node modules.

I'm having some unexpected behavior and trying to determine if it's by design (and if so why) or a bug.

When I update the Start Date of future instances of an existing Event (individual or recurring), those instances are deleted and re-created. This is a problem because users will be modifying instance Title, Description and other fields (we are using Inherited Formatter, but sometimes fields will be changed). When the instance(s) are deleted and re-created, we lose all of these changes.

Interestingly, the instances are NOT deleted and re-generated if you only change the End date/time. Instances are also NOT deleted and re-generated if they are in the past, even if you do change their Start date/time.

Clean install of:
drupal-6.22
ical-6.x-1.x-dev (also happening with alpha3)

Any thoughts? Is this the intended behavior? Reviewing http://drupal.org/node/1142512, it seems that it might be sufficient to re-save the instances with updated date/time, not delete them.

Comments

technivant’s picture

technivant commented

After further testing, here are some clarifications:

In ical-6.x-1.0-alpha3, with ical Status field enabled, changing only the End date of an existing instance will correctly update that instance.

In ical-6.x-1.x-dev, with ical Status field enabled, changing only the End date of an existing instance will NOT update that instance, it doesn't delete it either. It doesn't reflect the change in instance, but it does persist in the Event.

In ical-6.x-1.x-dev, with ical Status field REMOVED, changing only the End date of an existing instance will correctly update that instance.

But in all three of these cases, changing the Start date of an existing instance will DELETE the instance and generate a new one.

Crell’s picture

Crell commented
Status: Active » Closed (works as designed)

That's by design, or rather a known side-effect of design.

The way icalinstance works is by generating out a list of future instances, and then checking to see if they exist already. If they do not, it creates them. If they do, it updates them.

HOWEVER!

It can only detect an existing instance by its start date. There's no reliable way to say "OK, this instance was here, but is now here, so we'll move it". So there is then a garbage collection phase that searches for any orphaned instances and deletes those. Since we calculate out potential instances by start date, changing values other than the start date/time won't create orphans.

That does, sadly, lead to potential issues when an instance node has been updated. However, there is no way (that we could figure out) to determine which instance is which when changing the start date. So... yeah, known quirk of the design that we don't know a way around. :-(