As the stored context from initialisation may have changed
by `setContext` by other operations when acting as a OpenChange
library. This would make having a login set to nil and forcing
a NSException when it attempts to set a nil key at
[SOGoAppointmentFolder:roleForComponentsWithAccessClass:forUser]
inside [SOGoAppointmentFolder:initializeQuickTablesAclsInContext].
Happened in an imported vevent from Mozilla Thunderbird.
The crash was:
Sep 14 15:49:38 sogod [21063]: <0x6442DBF8[SOGoAppointmentFolder]:personal> missing 'c_startdate' in record?
Sep 14 15:49:38 sogod [21063]: <0x6442DBF8[SOGoAppointmentFolder]:personal> missing 'c_enddate' in record?
2015-09-14 15:49:38.927 sogod[21063] NGCalendarDateRange.m:37 Assertion failed in NGCalendarDateRange(instance), method initWithStartDate:endDate:. startDate MUST NOT be nil!
EXCEPTION: <NSException: 0x7fb96b3c0ed8> NAME:NSInternalInconsistencyException REASON:NGCalendarDateRange.m:37 Assertion failed in NGCalendarDateRange(instance), method initWithStartDate:endDate:. startDate MUST NOT be nil! INFO:(null)
The relevant ICS file lines are the following ones:
BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E00800000000901646A7234BCE01000000000000000010000000E9152C8FF1C27D488C91967FAAFCC2B0
RECURRENCE-ID:20140513T100000Z
DURATION:PT1H
CLASS:PUBLIC
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CN=krsny >>
Ann Thierry K:mailto:krsny@example.com
END:VEVENT
When returning contacts we have to supply also the domain field.
Because in a multidomain environment UIDField is unique only in
the domain so an user must be identified as uid@domain.
So when creating http requests from client side, we have to use
uid@domain instead of only uid so the SOGoUser created on server
side when parsing the requests is created properly.
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
A CSS identifier can't start with a digit, so when a folder name does,
a '_' character is appended at the beginning of its CSS identifier.
The check for this first character used the `isdigit()` function, which
takes a `char` argument, while `[self objectAtIndex: 0]` returns a
`unichar`, i.e. a 16-bit unsigned integer. This caused some non-digit
characters to pass this check (e.g. Chinese characters), ending up with
an underscore at the beginning of the folder name.
This method is used everywhere to try to retrieve the login of the user
(and normally use the return value to [SOGoUser initwithLogin: ...])
In multidomain environments (with DomainLessLogin = false) there were
several paths (mostly in SOGoAppointmentObject.m) that were trying to
create SOGoUser objects with incorrect login: using only the uid part,
not full email. Then like domain based uid was enabled, these users
had DomainLessLogin set to true and further calls tried to authenticate
only with the uid part (and they should not).
This affects to several methods in:
* ActiveSync/SOGoActiveSyncDispatcher.m
* Appointments/SOGoAppointmentFolder.m
* Appointments/SOGoAppointmentObject.m
* Appointments/SOGoCalendarComponent.m
* SOGoSAML2Session.m
Probably a few features related with calendars are now fixed or working
as intended in multidomain environments where the email is used as login