Instead of treating all the message either as alternative or mixed with
this changeset the MIME type of the parent part is used.
This allows a correct disposition of the message in the cases when
nested multiparts elements are used.
Also in mixed parts we convert between plain text and HTML as needed.
Instead of keeping only the highest access roles. This reverts
2c678101 to fix handling of ACLs with multiple groups.
This is done because OpenChange library stores other roles/permissions
in the ACLs that have limited scope to the MAPI protocol and it
maintains an homogeneous returned data with other folders by returning
the actual data is stored in the DB.
By sorting the roles, we give the ability to callers to validate
permissions more efficiency (less loops) and keep the right highest
access level. As an example, check
[SOGoApppointmentFolder:roleForComponentsWithAccessClass:forUser]
for details.
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.
By setting `SoIMAP4ExceptionsEnabled` config key to YES
Enabled for OpenChange by default, it will ensure no action is taken
when IMAP connection is not valid.
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).
