Fri, 10 Apr 2026 04:00:03 +0000 https://bugs.horde.org/ticket/8299 current implementation of kolab cache supports only one object type per folder type 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. Wed, 20 May 2009 08:37:35 +0000 https://bugs.horde.org/ticket/8299#t54268 Ehrm, the first thing that comes to my mind is that storing two different object types in the same folder breaks the IMAP folder annotation of Kolab, doesn't it? F.e. you can't store calendar and contact objects in the same folder without breaking the specification of the annotations. Thu, 04 Jun 2009 07:35:04 +0000 https://bugs.horde.org/ticket/8299#t54417 > Ehrm, the first thing that comes to my mind is that storing two > different object types in the same folder breaks the IMAP folder > annotation of Kolab, doesn't it? > > F.e. you can't store calendar and contact objects in the same folder > without breaking the specification of the annotations. > note that below i am talking about contact objects distribution-list objects in the same IMAP folder... Thu, 04 Jun 2009 08:44:55 +0000 https://bugs.horde.org/ticket/8299#t54418 > note that below i am talking about > > contact objects > distribution-list objects > > in the same IMAP folder... Thanks for reposting this. I still think this is invalid according to the Kolab folder annotation specification, maybe it was updated and I missed it. Gunnar, what do you think? Tue, 09 Jun 2009 11:15:14 +0000 https://bugs.horde.org/ticket/8299#t54510 >> note that below i am talking about >> >> contact objects >> distribution-list objects >> >> in the same IMAP folder... > > Thanks for reposting this. I still think this is invalid according to > the Kolab folder annotation specification, maybe it was updated and I > missed it. > > Gunnar, what do you think? > most clients store contacts and distribution-lists in the same folder... kolab does not want to break this habit, does it??? confused and astonished... Tue, 09 Jun 2009 13:03:48 +0000 https://bugs.horde.org/ticket/8299#t54511 Changes have been made in CVS for this ticket: Fix cache key issues (Bug #8299) http://cvs.horde.org/diff.php/framework/Kolab_Storage/Attic/package.xml?rt=horde&r1=1.2.2.29&r2=1.2.2.30&ty=u http://cvs.horde.org/diff.php/framework/Kolab_Storage/lib/Horde/Kolab/Storage/Attic/Data.php?rt=horde&r1=1.5.2.4&r2=1.5.2.5&ty=u Mon, 11 Jul 2011 07:59:46 +0000 https://bugs.horde.org/ticket/8299#t66262 Fixed for FRAMEWORK_3 and Horde 4 was already done with the refactoring of Kolab_Storage. Mon, 11 Jul 2011 08:00:37 +0000 https://bugs.horde.org/ticket/8299#t66263