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
Some clients such as OpenChange client does not send the following
properties PidTagNormalizedSubject or PidTagSubjectPrefix as
suggested by [MS-OXCMAIL].
On [MAPIStoreContext idForObjectWithKey: key inFolderUrl: url] check the ret value
of mapistore_indexing_get_new_folderID. This should never happen (oh my...) but
if this happens it will be reported
This adds [MAPIStoreUserContext activate] method to use
it instead of activateWithUser.
A cleanup operation is executed after each public function
so there won't be any conflicts with future calls.
In practice, this will deactivate the current user context set on
MAPIApp, this means two things: (1) set nil as current user context
on MAPIApp and (2) remove woContext from current thread dictionary
This is crashing when the PidTagObjectType property is set for
some recipient and not for others.
If the property is missing, then no object type for the recipient
is assumed.