6.0.0-beta1
7/7/25

[#9880] Changing time of recurring events via drag/drop broken
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

History
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?

Saved Queries