6.0.0-git
2019-04-25

[#8299] current implementation of kolab cache supports only one object type per folder type
Summary current implementation of kolab cache supports only one object type per folder type
Queue Kolab
Type Bug
State Resolved
Priority 1. Low
Owners thomas.jarosch (at) intra2net (dot) com, wrobel (at) horde (dot) org
Requester m.gabriel (at) das-netzwerkteam (dot) de
Created 2009-05-20 (3627 days ago)
Due
Updated 2011-07-11 (2845 days ago)
Assigned 2009-06-04 (3612 days ago)
Resolved 2011-07-11 (2845 days ago)
Milestone
Patch Yes

History
2011-07-11 08:00:37 Gunnar Wrobel Comment #7
State ⇒ Resolved
Reply to this comment
Fixed for FRAMEWORK_3 and Horde 4 was already done with the 
refactoring of Kolab_Storage.
2009-06-09 13:03:48 m (dot) gabriel (at) das-netzwerkteam (dot) de Comment #5 Reply to this comment

[Show Quoted Text - 13 lines]
most clients store contacts and distribution-lists in the same 
folder... kolab does not want to break this habit, does it???



confused and astonished...
2009-06-09 11:15:14 Thomas Jarosch Comment #4 Reply to this comment
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?


2009-06-04 08:44:55 m (dot) gabriel (at) das-netzwerkteam (dot) de Comment #3 Reply to this comment
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...
2009-06-04 07:35:04 Thomas Jarosch Comment #2 Reply to this comment
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.


2009-06-04 02:26:51 Chuck Hagenbuch Assigned to Gunnar Wrobel
Assigned to Thomas Jarosch
State ⇒ Assigned
 
2009-05-20 08:37:35 m (dot) gabriel (at) das-netzwerkteam (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ current implementation of kolab cache supports only one object type per folder type
Queue ⇒ Kolab
Milestone ⇒
Patch ⇒ Yes
New Attachment: 20090519_Kolab-Data_distlist-workaround.patch Download
Reply to this 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.




Saved Queries