Tickets :: Comment on [#8299] current implementation of kolab cache supports only one object type per folder type

* Your Email Address
* Spam protection	Enter the letters below: \ /.___. .. .. . >< [__ \|__\|\|__\|\|_/ / \\| \| \|\| \|\| \
Comment	> The current Kolab cache implementation (as in > horde-webmail-1.2.3-final) supports only one object type per folder > type. This issue only occurs when using more than one Kolab client > (e.g. Horde and Toltec). This issue also only occurs when my patch > found in ticket 7921 is applied as only then Horde and Toltec can > both see/access each others private distribution lists. > > > > If there was a Kolab client using > application/x-vnd-kolab.distribution-list as MIME type for Kolab > distribution list attachments the error would also occur with this > client. Meaning: it is a general problem that - with the current code > base - will always occur when different object types are stored in > the same folder. > > > > Try the following: > > > > 0. Prepare > > > > o add a test share for contacts/distlists > > o add at least one contact (any client, contacts will sync without > any problem) > > > > 1. Horde -> Toltec > > > > o create a private distlist-1 in the test share (with Horde), as > members use contacts you just > > created from your test share > > o sync with Toltec > > o SUCCESS, the distlist-1 will be synced to Outlook, the distlist-1 > can be seen in Horde > > > > 2. Toltec -> Horde > > > > o create another private distlist-2 in the test share (now with > Outlook/Toltec), as members again > > add contacts from the test share > > o sync with Toltec > > o partial FAILURE: the distlist-2 is synced to the IMAP server, but > Horde does not show the > > distlist-2. Further observation shows that the Kolab cache in > Horde does not ,,remember'' long > > enough that the IMAP folder containing contacts and distlists has > changed... > > > > 3. Make the distlist visible to Horde > > > > o Create another distlist with Horde > > o LATE SUCCESS: suddenly the distlist-2 synced from Outlook appears > in Horde > > > > DEBUGGING: > > > > The cause for this issue is structural. The current implementation of > the Kolab cache cannot cope with two different object_types in one > groupware folder. Turba does a dual call on the same IMAP share, > first it tries to retrieve the contact data, then it tries to > retrieve the distlist data. > > > > However, when retrieving the contacts it will synchronize the Kolab > cache with the IMAP folder (but for contacts only) and mark the cache > folder as ,,in sync'': > > > > function _folderChanged($validity, $nextid, &$old_ids, &$new_ids) > > { > > > > [...] > > > > $this->_cache->validity = $validity; > > $this->_cache->nextid = $nextid; > > > > [...] > > > > } > > > > > > Next, Turba will try to retrieve the distlist data. As the > corresponding IMAP folder is already marked as synced, the Kolab > cache thinks that cache and IMAP folder are identical. But they are > not. The contacts have by now been synced to the cache, but the > distlist objects have not yet been synced to the cache. > > > > To make this work fluently, I think, the code concept has to be > changed slightly. An idea could be changing $data->_object_type > (string) into an array $data->_object_types that contains all > object_types for this folder type. The $data->synchronize method > should then first check if the IMAP folder has changed, if yes walk > through all the possible object types for this folder type and sync > all these object types to the Kolab cache (in one go). > > > > To make the issue go away - without committing to much of a > structural change in the code - I applied a very evil workaround. I > will attach this workaround here with the hope of the problem > becoming clearer. > > > >
Attachment
Watch this ticket

Saved Queries