This is a revised fix for the issue raiased in sogo bug tracker 3370 and 3373. It supercedes the fix in commit 2c723070c6 .
The fix was noted in NEWS with the comment "we now return all cards when we receive an empty addressbook-query REPORT". However it did not work for me and at least two others, as can be seen in the commit comments. In summary, only contacts with email addresses were synced. The suggested change from kwirk fixes the regular address book sync, but it completely breaks syncing of the read-only Group Directory (Corporate Directory). My suggested changes work in full (as far as I'm able to test).
I have done some fairly extensive testing of CardDAV sync (with DAVDroid only) and it seems to work 100% now. In addition to the obvious tests, I have tested with contacts that only have one field of data entered. The feilds I've tested (with all other fields empty) are as follows:
First name
Last name
Display name
email address
Work (telephone)
Home (telephone)
Fax (telephone)
Mobile (telephone)
Additionally, I tested syncing of a contact with only the Work Address fully populated. In the webmail, since the name fields are all missing, the "Organization" field of the Work Address takes the place of the name field in the 'Name' column. This does get synced to my phone and it also appears my Android contact list with 'Name' set to the 'Organization' field data. The address, organization and website fields being in tact also.
In addition, I tested a Group Directory (Corporate Directory) [SOGoUserSources->isAddressBook] sync. It seems contacts without email addresses do not sync. This seems to be the behaviour across the board with a "." search filter. This happens despite the filter in SOGoUserSources including ldap entries without a mail attribute. Nothing I can do to patch this in SOGoFolder+CardDAV.m, that would have to be fixed in the code that deals with the special "." search filter (I guess).
I think the contact search system needs some looking into, particularly the "." search filter behaviour. There is another bug related to contact search in the webmail address book view. I will make a bug report on that soon. It's a shame there isn't an "all" search filter, it would seem it would make various parts of SOGo easier to get the right behaviour.
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
Attachment creation can succeed and attachment mime file could fail
This can happen, e.g., when the filename's length is close to the maximum
allowed but your filesystem and then mime file will exceed that limit
(because it has a prefix).
This method is used to get the login and we weren't returning
the domain, which led to problems when creating appointments
on multidomain environments like, for instance, not sending
the invitation mails.
Some clients (such apple mail) use only the filename
attribute in the content/disposition header and the
name attribute from the content/type header is filled with
uninternationalized characters.
Example:
Content-Type: application/msword;
x-apple-part-url=C4977556-0D01-4C6C-8A51-451E0AADE431;
name=_______.doc
Content-Disposition: attachment;
filename*=utf-8''%D0%A0%D0%95%D0%9A%D0%92%D0%98%D0%97%D0%98.doc
This changeset gives priority to the filename attribute.
As the stored context from initialisation may have changed
by `setContext` by other operations when acting as a OpenChange
library. This would make having a login set to nil and forcing
a NSException when it attempts to set a nil key at
[SOGoAppointmentFolder:roleForComponentsWithAccessClass:forUser]
inside [SOGoAppointmentFolder:initializeQuickTablesAclsInContext].
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)
Happened in an imported vevent from Mozilla Thunderbird.
The crash was:
Sep 14 15:49:38 sogod [21063]: <0x6442DBF8[SOGoAppointmentFolder]:personal> missing 'c_startdate' in record?
Sep 14 15:49:38 sogod [21063]: <0x6442DBF8[SOGoAppointmentFolder]:personal> missing 'c_enddate' in record?
2015-09-14 15:49:38.927 sogod[21063] NGCalendarDateRange.m:37 Assertion failed in NGCalendarDateRange(instance), method initWithStartDate:endDate:. startDate MUST NOT be nil!
EXCEPTION: <NSException: 0x7fb96b3c0ed8> NAME:NSInternalInconsistencyException REASON:NGCalendarDateRange.m:37 Assertion failed in NGCalendarDateRange(instance), method initWithStartDate:endDate:. startDate MUST NOT be nil! INFO:(null)
The relevant ICS file lines are the following ones:
BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E00800000000901646A7234BCE01000000000000000010000000E9152C8FF1C27D488C91967FAAFCC2B0
RECURRENCE-ID:20140513T100000Z
DURATION:PT1H
CLASS:PUBLIC
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CN=krsny >>
Ann Thierry K:mailto:krsny@example.com
END:VEVENT
When returning contacts we have to supply also the domain field.
Because in a multidomain environment UIDField is unique only in
the domain so an user must be identified as uid@domain.
So when creating http requests from client side, we have to use
uid@domain instead of only uid so the SOGoUser created on server
side when parsing the requests is created properly.
The folder names are encoded through the `asCSSIdentifier` and
`stringByEncodingImap4FolderName` functions when we store them as folder
keys. In addition, the prefix "folder" is added to the key.
The order in which these operations were done when storing the folder
keys (and reverted when retrieving them) wasn't consistent trough the
code. This led to problems such as creating twice a folder with a digit
at the beginning of its name.
The folder name goes now through the following operations when being
stored as a key (the retrieval reverts these in the reverse order):
* `stringByEncodingImap4FolderName`
* `asCSSIdentifier`
* Add "folder" prefix
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
The UID was being used to check if the changes in an appointment had been made by
its organiser. In this case, the UID is the user name, without taking the domain into account.
The `owner` variable, however, is a full email address, so the comparison was never successful. This
caused the update notification mail not to be sent.
Depend of the current workflow these paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
Depend of the current workflow this paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
Conflicts:
SoObjects/SOGo/SOGoUserManager.m
On multidomain environment (SOGoEnableDomainBasedUID) with email for imap
authentication (SOGoForceExternalLoginWithEmail) we need to use uid@domain
instead of just uid in method getEmailForUID
In multidomain environments this will produce that info@domain1.com
can read info@domain2.com emails when info@domain2.com log in after
info@domain1.com is already logged in.
If multidomain is not enabled, this action is not needed because
uid+attributes has been already saved on shared cache
On multidomain environment (SOGoEnableDomainBasedUID) with email for imap
authentication (SOGoForceExternalLoginWithEmail) we need to use uid@domain
instead of just uid in method getEmailForUID
In multidomain environments this will produce that info@domain1.com
can read info@domain2.com emails when info@domain2.com log in after
info@domain1.com is already logged in.
If multidomain is not enabled, this action is not needed because
uid+attributes has been already saved on shared cache
In multidomain environment right now we are trying to authenticate against
all sources defined in sogo.conf because the domain is not set at this point.
In sogo.conf we have to specify the domain a source is useful for, so with this
patch instead of 'n' tries of authentication we will perform only 1 (in a scenario
where we have 1 source per domain, and we have 'n' domains).
All this basically is to make it work on multidomain environment
the Reply all functionality of emails but I'm sure there are more use cases
as an Outlook client that don't work nowadays without this patch.
More info on commit message but basically it was that we were using user
instead of user@domain.com in several places.
PidTag*EntryId properties were not being generated (which contain
the email address and so on). Functionality on Outlook clients like
"Reply All" were not working because of this (probably a lot more
stuff related with email addresses).
With multidomain support enabled outlook clients will use full email
address (e.g. user@domain.com) as login.
This change is needed because we were performing ldap queries on samdb
using (sAMAccountName=UIDFieldName), being UIDFieldName the parameter
configured in sogo.conf for that source. In multidomain environment
this field could be `sAMAccountName` but it could not. Actually the
more logical scenario will be to use `uid` field here (which will be
just `user`, without the `@domain.com` part).
SOGoUserManager will return `sAMAccountName` if the contact has it
(in Outlook environment that means always) so it can (and must) be
used to query samdb in MAPIStoreSamDBUtils properly.
TL;DR: use sAMAccoutName instead of uid to query samdb
sogo-openchange library stores the properties as NSString keys
and the search function casts the values to NSNumber, which it may
be valid for other parts but not for this library.
The real fix would be to store the property keys as NSNumbers as
they are uint32_t at the end. However, this may lead to a great
refactor in the library.
With this fix, we can match the search for a property in a
MAPIStoreFallback folder, such as Notes or Deleted Items, or
MAPIStoreFolder properties (ie: search for a subfolder) or
for MAPIStoreFAIMessages in a folder.
When users use full domain to login (SOGoEnableDomainBasedUID) the
user attributes in the cache were not being properly updated because
in this case the key is `uid@domain` instead of just `uid`.
When users use full domain to login (SOGoEnableDomainBasedUID) the
user attributes in the cache were not being properly updated because
in this case the key is `uid@domain` instead of just `uid`.
