A follow-up to this question from a while back:
On 04/20/10 23:54, Matto Marjanovic wrote:
We've got a sogo setup with a user-source that looks like the
following:
SOGoUserSources = (
{ CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = mail;
baseDN = "ou=Users,dc=aaa,dc=xxx,dc=com";
bindFields = (
mail
);
canAuthenticate = YES;
displayName = "aaa users";
hostname = localhost;
id = public;
isAddressBook = YES;
port = 389;
type = ldap;
}
);
When accessing the "aaa users" addressbook (via the web interface;
haven't tried via the Connector), then entering letters in the search bar
does correctly produce a list of matching entries. However, clicking on
an entry does nothing: no address card data is displayed in the lower
panel of the UI. (And, nothing new appears in sogo.log either.)
The problem is that the 'uid' field specified by IDFieldName is never
fetched from the LDAP server. This behavior only occurs when bindFields
is used.
In our case, we fixed it by changing IDFieldName to 'mail' --- which is
a better choice in our case, anyway. (It is not clear to me why one
would ever want to use an IDFieldName which is different from UIDFieldName.)
I filed two bug reports on this just now: #734 for the failure to fetch,
and #735 for the faulty documentation for how "IDFieldName" should be
chosen.
-mm
Furthermore, exercising the context-menu (right click) on the entries in
the list doesn't work either. Clicking on "Properties" from an entry's
context-menu causes the sogo server to die/restart with the following
error logged in sogo.log:
EXCEPTION: <NSException: 0xa3b7270> NAME:NSInvalidArgumentException
REASON:Tried to add nil value for key 'edit' to dictionary INFO:{}
Is this due to a bug, or our misconfiguration?
-mm
ps: We had no problems with the addressbook with earlier testing using
an user-source that did not use bindFields.
--
[email protected]
https://inverse.ca/sogo/lists
