Depend of the current workflow these paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
On multidomain environment (SOGoEnableDomainBasedUID) with email for imap
authentication (SOGoForceExternalLoginWithEmail) we need to use uid@domain
instead of just uid in method getEmailForUID
In multidomain environments this will produce that info@domain1.com
can read info@domain2.com emails when info@domain2.com log in after
info@domain1.com is already logged in.
If multidomain is not enabled, this action is not needed because
uid+attributes has been already saved on shared cache
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.
All this basically is to make it work on multidomain environment
the Reply all functionality of emails but I'm sure there are more use cases
as an Outlook client that don't work nowadays without this patch.
More info on commit message but basically it was that we were using user
instead of user@domain.com in several places.
Take into account optional attendees setting the recipient
type to MAPI_CC when they have the iCal role set to OPT-PARTICIPANT
instead of harding always MAPI_TO (required) as was done before.
This is a complementary fix for: https://github.com/Zentyal/sogo/pull/108
oc: return last modified messages when sorted by PidMessageTagDeliveryTime
This change is required as oxcfxics is asking for sorting
using this property.
We fake this property on GCS folders (Tasks, Calendar, Contacts)
using c_lastmodified column.
PidTag*EntryId properties were not being generated (which contain
the email address and so on). Functionality on Outlook clients like
"Reply All" were not working because of this (probably a lot more
stuff related with email addresses).
With multidomain support enabled outlook clients will use full email
address (e.g. user@domain.com) as login.
This change is needed because we were performing ldap queries on samdb
using (sAMAccountName=UIDFieldName), being UIDFieldName the parameter
configured in sogo.conf for that source. In multidomain environment
this field could be `sAMAccountName` but it could not. Actually the
more logical scenario will be to use `uid` field here (which will be
just `user`, without the `@domain.com` part).
SOGoUserManager will return `sAMAccountName` if the contact has it
(in Outlook environment that means always) so it can (and must) be
used to query samdb in MAPIStoreSamDBUtils properly.
TL;DR: use sAMAccoutName instead of uid to query samdb
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
We believe the folder ID OpenChange is sending us is new
and we keep the indexing database properly updated.
Although the solution is not elegant, this could avoid
inconsistencies between what the client stores and the
relation in the MAPIStore backend.
sogo-openchange library stores the properties as NSString keys
and the search function casts the values to NSNumber, which it may
be valid for other parts but not for this library.
The real fix would be to store the property keys as NSNumbers as
they are uint32_t at the end. However, this may lead to a great
refactor in the library.
With this fix, we can match the search for a property in a
MAPIStoreFallback folder, such as Notes or Deleted Items, or
MAPIStoreFolder properties (ie: search for a subfolder) or
for MAPIStoreFAIMessages in a folder.
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.
This change is required as oxcfxics is asking for sorting
using this property.
We fake this property on GCS folders (Tasks, Calendar, Contacts)
using c_lastmodified column.
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.