View Issue Details

IDProjectCategoryView StatusLast Update
0001096SOGoBackend Calendarpublic2011-10-18 14:04
ReporterCarter_ Assigned Toludovic  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.4 
Target Version1.3.9Fixed in Version1.3.9 
Summary0001096: iCal from Mac OS X 10.6 - can't move events between calendars - CalDAVMoveEntityQueueableOperation
Description

Under iCal from Mac OS X 10.6
When changing calendar where a event is stored, we get this error :
HTTP/1.1 403 Forbidden
At operation CalDAVMoveEntityQueueableOperation

The problem seems appear from Mac OS X 10.6 : previous version don't have this issue.

TagsNo tags attached.

Relationships

has duplicate 0001051 resolvedludovic can't move an event between 2 calendars from iCal 

Activities

francis

francis

2011-01-26 14:10

administrator   ~0002048

The MOVE operation is not yet supported.

mark

mark

2011-05-10 08:51

reporter   ~0002453

Is this still not supported?

ludovic

ludovic

2011-05-10 19:59

administrator   ~0002457

It's not supported.

Marcel

Marcel

2011-05-12 12:01

reporter   ~0002468

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)

tlr

tlr

2011-07-21 10:23

reporter   ~0002734

Last edited: 2011-07-21 10:27

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.

cpohle

cpohle

2011-08-05 11:41

reporter   ~0002784

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.

pflaeging

pflaeging

2011-08-10 09:29

reporter   ~0002786

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

macomrade

macomrade

2011-08-12 15:11

reporter   ~0002793

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.

Marcel

Marcel

2011-10-17 17:08

reporter   ~0002919

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.)

ludovic

ludovic

2011-10-18 12:39

administrator   ~0002925

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

francis

francis

2011-10-18 13:35

administrator   ~0002926

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

ludovic

ludovic

2011-10-18 14:04

administrator   ~0002927

Fixed with:

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

and:

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

Issue History

Date Modified Username Field Change
2011-01-26 12:22 Carter_ New Issue
2011-01-26 14:10 francis Note Added: 0002048
2011-05-10 08:51 mark Note Added: 0002453
2011-05-10 19:59 ludovic Note Added: 0002457
2011-05-12 12:01 Marcel Note Added: 0002468
2011-07-06 19:32 ludovic Relationship added has duplicate 0001051
2011-07-21 10:23 tlr Note Added: 0002734
2011-07-21 10:27 tlr Note Edited: 0002734
2011-08-05 11:41 cpohle Note Added: 0002784
2011-08-05 12:40 francis Target Version => 1.3.9
2011-08-10 09:29 pflaeging Note Added: 0002786
2011-08-12 15:11 macomrade Note Added: 0002793
2011-10-17 17:08 Marcel Note Added: 0002919
2011-10-17 20:06 ludovic Status new => assigned
2011-10-17 20:06 ludovic Assigned To => ludovic
2011-10-18 12:39 ludovic Note Added: 0002925
2011-10-18 13:35 francis Note Added: 0002926
2011-10-18 14:04 ludovic Note Added: 0002927
2011-10-18 14:04 ludovic Status assigned => closed
2011-10-18 14:04 ludovic Resolution open => fixed
2011-10-18 14:04 ludovic Fixed in Version => 1.3.9