According to [MS-OXCPERM] Section 2.2.7 in PidTagMemberRights possible
values, once we set the DeleteAny flag, the DeleteOwned flag must be set.
Likewise EditOwned must be set when EditAny is set. In this way,
the rights sent by the MAPI client are equal to the returned by the
server when Editor is set.
In real world practice, makes more strict Outlook 2013 work with editor permissions
the sharing of user's defined calendars, tasks or contacts folders as
the recipients can be editors of that folder.
For example, if the SMTP is down, then the message is not sent and
an error is returned. We returned back this error code to be managed
by upper layer.
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.
