fix(calendar): Fix getting the permissions of the user

[nickvergessen]

• Resolves: Schedule meetings inside Talk calendar#6516 (comment)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

Do we want to open this box? I assume getkey, getUri, getDisplayName and getDiplayColor will have the same problem, as the values may be different for the sharer and the sharees? 🙊

[nickvergessen]

• Well, we somewhat need it for Ability to quickly schedule a meeting spreed#6292 aka Schedule meetings inside Talk calendar#6516 otherwise we can not filter the calendars to only show the ones that the user can actually create events in.
• And if the others are affected as well, yes we somewhat need to fix them as well.
• The URI and name is already overwritten, so the knowledge for whom we get the calendars should be there?

[ChristophWurst]

I get that we need to fix it. I'm just wondering if we should take a different approach. If you got the calendar objects through \OCP\Calendar\IManager::getCalendarsForPrincipal I'd expect the permissions to already be specific to the principal passed there, and not having the need to specify the principal another time later on.

[miaulalala]

You could add a new method on the IManager that only returns writable calendars, and filter directly in this method.

[nickvergessen]

If you got the calendar objects through \OCP\Calendar\IManager::getCalendarsForPrincipal I'd expect the permissions to already be specific to the principal passed there

Also makes sense. Should we add a new method which does that, or add a new method which has the current (unexpected) behaviour, or not have the old behaviour anymore at all.

[nickvergessen]

You could add a new method on the IManager that only returns writable calendars, and filter directly in this method.

If getPermissions is correct this should not be needed anymore as the OCP consumer can easily filter.

[nickvergessen]

So, fixed the permissions. ✅

For the color and the name, I would do a DB query in CalendarProvider::getCalendars against the oc_properties table, in lack of another good abstraction (I tried OCA\DAV\DAV\CustomPropertiesBackend but that requires a PropFind object, which is failing to generate in OCS requests with Could not resolve Sabre\DAV\ICollection! Class can not be instantiated).

Or does someone have better ideas that can be implemented until end of the week?

[miaulalala]

If you get the calendars via the IManager, isn't that (color, displayName) already contained within the calendarInfo?

[ChristophWurst]

Color and name need properties lookup. Let's tackle that separately when we need it.