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!

:peter

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
+++ sope-appserver/NGObjWeb/WebDAV/SoObjectWebDAVDispatcher.m d3e95639a9b4e09ad8133de275e977093dac670d
@@ -845,7 +845,8 @@ static NSTimeZone gmt
{
NSString absDestURL;
NSURL destURL, srvURL;

• unsigned int destPort, srvPort;

• if (path) *path = nil;

  / TODO: check proper permission prior attempting a move /
  @@ -865,14 +866,16 @@ static NSTimeZone *gmt
  }

  srvURL = [_ctx serverURL];

• srvPort = [srvURL port];
• destPort = [destURL port];

• [self debugWithFormat:@"move/copy:\n to: %@ (%@)\n server: %@)",
  [destURL absoluteString], absDestURL,
  [srvURL absoluteString]];

  / check whether URL is on the same server ... /
  if (![[srvURL host] isEqualToString:[destURL host]] ||

• ![[srvURL port] isEqual:[destURL port]]) {

• srvPort != destPort) {
  /
  The WebDAV spec is not really clear on what we should return in this
  case? Let me know if anybody has a suggestion ...
  @@ -937,7 +940,9 @@ static NSTimeZone gmt

  / TODO: we should probably use a subcontext?! /
  [_ctx setObject:yesNum forKey:@"isDestinationPathLookup"];

• *target_ = [root traversePathArray:targetPath
• / We check if the destination collection exist /
• *target_ = [root traversePathArray: [targetPath subarrayWithRange: NSMakeRange(0, [targetPath count]-1)]
  inContext:_ctx
  error:&error
  acquire:NO];

Together with this SOGo patch:

--- SoObjects/SOGo/SOGoContentObject.m 328bb5f39b5e9be7e05ca0dcf832e1fcaa53380b
+++ SoObjects/SOGo/SOGoContentObject.m d456053120d50371116d28ca7665e693a5bf32ce
@@ -411,11 +411,6 @@
return [NSString stringWithFormat: @"%u", length];
}

-// - (NSString *) davResourceType
-// {
-// return @"";
-// }

• (NSException ) davMoveToTargetObject: (id) _target
  newName: (NSString ) _name
  inContext: (id) _ctx
  @@ -424,11 +419,7 @@
  Note: even for new objects we won't get a new name but a preinstantiated
  object representing the new one.
  */

  • [self logWithFormat:
  • @"TODO: move not implemented:\n target: %@\n new name: %@",
  • _target, _name];
  • return [NSException exceptionWithHTTPStatus:405 / not allowed /
  • reason:@"this object cannot be copied via WebDAV"];
  • return [self moveToFolder: _target];
    }

• (NSException *) davCopyToTargetObject: (id)_target

The fix works for me (iCal.app v4.0.4).

Fixed with:

http://mtn.inverse.ca/revision/diff/af90264fc2b3a40aaf122d30a9d5f8c2eb889f0a/with/9dfff4b07c62ccec2c894fa0bb07d26001c7e7c0

and:

http://mtn.inverse.ca/revision/diff/0b64839fea2e383dcc57f754615f294e164d5826/with/7006e81f038867b26d3ed4119e35ad3a2763d2d4