To be able to search in this for every kind of operator.
As we cannot do a migration, we have to add a new key to the property
dictionary (@"version_number") which stores the version:
version = exchange_globcnt(CN >> 16)
Instead of the CN structure which is stored in @"version" key.
This way we can do searches for CN to download only missing data from the
given state of the client for this kind of messages.
It was using NSNumber in versions Dictionary for GCSMessages but it is
stored as the NSString representation (0x390300000000001), so the lookup
has always failed.
By ignoring <, =< and = operators and simplifying the following
request:
MODSEQ >= x || MODSEQ >= y || MODSEQ >= z --> MODSEQ >= min(x, y, z)
This hack will reduce the number of current retrieved UID keys
from the IMAP server. Current status is to retrieve everything when
the multiple CN restriction is sent as the required restriction
is too complex and it is not defined by the IMAP spec.
The proper implementation for:
CN > x_1 & CN < x_2 | CN > y_1 & CN < y_2 | CN > z_1
It will be something like this:
set(MODSEQ >= x_1 + 1) - set(MODSEQ >= x_2)
U
set(MODSEQ >= y_1 + 1) - set(MODSEQ >= y_2)
U
set(MODSEQ >= z_1)
Assuming x_1 <= x_2 <= y_1 <= y_2 <= z_1.
We needed to return AddressBookProviderEmailList,
AddressBookProviderArrayType and Email1OriginalEntryId to
make it compatible with the standard.
Besides a refactorization to return better EmailNFoobar properties
After the providing the workaround on rebuilding the LDAP connection,
the sam_ctx variable can be freed and it was used as memory context
to store the AddressBookEntryId or OneOffEntryId when resolving
recipients. After this changeset, a local memory context which I
think is more sane.
The changes in the exchange.idl file from OpenChange has changed
some string pointers from 'const char *' to 'uint8_t *'.
This changeset cast them to avoid compilation warnings.
SOGo event notification mails add information to the event name in their
subject (e.g. _Event invitation: "foo"_). The client uses the mail
subject to create a copy of the event on the attendee's calendar, so we
need to strip out that extra information if we want the event to have
the proper name.
Equals to the number of uids requested.
There are corner-cases when this is not happening, we don't know yet
why this is happening but IMAP server log should do the trick.
This avoids to launch a NSException trying to access an element
outside the array bounds.
There is a use case where this has caused crashes:
A message was hard-deleted using an IMAP client, this is the first
message you deleted in that folder and you have cleared offline
items in the client so a full sync is asked by upper layer.
In that situation, the SyncLastDeleteChangeNumber version property
is not set and return 0 in [getDeletedKeysFromChangeNumber:andCN:inTableType]
making OpenChange to crash while it is asking for deleted fmids
since a given change number.
This is a regression from 18d7070c4a.
Sometimes we're trying to get the `objectVersion` of a calendar message,
but this message's entry is not in the cache. The method
`synchroniseCache` won't work in this case, so we try to force the
synchronisation of that particular message in order to get the change
number before aborting.
And perform the real IMAP operation on save method as described by
[MS-OXCFXICS] and [MS-OXCMSG] Section 2.2.3.3, these operations must be
committed when SaveChangesMessage is called.
As it is expected by Outlook to increase the change number when
performing the `SetMessageReadFlag` ROP, if it is not done, the client
tries indefinitely to store that.
This method does not longer returns true if the content id
was a empty string.
In some case the old false positive triggered the removal of
attachments when sending messages.
The operation RopFastTransferSourceCopyTo calls the available
properties for a message using the instance method. It seems the
preferred method by Outlook to synchronise a FAI message. OpenChange
calls the message to get the available properties, so the instance
method is called. As it is specialised to return the custom hack
FAI properties, we have to call that class method instead of using
generic one available at NSObject (MAPIStoreProperties) class.
This avoids crashing the Outlook client after we synchronise the
calendar folder after changing the timeframe view (eg from day view
to month view).
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
It was not working because we try to save as component the
full calendar and its parent was nil. We have to save the calendar
itself to save the task in the personal calendar.
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.
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.
Before this change, the recipient address was only extracted from the sogo
user object. This made mail to groups undeliverable.
Now if we do not have mail addresses from user object,
we try to use parameters from the client call.
Introduced by ebe2a466e7 in PR #132 when the event is not
all day neither recurrent one.
The fix is just to initialise to nil when it is a normal event
and it returns NOT_FOUND for this property.
The value of `PidTagResponseRequested` property in the invitation mail
wasn't being set properly, while the `PidTagReplyRequested` property
wasn't being set at all. This caused invitation response mails not to be
sent. Both properties are expected to be `true`.
This fixes two scenarios:
* An IMAP subfolder has updated its hierarchy when it is asked
to be synchronised
* An IMAP root folder is created on Outlook when you logon. OpenChange
changes are required to be refreshed on synchronisation.
