Allow to have multiple links per public calendar

[tcitworld]

Needed for #20096

• Test with cdav-library
• Adapt Activity and everything else that uses '\OCA\DAV\CalDAV\CalDavBackend::publishCalendar' events

Adding a public link is still the old way:

<o:publish-calendar xmlns:o="http://calendarserver.org/ns/"/>

Removing all public links is just like we used to unpublish

<o:unpublish-calendar xmlns:o="http://calendarserver.org/ns/"/>

We now have the following for unpublishing a specific link (we can change nc:unpublish-calendar to something else).

<o:unpublish-calendar xmlns:o="http://nextcloud.com/ns/">urltounpublish</o:unpublish-calendar>

The public URLs are exposed this way:

<x1:publish-urls xmlns:d="DAV:" xmlns:x1="http://nextcloud.com/ns/">
	<d:href>urltopublish</d:href>
	<d:href>secondurltopublish</d:href>
</x1:publish-urls>

publish-url is still available and gives the first URL

<x1:publish-url xmlns:d="DAV:" xmlns:x1="http://calendarserver.org/ns/">
	<d:href>urltopublish</d:href>
</x1:publish-url>

Note : not sure if the collection of public calendars should contain unique calendars or one calendar per public link. Need help here @georgehrke.

[georgehrke]

I actually had something slightly different in mind:

1. If you put multiple <d:href> into one <x1:publish-urls>, you can't save different permissions for them. Different permissions (and other fields like show busy only, expiry date, etc.) will require a slightly more complex XML structure.

Our current response for ordinary shares looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:oc="http://owncloud.org/ns">
	<D:response>
		<D:href>/foo</D:href>
		<D:propstat>
			<D:prop>
				<oc:invite>
					<oc:user>
						<D:href>principal:principals/users/admin</D:href>
						<oc:common-name>John Doe</oc:common-name>
						<oc:invite-accepted/>
						<oc:access>
							<oc:read-write/>
						</oc:access>
					</oc:user>
				</oc:invite>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
</D:multistatus>

What i had in mind was something like this:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:oc="http://owncloud.org/ns">
	<D:response>
		<D:href>/foo</D:href>
		<D:propstat>
			<D:prop>
				<oc:invite>
					<oc:user>
						<D:href>principal:principals/users/admin</D:href>
						<oc:common-name>John Doe</oc:common-name>
						<oc:invite-accepted/>
						<oc:access>
							<oc:read-write/>
						</oc:access>
					</oc:user>
                                        <nc:public>
						<d:href>urltopublish</d:href>
                                                <nc:label>Label for this read-only link</nc:label>
                                                <nc:expiry-date> 20201003T000000Z</nc:expiry-date>
						<oc:access>
							<oc:read/>
						</oc:access>
                                        </nc:public>
                                        <nc:public>
						<d:href>urltopublish2</d:href>
                                                <nc:label>Label for this read-write link</nc:label>
						<oc:access>
							<oc:read-write/>
						</oc:access>
                                        </nc:public>
                                        <nc:public>
						<d:href>urltopublish3</d:href>
                                                <nc:label>Label for this read-only with busy link</nc:label>
						<oc:access>
							<oc:read/>
                                                        <nc:busy-only/>
						</oc:access>
                                        </nc:public>
				</oc:invite>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
</D:multistatus>

@tcitworld Does that make sense? :)

EDIT: Similar to <nc:public>, we can also have <nc:public-email>, <nc:user-federated>, <nc:group-federated>, and possibly more.

[tcitworld]

Thanks for clarification ! Definitely makes sense. Would the public link elements be managed through oc:set and oc:remove as well ?

[tcitworld]

Also <nc:label> may reuse <oc:commonName> or <oc:summary> ?

[georgehrke]

Would the public link elements be managed through oc:set and oc:remove as well ?

Yes, with the exception of creating new published calendars. (because for using oc:set and oc:remove you need a d:href, but we don't want clients to pick a token themselves. It has to be generated randomly on the server).

For sharing a public link via email or federated shares, we would be using something like mailto:janedoe@example.com and nc-federated:johndoe@example.cloud as href.

Also <nc:label> may reuse <oc:commonName> or <oc:summary> ?

Yes, looking at the RFC, we should be using <oc:common-name> as a label and <oc:summary> as a note to sharees.

---

What should d:href look like for public calendars?
<d:href>http://example.com/remote.php/dav/public-calendars/token123</href> or <d:href>nc-public-token:token123</d:href>. I'm worried that the first one is too ambiguous and might cause conflicts if we add other sharing types later.

[tcitworld]

<d:href>http://example.com/remote.php/dav/public-calendars/token123 or <d:href>nc-public-token:token123</d:href>. I'm worried that the first one is too ambiguous and might cause conflicts if we add other sharing types later.

However we can't discover the public calendars collection, right? So the public-calendars endpoint would be hardcoded.

[georgehrke]

However we can't discover the public calendars collection, right? So the public-calendars endpoint would be hardcoded.

I think in that case I would still like to stick to <d:href>nc-public-token:token123</d:href> and then include the following:

<nc:public>
    <d:href>nc-public-token:token123</d:href>
    <nc:public-caldav-endpoint>
         <d:href>http://example.com/remote.php/dav/public-calendars/token123</href>
    </nc:public-caldav-endpoint>
    ...
</nc:public>

[georgehrke]

Moved to Nc 20 milestone, since we are past feature freeze

[georgehrke]

Off-topic:
@rullzer I feel like we could do a better job properly announcing feature freeze publicly :)
It wasn't even included in https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule for this release.

[MorrisJobke]

@georgehrke We seem to miss the next feature freeze as well. Sorry @tcitworld :/

[ChristophWurst]

and we are in beta again 😭

[codingHahn]

How is the status on this? The next feature freeze seems to be tomorrow

[tcitworld]

As per the labels, still being developed.

[skjnldsv]

Hey Thomas!
This PR has been on hold for a while, do we still want this?
I'm cleaning up things and suggest we close it otherwise.

Many conflicts and outdated history... 🙈

[skjnldsv]

Closing this pull request due to lack of recent activity and updates. We appreciate your contribution and encourage you to reopen or provide further updates if necessary. ☺️
Our aim is to keep the project moving forward with active collaboration. Thank you for your understanding and continued support! 🙏