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"?).

If you're in the File section of the web client, invitations about being invited to a collaborative session show up.

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#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.

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#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).

In T224#26147, @machniak wrote:

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

In T1523#25021, @machniak wrote:

In T1523#25018, @greve wrote:

Hasn't the choice which calendar to store something into upon acceptance been a feature request recently? So then the user could always choose where to store a new event, and that would default to their private calendar.

User has this possibility if the event wasn't found, but we check only personal folders. Otherwise "Save in..." is not displayed.

In T1523#24982, @machniak wrote:

Privileges to shared folders are managed by admins.

In T1523#24832, @machniak wrote:

1. Consider a situation in which User A delegated his calendar to User B. Now, if User B will try to handle such itip reply in the name of User A, he will encounter a problem. User B has no information about which shared folders User B has access to. So, this may work if both have access to this shared folder, but what if not?

@vincent You have done the hard work of writing them all up.

Please note, from: https://docs.kolab.org/installation-guide/winterfell/index.html

In T1244#22244, @hsmith wrote:

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

BTW: Still seeing these after the recent Kolab Now service window. Should it have resolved them or is this something new/residual?

FWIW, my private account (on apps.kolabnow.com) is still failing in the same way right now. Let me know if/how to provide debugging info.

Torsten: Look for events that have a UID of https://some.some.some/some/some -- these apparently make SabreDAV choke and die badly.

Torsten reports this also happens to him with his personal server, no HA Proxy involved: https://github.com/bitfireAT/davdroid/issues/542#issuecomment-113499114

Ah, interesting. Indeed I tried kolabsystems.com. So I think we narrowed this down enough that it should be thrown over to Ops for looking at HAProxy, and perhaps documenting what has been going on there also for future deployments.

Interesting, thanks a lot for that.

Update https://github.com/bitfireAT/davdroid/issues/542#issuecomment-112361204 copied here for convenience:

section 3.6 of RFC 3253 is the relevant RFC section. Wondering whether "(DAV:supported-report)" is what should be issued if REPORT is supported. Also raised that question with the client:

This comment raises the question of whether 404 is a valid response to a valid URL in case there are no entries to report. This may warrant checking against the specification and other implementations.

Since this impact development only, which is focused purely on moving ahead the state of the art, I have no objections.