Using LDAP as source, the group entry must have a valid
group objectClass such as posixGroup or group and have a
valid UIDField which does not include the domain.
With this changeset, SOGo is aware of these groups when it has
an email and you can share a component such as a calendar with
the member of the group.
This option is not needed. SQLSource was not using it
and LDAPSource will transform the filter to (UIDField=*) when
there is nothing set as filter, before this patch it was needed
to either insert '.' as filter or set listRequiresDot to NO
When we have a contact with an email, avoid generating another one
with SOGoMailDomain value (normally we ended up with a contact with
two identical emails on 'emails' key and for multidomain source we
would had ended up with an email @localhost)
A CSS identifier can't start with a digit, so when a folder name does,
a '_' character is appended at the beginning of its CSS identifier.
The check for this first character used the `isdigit()` function, which
takes a `char` argument, while `[self objectAtIndex: 0]` returns a
`unichar`, i.e. a 16-bit unsigned integer. This caused some non-digit
characters to pass this check (e.g. Chinese characters), ending up with
an underscore at the beginning of the folder name.
This method is used everywhere to try to retrieve the login of the user
(and normally use the return value to [SOGoUser initwithLogin: ...])
In multidomain environments (with DomainLessLogin = false) there were
several paths (mostly in SOGoAppointmentObject.m) that were trying to
create SOGoUser objects with incorrect login: using only the uid part,
not full email. Then like domain based uid was enabled, these users
had DomainLessLogin set to true and further calls tried to authenticate
only with the uid part (and they should not).
This affects to several methods in:
* ActiveSync/SOGoActiveSyncDispatcher.m
* Appointments/SOGoAppointmentFolder.m
* Appointments/SOGoAppointmentObject.m
* Appointments/SOGoCalendarComponent.m
* SOGoSAML2Session.m
Probably a few features related with calendars are now fixed or working
as intended in multidomain environments where the email is used as login
