machniak@kolabsys.com:
As this behaviour would need to be optional and manageable by the user, I see this as a user Preference, e.g. a checkbox "Enable ActiveSync on newly created folders" in Preferences > Server Settings > Main Options.

Syncroton already has a similar option, however it is not user configurable.

// When a device is reqistered, by default a set of folders are
// subscribed for syncronization, i.e. INBOX and personal folders with
// defined folder type:
//     mail.drafts, mail.wastebasket, mail.sentitems, mail.outbox,
//     event, event.default,
//     contact, contact.default,
//     task, task.default
// This default set can be extended by adding following values:
//     1 - all subscribed folders in personal namespace
//     2 - all folders in personal namespace
//     4 - all subscribed folders in other users namespace
//     8 - all folders in other users namespace
//    16 - all subscribed folders in shared namespace
//    32 - all folders in shared namespace
$config['activesync_init_subscriptions'] = 0;

As user suggested, this should be user-configurable and per device. So, the option should be placed where we configure folders for synchronization.

I suppose this would be a flag set in a device configuration stored in IMAP annotation for activesync. According to this setting syncroton would handle folders as requested.

I'm not sure we need all those options from syncroton, maybe we should simplify this to:

1. Selected folders (as it is now)
2. All subscribed folders
3. All existing folders

I agree with the suggested options by @machniak, since they combine in to the following combinations of bitflips for the underlying Syncroton:

1. Selected folders only (0),
2. All subscribed folders (1+4+16),
3. All folders (2+8+32)

Great to see! This will definitely go a way to enriching the experience of both users on Outlook, and also on mobile devices too.

This so good to see!

Once implemented, it will certainly mean we can look to Activesync as more than a mere mobile device protocol, but this could make MAPI integration considerably less important as all new Outlook versions have Activesync enabled.

Further, I know @vanmeeuwen has discussed making multiple calendars and groupware objects viewable in Outlook, as the current Activesync flattens the structure.

Perhaps it would be useful to do a MAPI to Activesync comparison so that we can compile a list of features that we could include in Activesync to make MAPI considerably less important. Such would need to include freebusy scheduling, but solving this task alone would make a big difference.

What would be even better is if the server could detect when an Outlook connection is initiated via Outlook, and automatically set Option 2 outlined by @vanmeeuwen (flags 1, 14, 16).

Something along the lines of:

1. Syncroton requests client id
2. If Outlook, enable flags 1, 14, 16 automatically
3. If not, allow user to set subscription options

I think this would be a much more 'smart' enhancement. We now expect a lot more of Activesync and see it more than as a mobile device protocol, but as the replacement for MAPI.

Thoughts @machniak @petersen ?

Enabling syncing of all (selected) folders is one thing and disabling "flat mode" is another. I think this ticket is about the former.

As for the "flat mode", I'm not very optimistic about this. Last time I tried Outlook supported folders hierarchy only for mail. Also, handling of folders hierarchy is different on different clients and different types of objects. Also problematic is handling of incomplete hierarchies e.g. when you subscribe subfolder of Calendar folder, but not the Calendar itself. I could implement an option in syncroton to disable "flat mode" globally, but testing all kind of apps (and versions) would take really much time.

Yes @machniak you're certainly right - it's about the former indeed.

Apologies for the likely misunderstanding - what I was trying to suggest, is that as well as resolve this - we undergo an evaluation of all the areas that the Activesync falls short in comparison to MAPI (and compile a list of those)and thus likely to prevent it from providing an enterprise-class experience to an enterprise-grade desktop client, that is Microsoft Outlook. To clarify, the folder hierarchy and 'flat mode' was a mere example of one of those.

Overall, what I'm trying to suggest is that it makes much more sense to improve the already great Kolab Activesync, and resolution of this ticket will be a massive step, so that it can be the only means to power Outlook, thus the need of pursuing MAPI down the line even when it is more developed will be redundant. Only thing is that the users of older Outlook versions (2010 and older will get left behind but that's not a big deal - they'll upgrade).

With the above in mind @machniak @petersen @vanmeeuwen,

I would propose we create a ticket: Issues preventing Kolab Activesync from supporting Outlook fully, and then moving this task, along with the other task (flat vs expanded hierarchies) and all other subtasks under that.

What are your thoughts?

In T1244#20657, @vanmeeuwen wrote:

I agree with the suggested options by @machniak, since they combine in to the following combinations of bitflips for the underlying Syncroton:

1. Selected folders only (0),
2. All subscribed folders (1+4+16),
3. All folders (2+8+32)

With regards to the original issue, we're really dealing with something other than this.

The above is presumed to 'activate' folder synchronization 'upon initial registration'. That's fine, and we should use that.

The default for a folder created by one ActiveSync device though should probably force all other ActiveSync devices to also synchronize the new folder (by default).

There would not need to be an option to prevent other ActiveSync clients from being subscribed to new folders created by other ActiveSync devices, nor would this option need to be taken in to account for this scenario.

For simplicity sakes, it may even be worth considering removing the option for folder syncing altogether.

Kolab's implementation is the only one which has such a facility, having tried Office 365, Backspace Hosted Email, OpenXChange, etc.

I would like to make the somewhat outrageous proposition that folder synchronisation should simply mirror IMAP folder subscriptions in their entirety. When a folder gets unsubscribed from IMAP, it should simultaneously do so on Activesync and vice versa. This would bring Kolab in line with pretty much every other implementation. Further, the preferences of folder syncing are normally set on the device, rarely server-side.

In my opinion, the Activesync model should replicate the IMAP/CardDAV/CardDAV model - the only tangible difference to a USER is that Activesync provides PUSH to a mobile device where devices like iOS ones don't support IDLE.

@vanmeeuwen

Yes @vanmeeuwen I understand point you make - the user appears to be frustrated that that the default behaviour for Activesync is that when a new folder is created on Activesync, it doesn't force all other Activesync devices to subscribe it.

In T1244#22244, @hsmith wrote:

For simplicity sakes, it may even be worth considering removing the option for folder syncing altogether.

That's a sensible suggestion.

From a management perspective, I think it's not such a terrible idea to be able to restrict certain folders for certain devices, though.

I may not want ALL data on EVERY device.

But the usability should perhaps be modelled more around restricting access on a folder by folder basis, rather than granting access on a folder by folder basis.

Hello @greve - nice to (informally meet you, Sir)

This is certainly true, from both a management and security perspective - you may want to restrict access to certain files, for instance the 'Confidential Client Details' folder on the highly mobile salesman's Galaxy S6, should he lose it, and be irresponsible enough not to password protect it.

So yes, you may certainly not want every folder on every device.

I do believe that this should be less protocol-specific, but perhaps these enforcing rules you mention could be all-encompassing, across all Protocols. Activesync may not need be here forever, though security concerns will :)

I'm sure @petersen @vanmeeuwen as Systems Administrators and particularly @machniak who is in charge of Activesync would agree that it is a necessary evil. It goes without saying that open protocols are by far preferable in every sense. Activesync is far more strenuous on a server than the open protocols, and its only real advantages are:

1. Push to mobile devices - these can't do IMAP idle, as it would be far too strenuous for battery purposes.
2. The second necessary evil which is Outlook - it is seemingly easier to configure Outlook <2013 &+ with Activesync rather than install plugins of varying quality

I'm sure it is everybody's hope that one day Activesync will no longer be necessary due to:

1. Outlook supporting CalDAV/CardDAV natively - one can dream :)
2. Implementing Proprietary push protocols (like Apple's mobile-friendly PUSH-IMAP extension)
3. JMAP replacing IMAP which has push as native

Aaron @seigo mentioned Guam will be extended to more than filtering of groupware folders, and can also restrict access - so perhaps it needs to be done on an IMAP level using Guam?

So with further simplicity in mind, I would even suggest removing the option to sync unsubscribed folders in IMAP @vanmeeuwen

If a user has purposefully UNSUBSCRIBED it in IMAP, it should also be reflected through to Activesync too. Perhaps then we now need to have just: Subscribed folders, (or selected folders, if this really needs to remain?)

And then eventually work on using GUAM to work on folder restrictions once it is fully successful in its first use case which is filtering out groupware folders from non Kolab-aware IMAP clients :)