Depend of the current workflow this paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
Conflicts:
SoObjects/SOGo/SOGoUserManager.m
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
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.
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
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.
