versionsMessage object could have outdated version in a root folder
in the following case:
* Download latest contents using FXBuffer
* versionsMessage is updated by synchroniseCache
* OpenMessage from last FXBuffer
* Setup versions message as root folder
* Get Predecessor Change List from that message
We could just reload if needed the versions message if something
is missing but I don't know if that situation fixes more than this
one.
After saving a draft mail (this is done automatically by Outlook)
a GetProps call is done checking the PidTagChangeKey has been
updated properly. Without this patch, it returned MAPI_E_NOT_FOUND.
With this patch, we addressed that problem and we have updated
the Predecessor Change List metadata for the draft mail with the
change key provided by the client to avoid conflicting messages
whenever it is possible.
The attachments which used a extended parameter for their filename
('filename*=') where silently dropped.
This was because MAPIStore was only looking for no-extended filename
parameter.
The solution is using the 'filename' from the
SOGOExtension of the NSDictionary interface.
It is required when you are using SynchronizeImportReadStateChanges ROP
to update the MetaTagCnsetRead meta property.
See [MS-OXCFXICS] Section 3.2.5.9.4.6
This could lead to sync issues.
There were cases where only the change key was updated (GCS) or
others were the change key was updated with wrong info.
This changeset has as goal to update the predecessor change list
and, change key if required, on saving taking into account the latest information
given by the client in high level ROPs such as ImportMessageMove
or SetProperties, and merge it with information provided by the server
backend (IMAP server, SOGo DB) using `synchroniseCache`.
For more details about `PidTagChangeKey` and `PidTagPredecessorChangeList`
property values check [MS-OXCFXICS] Section 2.2.1.2
As required by operations like SynchronizationImportHierarchyChanges
a new change number must be generated when a change in a folder
is set. This affects to subfolders.
See [MS-OXCFXICS] Section 3.2.5.9.4.3 for details.
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
