[kronolith] kronolith 4.0.3 breaks shared folder access for me

[Jens-U. Mozdzen]

Isn't it fun responding to one's own messages?

> after applying the update to kronolith 4.0.3 (and deleting the Horde  
> cache), I can no longer see the list of calendars when starting  
> kronolith. The dynamically list on the left forever remains at  
> "loading calendars". The error log contains:
>
> 2013-01-14T12:45:08+00:00 WARN: HORDE [kronolith] PHP ERROR:  
> array_merge(): Argument #1 is not an array [pid 1045 on line 342 of  
> "/usr/share/php5/PEAR/Horde/Share/Kolab.php"]

It seems that, while the new code did exhibit a problem the old code  
didn't, the root cause was bad data in the configuration store.

As I'm currently trying to understand the structure of the  
"shared-folder" annotation stored in our IMAP store, I decoded that  
value from various folders. Some of these folder were created with H4  
(or probably even Horde 1.2.8), one with some older version of H5,  
that still might have had problems with our Kolab back-end.

It turned out that one of those "old" folders contained a "share_name"  
structure (base64-encoded), that wouldn't decode to the expected  
format. This then somehow lead to the above message. Unfortunately,  
that folder was not only shared with the other users, but activated  
for display with all users, leading to that error for any user we had  
tested with.

After fixing that structure, everything is working with the new code.  
And as a hint for others hitting that problem too: If you get "mailbox  
does not exist" error pop-ups when activating shared mailboxes (or  
when starting kronolith), if mailboxes are missing in your list or are  
without name, then try to isolate that mailbox and delete the  
share-folder annotation at the imap level.

A question to the developers: Is there somewhere in the Horde 5 code  
some tool/code that I could use to check the content of all  
"share-folder" annotations? I seem to have some really weird  
attributes stored in one or another of those, it might be helpful to  
do some "plausibility check" at least during/after an upgrade.

And many thanks for 4.0.3, because that new code level fixes a rather  
nasty problems that we had noticed, but not yet had time to diagnose  
(moving entries between Kolab-stored calenders always failed with  
"mailbox does not exist", although I could create new entries in both  
the source and the target calender just fine).

Regards,
Jens