Re: [Kolab-devel] Shared addressbooks and roundcube

Thomas Brüderli <[email protected]>
Newsgroups gmane.comp.kde.devel.kolab
Message-ID <[email protected]>
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/[email protected]/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/[email protected]/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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.