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

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8299
------------------------------------------------------------------------------
  Ticket             | 8299
  Created By         | m.gabriel at das-netzwerkteam.de
  Summary            | current implementation of kolab cache supports only one
                     | object type per folder type
  Queue              | Kolab
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
+New Attachment     | 20090519_Kolab-Data_distlist-workaround.patch
------------------------------------------------------------------------------


m.gabriel at das-netzwerkteam.de (2009-05-20 04:37) wrote:

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.