Server: shared calendar's color and name not editable by sharee (on a per-sharee basis)

[georgehrke]

Scenario:
user1 shares their calendar with user2.
user2 can change the visibility without affecting user1, because we use a custom attribute for that.

When user2 changes the color, the new color will also show up for user1.
When user2 changes the name, the new name will also show up for user1, additionally (user1) will just be appended without checking if it's already in there, resulting in something like: ownCloud(user1) asd(user1), better use the CS:summary instead ;)

This conflicts with the caldav sharing standard: https://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt#L761

We should go with a per user table for calendar and address books properties.

[georgehrke]

We have two different approaches here:

1. Add a dedicated entry in calendars for each sharee. This will massively increase the size of the calendars table. We will also have to take care of updating the calendars table when adding or removing users from groups. Additionally the sync token has to be updated for all calendars (instead of one) when editing calendar objects.

1. Store the following list of properties for a sharee inside the properties table upon editing them. The corresponding properties for the sharer/owner will be stored inside calendars just like now. If a sharee doesn't edit these properties, they will come straight from the calendars table. This will generally increase the amount of necessary SQL queries, but will be way less error-prone.

• displayname
• description
• calendarorder
• calendarcolor
• transparent

@MorrisJobke @nickvergessen @LukasReschke I'd personally prefer 2. Which option do you prefer?

[nickvergessen]

1 will also not work easily, since all events have the id stored etc. So 2 sounds reasonable

[georgehrke]

Ok, let's go with option 2.