View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001096||SOGo||Backend Calendar||public||2011-01-26 07:22||2011-10-18 10:04|
|Target Version||1.3.9||Fixed in Version||1.3.9|
|Summary||0001096: iCal from Mac OS X 10.6 - can't move events between calendars - CalDAVMoveEntityQueueableOperation|
Under iCal from Mac OS X 10.6
The problem seems appear from Mac OS X 10.6 : previous version don't have this issue.
|Tags||No tags attached.|
The MOVE operation is not yet supported.
Is this still not supported?
It's not supported.
You can use cut and paste instead (cut, select target calendar, paste).
However, this is no option for events where I invented others (they will be uninvited first) or events to which I have been invited (I will have to decline first).
(See also http://www.sogo.nu/bugs/view.php?id=1299 for a similar issue with the Web Calendar)
cut and paste doesn't work well with Lion.
Fundamentally, this bug (and Apple's redesign of iCal) make it impossible to work with multiple calendars hosted on SoGo from Lion iCal. It further makes it impossible to properly file events with invitations. I suggest bumping the priority of this bug and 0001051.
This bug leads to user-facing poor performance. It is in no way minor.
My support for tlr - in a team environment this function is critical, thus this issue should be set to "major".
Until this is solved, only the web interface can be used as a workaround for changing the calendar.
I've circumvented the problem under Lion by creating a local "temporary" calendar.
If you want to move a date from one calendar to another, you move it to the local calendar and then to the destination. Works for me, but is not very beautiful!
Im experiencing this exact same issue as well. (Lion, iCal 5 (1535)) Very annoying. Pflaeging's workaround does seem to function but isn't very elegant either. Seems to be isolated to iCal only as our company iPhones sync correctly when moving entities as does the SOGo web interface.
I am glad this will finally make it into 1.3.9, thanks guys!
macomrade: According to my experiments, iOS does not handle it correct, either (tested with iOS 4 and iOS 5), it just ignores the error and does not update the server. However, it never seems to reload the server state, so on the iPhone, it seems as the move had been successful. (Sometimes, the changes also lead to two entries, i.e., the move operation becomes a copy operation instead.)
Please this SOPE patch:
--- sope-appserver/NGObjWeb/WebDAV/SoObjectWebDAVDispatcher.m 334c3a6f94a2f17ad118c39c6378a5d907383b6b
Together with this SOGo patch:
--- SoObjects/SOGo/SOGoContentObject.m 328bb5f39b5e9be7e05ca0dcf832e1fcaa53380b
-// - (NSString *) davResourceType
The fix works for me (iCal.app v4.0.4).
|2011-01-26 07:22||Carter_||New Issue|
|2011-01-26 09:10||francis||Note Added: 0002048|
|2011-05-10 04:51||mark||Note Added: 0002453|
|2011-05-10 15:59||ludovic||Note Added: 0002457|
|2011-05-12 08:01||Marcel||Note Added: 0002468|
|2011-07-06 15:32||ludovic||Relationship added||has duplicate 0001051|
|2011-07-21 06:23||tlr||Note Added: 0002734|
|2011-07-21 06:27||tlr||Note Edited: 0002734|
|2011-08-05 07:41||cpohle||Note Added: 0002784|
|2011-08-05 08:40||francis||Target Version||=> 1.3.9|
|2011-08-10 05:29||pflaeging||Note Added: 0002786|
|2011-08-12 11:11||macomrade||Note Added: 0002793|
|2011-10-17 13:08||Marcel||Note Added: 0002919|
|2011-10-17 16:06||ludovic||Status||new => assigned|
|2011-10-17 16:06||ludovic||Assigned To||=> ludovic|
|2011-10-18 08:39||ludovic||Note Added: 0002925|
|2011-10-18 09:35||francis||Note Added: 0002926|
|2011-10-18 10:04||ludovic||Note Added: 0002927|
|2011-10-18 10:04||ludovic||Status||assigned => closed|
|2011-10-18 10:04||ludovic||Resolution||open => fixed|
|2011-10-18 10:04||ludovic||Fixed in Version||=> 1.3.9|