[Kolab-devel] Shared addressbooks and roundcube

Thomas Brüderli bruederli at kolabsys.com
Thu Feb 5 13:21:37 CET 2015


Sergio Talens-Oliag wrote:
> Hello again,
> 
> I'm still working on my dovecot based kolab installation and I'm really close
> to have almost everything I want working, but I'm still finding some small
> bugs probably caused by the use of dovecot.
> 
> My latest problem is related to shared contacts and the roundcube plugin; I
> have found a workaround to the problem for now, but I guess it is worth 
> reporting in case it is useful to others.
> 
> The problem I've found appears when a user is subscribed to an addressbook
> shared by other user; once the subscription is enabled I get a 700 error every
> time I try use the Contacts section or the autocompletion functions.
> 
> This message is related to the function:
> 
>   public function get_address_book($id, $writeable = false)
> 
> on the file:
> 
>   /usr/share/roundcubemail/program/include/rcmail.php
> 
> Near the end of that function it says:
> 
>         if (!$contacts) {
>             // there's no default, just return
>             if ($default) {
>                 return null;
>             }
> 
> Where it should say:
> 
>         if (!$contacts) {
>             // there's no default, just return
>             if (!$default) {
>                 return null;
>             }
> 
> That is, the current code fails because the 'default' test is not doing what
> the comment say, we don't return null while the addressbook we are looking at
> is not the default and the user gets a 700 error although the default
> addressbook is working OK.

We've been here already and the code is correct. See
http://lists.kolab.org/pipermail/devel/2014-August/015136.html

> The problem is that when someone calls get_addressbook for the shared calendar
> they get a NULL value, but the code does not check if the value is null or
> not;

We should rather investigate why get_addressbook() doesn't return an
addressbook. $args['source'] holds an identifier which was previously
generated from an address book listing. Catching null values here
doesn't fix the root cause.

> There are more problems like the previous, and they could be fixed to let the
> system work when there are good addressbooks, but my problem remains, as the
> shared addressbook can't be seen from roundcube.
> 
> After looking at the error log I've found that the problem was related
> to the metadata parsing code; on the file:
> 
>   /var/log/roundcubemail/errors
> 
> I saw this:
> 
>   [29-Feb-2015 12:11:35,000000 +0100]: <chhgiih4> PHP Error: No kolab_storage_cache class found for folder 'c2hhcmVkL3N0b0BpdGkuZXMvQ29udGFjdHM' of type '' (GET /roundcube/93cde108787ed5c2/?_task=addressbook)
> 
> while the type should be 'contact'.
> 
> I've looked at the METADATA operations directly and I've found that GETMETADA
> fails because the folder has an '@' on it:
> 
>   A2 GETMETADATA "shared/sto at iti.es/Contacts"
>   (/private/vendor/kolab/folder-type /shared/vendor/kolab/folder-type)
>   A2 BAD Error in IMAP command GETMETADATA: 8bit data in atom
> 
> If I quote the '@' it works:
> 
>   A3 GETMETADATA "shared/sto\@iti.es/Contacts" (/private/vendor/kolab/folder-type /shared/vendor/kolab/folder-type)
>   * METADATA shared/sto at iti.es/Contacts (/private/vendor/kolab/folder-type NIL
>   * /shared/vendor/kolab/folder-type {7}
>   contact)
>   A3 OK Getmetadata completed.
> 
> So my guess is that the addressbook code is not quoting the folder names when
> getting the metadata.

Seems more like a dovecot issue. But anyway, it's not the addressbook
code who's responsible for quoting but the IMAP library.
> 
> As I'm only using one domain right now I've changed the shared folder route to
> avoid the '@' and now the path to the other user folder is
> "shared/sto/Contacts".
> 
> With this change the shared address books work as expected. Note that the
> problem seems to be in the addressbook plugin, as other modules worked OK when
> the shared folders had an '@' on their names (i.e. the calendar module gave no
> errors when using shared calendars).

That's strange. The calendar module actually uses the same code for
accessing Kolab groupware objects in IMAP as the kolab_addressbook plugin.

~Thomas



More information about the devel mailing list