does this issue apply to the enterprise version of Kolab 16 as well? We're currently evaluating Kolab (opensource version) to see if it fits our needs, but incomplete ActiveSync would be somewhat of an issue for us.

Fixed in 91e57e1f7367.

Submitting patch for review blocked due to https://git.kolab.org/T5462

Nobody with a support subscription runs in to this "problem", therefore nobody needs this "feature", and it is therefore closed off as irrelevant.

Correcting the priority from 60/40 to Normal

Hi All,

@machniak is there any update to how streamlining Activesync subscription logic may work?

Wouldn't the simple solution to be allow folders to be created as subfolders of INBOX @machniak

What is more. When user receives iTip response for an exception and updates the event, Outlook will incorrectly send Sync-Add command for the new exception, which then creates a duplicate object. Which leads to a "missing" event in Roundcube and error in syncroton log. This in itself is another issue, but I see that with correct ExceptionStartTime Outlook does not send such requests.

So, I started working on this. I thought it's reasonably simple to implement, but testing this with Outlook 2013 I see a lot of strange comminication that is not described in the documentation. It sends redundant Sync commands with event updates, so in the end, after accepting an invitation the event ends up being still in un-responded state.

Fixed.

no, I didn't

@adomaitis Looks like both DayOfWeek and Until are optional. In this case I think we just should not include DayOfWeek in the response. Did you test that?

SendResponse element was added in version >=16.0 of the ActiveSync protocol, which means it is optional and can be excluded from the initial implementation. Also, from what I see it is about calendar events. I didn't found any information about handling of iTips for TODO (tasks), so they are probably ignored.

One additional change is required in the ldap_public config:

Note: To make the LDAP addressbook sources working we need two additional
	//       fields ('uid' and 'changed') specified in the fieldmap array
	//       of the LDAP configuration ('ldap_public' option). For example:
	//          'uid'     => 'nsuniqueid',
	//          'changed' => 'modifytimestamp',

This is done. Required configuration for Outlook:

$config['activesync_gal_sync'] = array('windowsoutlook');
$config['activesync_multifolder_blacklist_contact'] = array('windowsoutlook');

Fixed.

While using constant folder identifiers would be good long term solution, in meantime I've found a simpler way. With rS57c38b7aede3 the device will correctly handle folder renames and re-synchronize folder hierarchy and renamed folder content. Closing.

Fixed in cae366edcab1b.

Activesync supports reminders (alarms) only as "the number of minutes before a calendar item start time". So, we can just ignore these alarms or check if the datetime is before start time of the event and calculate number of minutes.

You are right. It's not implemented at all.

I also think that revealing activesync_init_subscriptions setting to users may be too complicated and confusing for most of them. So, I'd keep this option as is.

@adomaitis, committed 1d7e1237f2d to master. I don't know if there's anything more we can do here.

Confirmed. The problem here is that Outlook completely ignores the error we send in response to Sync request (after FolderUpdate). It should re-synchronize folders hierarchy according to the protocol specification.

Outlook and MS ... why I'm not surprised ...
let me know about the commit, I will try on my side.

@adomaitis I'm testing a fix and can't make Outlook display an error. I tried valid ActiveSync response with different error codes and even http error 500. In all cases Outlook just ignores the error and displays the folder as any other folder. So, while I'll commit the change it looks that it's not possible to tell Outlook the operation failed.

Note to myself: See https://msdn.microsoft.com/en-us/library/gg651087(v=exchg.80).aspx for list of possible error status codes. Looks like code 3 might suit the best this case, but there are a few other cases that we might want to distinguish in error code.

Looks like you are right. There's a TODO entry in the folder creation code to throw exception on error, but it's not implemented and indeed no error is returned to the client. However, throwing an exception here is not enough, we need some more code in the Syncroton library itself to handle nicely the exception (returning properly formatted response instead of just a http error).

It is because syncroton uses authentication cache. So, when the username is in the cache kolab_auth plugin (which logs userlogins errors) is bypassed. We need some additional code in kolab_sync::authenticate(), probably should depend on Roundcube's log_logins setting.

Done. It does create folder names similar to these known from ActiveSync settings in Roundcube. Also iRony uses similar technique. So, the unification is good, but likely there's still a place for improvement. If we could agree on some precise unified format (with all corner cases described) we could then implement it for all of these three systems.

Or @vanmeeuwen @greve how about simplifying this even further:

I would even go as far to say (as politely as I can) that the options @vanmeeuwen are proposing are just complicating things.

I agree with all of the above, including

Raising priority of this and assigning (-oh - It's already assigned correctly)

In T2055#31554, @vanmeeuwen wrote:

It seems most straight-forward to me to attempt to flatten the hierarchy to work around the majority of these issues, and engineer a way to name folders in such a way that the client can present the folders to the users in such a way that they are somewhat recognizable (i.e., why not make "Other Users/jane.doe/Calendar" appear as "Calendar (jane.doe)" or "jane.doe Calendar"?).

I believe I have provided what I thing is a coherent and comprehensive description of the considerations made in this ticket, and elsewhere, to the new tickets.

It seems reasonable to expect that if an ActiveSync client creates a folder, this folder must therefore also be synchronized with all other ActiveSync devices by default, and any manual intervention via the web client is only required in order to opt out of a particular device synchronizing such folder.

It seems clear that folder merging (all folder's contents will appear to the client application as if they originate from a single folder) is far, far from the ideal solution. In part, T224 has been initiated with that in mind specifically, since more and more newer clients appeared to support multi-folder in their respective client implementations. We've therefore switched from needing to whitelist every such newer device, to instead blacklisting whatever older device we might choose to continue to support.

This ticket has evolved in to T224, and T2055 and T2058 since. Your current entitlements also alleviate git.kolab.org from the support issues you may find yourself suffering from.

I agree that we're bloating this ticket with considerations that go past the white- vs. blacklist changeover. I'll create a sub-task and break the inheritance.

It seems this should now get some thought and insight from @seigo and then go over to @vanmeeuwen to make the call on how to proceed. Assigning to @seigo first.

In T224#31311, @machniak wrote:

In T224#31305, @greve wrote:

Would it display them all, or just the first/primary/top level one?

It would display only the Calendar folder as a top-level folder.

In T224#31305, @greve wrote:

Would it display them all, or just the first/primary/top level one?

In T224#31257, @machniak wrote:

In T224#31251, @greve wrote:

Does the "only Calendar" mean it shows only the main folder, or that it only shows Calendars, incuding hierarchy for the Symantec App?

It would display only the Calendar folder, without any hierarchy in this case.

In T224#31251, @greve wrote:

Does the "only Calendar" mean it shows only the main folder, or that it only shows Calendars, incuding hierarchy for the Symantec App?

It would display only the Calendar folder, without any hierarchy in this case.

Would such folder names be possible in the ActiveSync protocol?

We can set anything as a folder name.

Thank you, @machniak.

Problem Space

In T224#31230, @machniak wrote:

In T224#31227, @greve wrote:

But we're only seeing Calendar, Subcalendar2, Subcalendar4 and Subsubcalendar3 because both Subsubcalendar and Subsubcalendar2 are being hidden by the state of their parent folder and this behaviour is consistent across all devices?

Not consistent. According to my previous findings it would be:

1. Android: Flat list (no hierarchy): All except Subcalendar and Subcalendar3
2. iOS: the same as Android
3. Symantec app: All folders as in iOS, but with hierarchy.
4. Oultook: Flat list (no hierarchy): Calendar, Subcalendar2, Subcalendar4, Subsubcalendar3.

Note, that for mail folders it will look different.

In T224#31227, @greve wrote:

But we're only seeing Calendar, Subcalendar2, Subcalendar4 and Subsubcalendar3 because both Subsubcalendar and Subsubcalendar2 are being hidden by the state of their parent folder and this behaviour is consistent across all devices?

In T224#31224, @machniak wrote:

Not only deleted, but indeed IMAP allows for hierarchies with deleted parents. It may also exist but be unsubscribed (in general or for activesync only), or it may be a namespace root (which is also a kind of special folder and generally not subscibeable).

Not only deleted, but indeed IMAP allows for hierarchies with deleted parents. It may also exist but be unsubscribed (in general or for activesync only), or it may be a namespace root (which is also a kind of special folder and generally not subscibeable).

In T224#26147, @machniak wrote:

So, I tested some clients with my blacklist implementation and enabled folders hierarchies for all.
[...]

I've tested all special chars. It looks only two cause errors. It's "=EF=BF=BE" and "=EF=BF=BF". Fixed.

Ok, I investigated this case. I have no idea yet why but mb_convert_encoding() converts ISO-8859-1 string of "=FC=81" into (UTF-8) "=C3=BC=EF=BF=BE" (using quoted-printable encoding).

See T224.