Am 22.11.10 19:30, schrieb Wolfgang Sourdeau:
In SOGo, we use SQL-based addressbooks for all user addressbooks and
LDAP-based addressbooks for "system addressbooks". What "system" means
is that it represents a read-only source of user informations that is
managed only by the system administrator and outside of SOGo itself. In
Thunderbird, all user addressbooks but only one system addressbook can
be used for finding users when composing emails or inviting people to an
event. That's a limit of Thunderbird.
In SOGo Connector, user addressbooks are synchronized (via webdav sync)
with local Thunderbird addressbooks while system addressbooks are
queried in real time via a carddav request.
I suspect the problem that occurs is that SOGo Connector considers those
2 addressbooks as "user addressbooks" rather than "system addressbooks",
which trigger webdav sync queried, which are not supported for system
addressbooks. There would thus be 2 bugs:
- SOGo Connector must consider them as system addressbooks
- SOGo must not report those addressbooks as "webdavsync capable"
In order to confirm this, please provide us with a sniff log of the SOGo
traffic when this occurs, from the moment you launch Thunderbird until
the problem starts to show up.
Regarding your configuration, you should probably declare "unikn_users"
as value for the "publicid" key mentionned by Ludovic. Following its
unikn_rooms is also an LDAP system address book, containing all bookable
rooms of the university.
And unikn_resources will also exist, featuring ressources. If only one
LDAP system addressbook may exist, I'll purge unikn_rooms to test.
What's the exact meaning of the publicid Thunderbird parameter?
--
[email protected]
https://inverse.ca/sogo/lists
