“Show only own calendars” logic

[dilyanpalauzov]

When I setup a CardDAV/CalDAV account, the account has a current-user-principal URL property in terms of WebDAV. When the user provides the complete collection URL there might be no principal-URL, but with proper WebDAV-server there is a current-user-principal-URL.

For each collection, under Properties, DAVx⁵ shows the owner of the collection.

DAVx⁵ has the option to show only own collections. I expect that DAVx⁵ compares the owner of each collection to the DAV:current-user-principal value and decides on this criterion whether a collection belongs to the current user or to a different user. Albeit, DAVx⁵ uses apparently a different logic to determine, if a collection belongs to the currently registered user. The implemented logic is not explained at https://www.davx5.com/manual/accounts_collections.html or https://www.davx5.com/manual/technical_information.html.

Please tweak DAVx⁵ to handle as own collections/hide as foreign collections, the collections, whose owner is distinct from the value of DAV:current-user-principal.

[devvv4ever]

Hello Dilyan! Thanks for the input on this. Is this a real-life problem? Just asking because we've implemented the "Show only personal" option for a specific server (eGroupware) which needed this for certain users (namely admin users that have access to a lot collections) that were overwhelmed by a huge list of collections in the DAVx5 CalDAV tab.

[dilyanpalauzov]

The problem is that I see an option, which option does not do what I think it shall do. In such cases the option shall be hidden from the user.

I can provide a server to test the logic I described initially.

In any case, there is no documentation how DAVx⁵ determines, if a collection belongs to the logged in user.

[rfc2822]

That's true, currently it's quite customized for eGroupware (for whom this setting was initially made for). I think the owner solution wasn't applicable there, but I don't remember.

One will have to check again and maybe write some documentation :) (Or you can look it up in the source code)

[rfc2822]

Internal tracking: https://github.com/bitfireAT/davx5/issues/118

[sunkup]

Hello Dilyan @dilyanpalauzov ,

After some interal discussion, we decided to stick with the current implementation and document it. We chose to make a difference between whether a collection is considered "personal" or "owned" in regards to the current-user-principal. The internal logic for deciding whether a collection is personal is the following:

Collections are considered personal if listed in the homeset of current-user-principal. This is the criterion to filter out non-personal collections, when selecting "Show only personal" in the action menu (⋮).

See the documentation here: https://manual.davx5.com/accounts_collections.html#personal-collections

[dilyanpalauzov]

I do not understand the explanation. The current-user-principal has homesetS. Each homeset has collection(s).

So I see no criterion how to distingish between personal and shared collection, especially when DAV:owner is not consideres.

[rfc2822]

RFC 4791:

Description: The CALDAV:calendar-home-set property is meant to allow users to easily find the calendar collections owned by the principal. Typically, users will group all the calendar collections that they own under a common collection. This property specifies the URL of collections that are either calendar collections or ordinary collections that have child or descendant calendar collections owned by the principal.

We use this definition of owned for personal, which is not the same as DAV:owner == DAV:current-user-principal.

I don't understand the problem: If (and only if) a collection is in the current user's homesets, it's considered personal.

[dilyanpalauzov]

The account discovery first finds the current-user-principal, then the homesets under it, and finally the collections within the homesets. All of these are 'personal'.

How are non-personal collections discovered?

[rfc2822]

The account discovery first finds the current-user-principal, then the homesets under it, and finally the collections within the homesets. All of these are 'personal'.

Exactly.

How are non-personal collections discovered?

Most importantly over group-membership and read[-write]-proxy-for:

https://github.com/bitfireAT/davx5/blob/7b497af715557790c0783eee55c50027bd5759ed/app/src/main/java/at/bitfire/davdroid/servicedetection/RefreshCollectionsWorker.kt#L286-L289

This is for instance the case when admins are in an admin group and have read access to all collections (typical eGroupware case). Then the visible collections can be filtered to personal collections (which usually include collections that have been explicitly shared for the current user, so that they appear in the homeset).

[dilyanpalauzov]

So, the only way to have the filter „Show o Own Collections only“ is to use non standard calendar-proxy-read/calendar-proxy-write operations. I do not understand how the Group logic works here.

In any case davx5 does not document that it handles calendar-proxy-read/write. I think the documentation for that checkbox shall state, that the checkbox has only impact on servers supporting calendar-proxy-read/write. Ideally the option shall be hidden when the server does not do calendar-proyy-read/write.

[sunkup]

Yes, true. A principal may have multiple homesets. We should update that. This does however not change the definition by which DAVx5 decides whether a collection is personal or not.

Let me put it another way:
A homeset is considered personal, or not, depending on whether the current-user-principal has this homeset as CALDAV:calendar-home-set or not. Meaning that, a collection is considered personal, if the homeset which it belongs to has been set as CALDAV:calendar-home-set for the current-user-principal. (analogous for addressbooks)

Here is a piece of pseudo code which might explain it better than words:

if (collection.homeset in any currentPrincipalHomesets)
  // collection is personal!

I do agree with you that "personal" vs "owned" is misleading terminology in the UI, but as @devvv4ever said, this functionality was built for a specific server where calendars are shared into other principal homesets.