So when multidomain is enabled we will have tables like
sogo_cache_folder_user_A_domain_D_com instead of just
sogo_cache_folder_user
If multidomain is disabled the folders will still be like
sogo_cache_folder_user
Avoiding the usage of __FUNCTION__ and __LINE__
and more related with the logging system is being in place
for OpenChange.
As well as set the proper level to some debug messages.
As well as hard deleted
As explained in [MS-OXCFXICS] Section 2.2.1.3.1, the
property MetaTagIdsetDeleted must include both types
of messages and this idset is filled with the return
value of this message.
This property is needed to show the 'Internet Headers' in Outlook.
Outlook 2010 shows them in the properties dialog of a message.
Outlook 2007 show them in message options section from context menu
of a mail message.
The property is defined in [MS-OXOMSG] section 2.2.1.61.
The property is formed concatenating the mail message headers
properly mime encoded.
The headers are appended in no defined order.
As it happened with dba17fb if we interleave requests
from different users while creating a folder we can
create the folder in other user's mailbox as latest
activeUser is the one from latest sogo_context_get_root_folder
call.
This is for me a lack of right design and a workaround
only fixing this issue but not the root cause.
This requires https://github.com/openchange/openchange/pull/244 to work
but basically we have modified this backend to store request-related
properties in a `MAPIStoreMailMessage` using the versions message
from the `MAPIStoreMailFolder` container and fix the setter/getter
for the following properties:
* PidNameXSharingFlavor
* PidLidSharingFlavor
* PidNameXSharingCapabilities
* PidLidSharingResponseType
* PidLidSharingResponseTime
As it happened with dba17fb if we interleave requests
from different users while creating a folder we can
create the folder in other user's mailbox as latest
activeUser is the one from latest sogo_context_get_root_folder
call.
This is for me a lack of right design and a workaround
only fixing this issue but not the root cause.
* PidNameXSharingFlavor is used by Outlook 2010 so we have
to store it
* 0x5100 is used although it is not in spec as Sharing Flavour
value when the request is denied from a message where
Request + Invitation was sent.
* Return properly PidNameXSharingCapabilities and PidNameXSharingFlavor
as it is an string representation of a hex number
* Try to guess proper sharing flavour value when it is missing
Save them in extra properties from folder container.
This is required because the client once a request is accepted
or denied sets these two properties and save the message again.
As we cannot modify an IMAP message, we use this utility.
See [MS-OXSHARE] Section 3.1.4.3 for details.
A failure in parsing an ICS makes return a nil calendar
object. Instead of creating an appointment with nil
information which can lead to crashes like the one
generated creating PidLidCleanGlobalObjectId property.
We return an empty message with no information which is
taken into account in Outlook but not displayed like
in SOGo webmail does.
The `[SOGoFolder:aclUsers]` returns a reference to a `NSArray`
which is being modified in the `for` loop making fail when
more than one user is in the ACL with `NSRangeException`.
A failure in parsing an ICS makes return a nil calendar
object. Instead of creating an appointment with nil
information which can lead to crashes like the one
generated creating PidLidCleanGlobalObjectId property.
We return an empty message with no information which is
taken into account in Outlook but not displayed like
in SOGo webmail does.
The `[SOGoFolder:aclUsers]` returns a reference to a `NSArray`
which is being modified in the `for` loop making fail when
more than one user is in the ACL with `NSRangeException`.
Outlook sets recipient type of Required attendees as MAPI_TO and
optional ones as MAPI_CC, so the fix is just to not only iterate
over the "to" list of recipients but also the "cc" one. We're
also setting the proper iCal value for this case (OPT-PARTICIPANT
instead of REQ-PARTICIPANT)
In [MS-OXOCAL] Section 2.2.4.10.7 says the recipient type is 0x01
as Required and 0x02 as Optional and other documents such as
[MS-OXCMSG] 2.2.3.1.2 indicates that MAPI_TO is 0x01 and MAPI_CC
is 0x02, that's why is stored in 'to' and 'cc' respectively.
Julien Kerihuel
Julio García
Jesús García Sáez
Julio J. García Martín
Enrique J. Hernández Blasco
Jesús García Sáez
Ludovic Marcotte
Francis Lachapelle
José Antonio Calvo