[kronolith] annotation scan (was: kronolith 4.0.3 breaks shared folder access for me)

[Jens-U. Mozdzen]

Zitat von Jan Schneider <jan at horde.org>
>> 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.
>
> How did the structure look like, and how was it different from the   
> current structure? We might have to support and convert it, if this   
> was created by an earlier stable version.

the decodable one that looked strange to me was
--- cut here ---
a:5:{s:6:"source";s:5:"kolab";s:11:"fbrelevance";i:0;s:9:"xfbaccess";a:0:{}s:5:"color";s:7:"#00ff00";s:10:"share_name";s:80:"YTozOntpOjA7czo4OiJqbW96ZHplbiI7aToxO3M6ODoiS2FsZW5kZXIiO2k6MjtzOjU6IklOQk9YIjt9";}
--- cut here ---
Note the fbrelevance, source and xfbaccess attributes. I haven't seen  
them with shares created with H5.

Then I've noticed that 1.2.9 seems to have stored the user name  
*without* domain part, while H5 stores user at domain. When migrating a  
MySQL-stored user address book to H5, I had changed that manually  
(might have been done by the upgrade scripts if I had chosen to  
properly upgrade without skipping every release in between... by hey,  
it was only that address book table and only needed to export that  
data before re-importing it to the Kolab-based address book), and now  
I probably see the same thing in the IMAP-stored annotations.

At least one of the annotations contained garbled nonsense - I ran it  
through the base64 decode as those others I had a look at, and the  
result was binary, instead of a serialize data instance.

> Going through all folders with an external script is not easily
> possible due to permissions.

I don't see the point: The script will be run in a user's context  
(with his/her permissions), and of course only that user's annotations  
get checked. If run as the imap super user, then all mailboxes  
("folders") get checked :). So in the end, it's about providing the  
right credentials when invoking the script - and that's up to the  
invoker, not to the script developer. At least IMO.

Another observation/idea: currently, when that annotation contains a  
wrong share_name (at least I believe it's that share_name hash), the  
corresponding folder doesn't get handled well (see my other thread),  
so at least H5 might be able to be more forgiving to "bad" annotations  
by ignoring those?

With regards, and keep up the good work

Jens