Tickets :: [#9880] Changing time of recurring events via drag/drop broken

6.0.0-beta1

7/7/25

Summary	Changing time of recurring events via drag/drop broken
Queue	Kronolith
Queue Version	Git master
Type	Bug
State	Resolved
Priority	2. Medium
Owners	mrubinsk (at) horde (dot) org
Requester	mrubinsk (at) horde (dot) org
Created	04/12/2011 (5200 days ago)
Due
Updated	05/06/2011 (5176 days ago)
Assigned	04/29/2011 (5183 days ago)
Resolved	05/06/2011 (5176 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

05/06/2011 01:42:42 AM	Michael Rubinsky	State ⇒ Resolved

05/06/2011 01:42:34 AM	Git Commit	Comment #11	Reply to this comment
Changes have been made in Git for this ticket: ~~Bug: 9880~~ Fix creating exceptions by drag/drop in month view 1 files changed, 1 insertions(+), 1 deletions(-) http://git.horde.org/horde-git/-/commit/cea4c8db70730f6d7c8163a8c2eebdef46d5fe8c

04/29/2011 03:48:36 PM	Jan Schneider	Comment #10 State ⇒ Assigned	Reply to this comment
This doesn't work with month views yet.

04/16/2011 12:30:47 AM	Michael Rubinsky	State ⇒ Resolved Taken from Jan Schneider

04/16/2011 12:30:32 AM	Git Commit	Comment #9	Reply to this comment
Changes have been made in Git for this ticket: ~~Bug: 9880~~ Fix drag/drop editing of recurring events. If a recurring event occurence is moved or the time span is changed via drag/drop it is now automatically added as an exception to the recurring event. 2 files changed, 99 insertions(+), 17 deletions(-) http://git.horde.org/horde-git/-/commit/24e4771f380dabb49ade6d5eb31d4aebc2033083

04/12/2011 06:29:39 PM	Michael Rubinsky	Comment #8	Reply to this comment
Sorry, that last example is rdproducable by adjusting the start and enter times separately, not by dragging the entire event.

04/12/2011 06:26:05 PM	Michael Rubinsky	Comment #7	Reply to this comment
Another example: Create weekly recurring event. Relocate one of the recurrences other than the first one by dragging it to a later time. This causes the entire series to disappear other then the one just edited.

04/12/2011 06:16:35 PM	Michael Rubinsky	Comment #6	Reply to this comment
Actually, 2) is what we already do. What issues do you see? This seems to work fine for me. This only works if editing the first event in the series. To repro: Create weekly recurring event Edit, for example, the third occurence byvdraggin the end time to later. This happens because we are keeping all the original event's data - like the original st time - and changing the part that changed...in this example, making the event span a week or more.

04/12/2011 04:55:15 PM	Jan Schneider	Comment #5	Reply to this comment
Actually, 2) is what we already do. What issues do you see? This seems to work fine for me.

04/12/2011 02:47:47 PM	Michael Rubinsky	Comment #4 State ⇒ Assigned	Reply to this comment
After mulling over this while trying to sleep last night, I agree. I think automatically creating an exception would be the expectation here.

04/12/2011 09:22:20 AM	Jan Schneider	Comment #3	Reply to this comment
At first I considered 2) the correct choice. But 1) would probably be even smarter.

04/12/2011 01:28:26 AM	Michael Rubinsky	Comment #2 Priority ⇒ 2. Medium	Reply to this comment
Bumping to medium since it can lead to loss of event data from the calendar.

04/12/2011 01:27:30 AM	Michael Rubinsky	Comment #1 Patch ⇒ No State ⇒ Feedback Milestone ⇒ Assigned to Michael Rubinsky Assigned to Jan Schneider Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ Changing time of recurring events via drag/drop broken Queue ⇒ Kronolith	Reply to this comment
Using dynamic kronolith, editing the date or time of a recurring event by using drag/drop corrupts the recurring event data. This happens because the updateEvent call is made with the new times of the current instance of the recurring event, but the data stored for a recurring event should be the date/time of the original instance. Not sure the best way to handle this UI-wise. The choices I see are: (1) Automatically assume that the current instance should be edited, and add it as an exception. (2) Assume the entire series is being edited, and adjust the original entry (probably not the best idea, as this would probably NOT be what the user intended). (3) Disable drag/drop editing of recurring events. Thoughts?