The bug seems to be happening whenever you update the start time of a repeating event, so it should be pretty easy to see when it is happening. On the other hand, I'm not sure if it is happening 100% of the time, so if it looks like it is working fine, try to edit it again.

I think part of this bug has to do with the change in workflow.

Version 1.30 of eventrepeat works like this:

1. User creates an event
2. User saves a repeat event for that event, spawning additional events
3. User possibly updates the event information, calling _eventrepeat_update_nodes
4. User possibly updates the repeat schedule, calling _eventrepeat_form_submit

Bringing the repeat form into the node form (post version 1.31) makes the workflow look something more like this:

1. User creates an event, saves the repeat data, and spawns the additional nodes, all in one action.
2. User goes back and changes the event information and repeat information.

For this second action, I am calling _eventrepeat_form_submit (renamed to _eventrepeat_save_repeat), followed by a call to _eventrepeat_update_nodes. Both need to update the event timestamps: the first to possibly remap nodes and the second to possibly update the time of day on any siblings to this node. One possibility is that this one-two step is double adjusting the times. Hope that helps.

CommentFileSizeAuthor
#5 repeat_update.patch24.14 KBhunmonk

Comments

hunmonk’s picture

hunmonk commented
Assigned: Unassigned » hunmonk

the event_repeat_calendar_map table is generated using UTC timestamps, and i remember having problems w/ user edits of repeat patterns because the user is not operating in UTC most of the time--for example, 7pm EST is actually _tomorrow_ in UTC. i had originally put in some correcting code to solve this issue, but it sounds like the change in workflow has disrupted it. :)

i'll try to have a look at this very soon.

hunmonk’s picture

hunmonk commented

apologies for not getting to this sooner. i can have a look at it after the code freeze if it's still open at that time...

hunmonk’s picture

hunmonk commented

this is still on my radar. plan is to get it fixed within the next week.

hunmonk’s picture

hunmonk commented

i've started looking into this, but it looks like it's going to take awhile to track down the problem. i'll work on it more over the next week or so...

hunmonk’s picture

hunmonk commented
StatusFileSize
new repeat_update.patch24.14 KB

attached patch corrects the issue--couple of things were wrong:

  1. the update function in eventrepeat was getting called every time a node_save was called during _eventrepeat_update_nodes. we only want this to be run once, so i put in a static indicator to test.
  2. the node times should really be updated before the repeat pattern, since the module bases it's repatterning partially on the time of the node adjusted for GMT.
  3. the repatterning should only happen if the first update happens successfully--so i made that conditional

      the patch is rather large, because it also removes a bunch of extra whitespace that shouldn't be in there anyways.

hunmonk’s picture

hunmonk commented
Status: Active » Reviewed & tested by the community
seanbfuller’s picture

seanbfuller commented
Status: Reviewed & tested by the community » Fixed

Looks great so far.

Given the complexity of the eventrepeat module, I invite everyone to come by and test this. I'm hoping to have a new 4.7 version by next week.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)