Fwd: Re: [chandler-users] "Read" status reset on sync w/Zimbra Tasks.
|
|
Davor Cubranic
|
Forwarding John's bug fix to the dev list for consideration in the next
code release. Davor Here's a link to the report. https://bugzilla.osafoundation.org/show_bug.cgi?id=12798 -John Davor Cubranic wrote: > Hi John, > > This is great, a bug report with a fix! Those are the best kind! > > I would encourage you to enter it into the Bugzilla yourself. That way > if the devs want you to make changes or test it on any further, you'll > get the email directly. > > Davor > > > On Wednesday 29 April 2009 19:58:33 John McCullough wrote: > >> More digging suggests a quoting problem. >> >> 2009-04-29 19:36:01,772 osaf.sharing.recordset_conduit DEBUG: Need to >> fetch: etag mismatch for d38c2a94-29ff-11de-94fd-8abe0bdda660.ics >> (44800-1241058902000 vs "44800-1241058902000") >> >> The following hack seems to have addressed the problem for me: >> >> Index: chandler/parcels/osaf/sharing/recordset_conduit.py >> =================================================================== >> --- chandler/parcels/osaf/sharing/recordset_conduit.py (revision >> 16675) +++ chandler/parcels/osaf/sharing/recordset_conduit.py >> (working copy) @@ -1342,7 +1342,7 @@ >> for path, etag in self.resources.iteritems(): >> if path in paths: >> state = paths[path][1] >> - if etag != state.etag: >> + if etag != state.etag and etag[1:-1] != state.etag: >> # Need to fetch this path since its etag doesn't >> match doLog("Need to fetch: etag mismatch for %s " "(%s vs %s)", >> path, state.etag, etag) >> >> >> Should I post a bug report? Or would someone who already has a >> bugzilla account be willing to post one for me? >> >> -John >> >> John McCullough wrote: >> >>> Hello, >>> >>> I recently started using Chandler Desktop and I like the general >>> concept, but I have been running into a problem syncing against a >>> Zimbra CalDav Server. The first manifestation was that my >>> Dashboard/Tasklist would completely re-order when syncing. Digging >>> a little I discovered that this was because the items were being >>> flagged as unread during the sync. (I checked that tasks synced ok >>> with the chandler hub, and they did). I did a little code diving >>> to find where the items were tagged as unread and checking the logs >>> it seems like the tasks are being viewed as changed even though I >>> am not aware of any process changing them. >>> >>> Here is a log snippet that should cover a single record: >>> >>> 2009-04-29 16:44:18,682 osaf.sharing.recordset_conduit DEBUG: >>> Applying changes to 2d7fb878-3517-11de-8881-b6446c042ed3 >>> [Diff(set([NoteRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', >>> NoChange, NoChange, None, None, NoChange), >>> ItemRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', NoChange, '100 >>> 0.0 0', NoChange, NoChange, NoChange, NoChange)]), >>> set([ModifiedByRecord('2d7fb878-3517-11de-8881-b6446c042ed3', u'', >>> Decimal("1241048456"), 500)]))] >>> 2009-04-29 16:44:18,683 osaf.sharing.recordset_conduit INFO: ** >>> Applying to UUID: 2d7fb878-3517-11de-8881-b6446c042ed3 / alias: >>> 2d7fb878-3517-11de-8881-b6446c042ed3 >>> 2009-04-29 16:44:18,683 osaf.sharing.recordset_conduit INFO: ** ++ >>> NoteRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', NoChange, >>> NoChange, None, None, NoChange) >>> 2009-04-29 16:44:18,683 osaf.sharing.recordset_conduit INFO: ** ++ >>> ItemRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', NoChange, '100 >>> 0.0 0', NoChange, NoChange, NoChange, NoChange) >>> 2009-04-29 16:44:18,683 osaf.sharing.recordset_conduit INFO: ** -- >>> ModifiedByRecord('2d7fb878-3517-11de-8881-b6446c042ed3', u'', >>> Decimal("1241048456"), 500) >>> 2009-04-29 16:44:18,695 osaf.sharing.recordset_conduit INFO: Moved >>> single item 2d7fb878-3517-11de-8881-b6446c042ed3 to NOW; >>> Diff(set([NoteRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', >>> NoChange, NoChange, None, None, NoChange), >>> ItemRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', NoChange, '100 >>> 0.0 0', NoChange, NoChange, NoChange, NoChange)]), >>> set([ModifiedByRecord('2d7fb878-3517-11de-8881-b6446c042ed3', u'', >>> Decimal("1241048456"), 500)])) >>> 2009-04-29 16:44:18,696 osaf.sharing.recordset_conduit INFO: >>> Marking item unread: 2d7fb878-3517-11de-8881-b6446c042ed3; >>> Diff(set([NoteRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', >>> NoChange, NoChange, None, None, NoChange), >>> ItemRecord(u'2d7fb878-3517-11de-8881-b6446c042ed3', NoChange, '100 >>> 0.0 0', NoChange, NoChange, NoChange, NoChange)]), >>> set([ModifiedByRecord('2d7fb878-3517-11de-8881-b6446c042ed3', u'', >>> Decimal("1241048456"), 500)])) >>> >>> My guess is that something is happening in the translation step, or >>> that Zimbra is doing something quirky with the VTODO entries. >>> >>> I'd appreciate any help addressing this, at least to interpret what >>> is being flagged in the Diff (if anything). >>> >>> I am using Chandler Desktop v1.0.3 from the hardy package (running >>> Debian/testing). >>> >>> Thanks! >>> John >>> _______________________________________________ >>> [hidden email] mailing list >>> unsubscribe here: >>> http://lists.osafoundation.org/mailman/listinfo/chandler-users >>> Chandler wiki: http://chandlerproject.org/wikihome >>> >> _______________________________________________ >> [hidden email] mailing list >> unsubscribe here: >> http://lists.osafoundation.org/mailman/listinfo/chandler-users >> Chandler wiki: http://chandlerproject.org/wikihome >> > > > [hidden email] mailing list unsubscribe here: http://lists.osafoundation.org/mailman/listinfo/chandler-users Chandler wiki: http://chandlerproject.org/wikihome _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
