aboutsummaryrefslogtreecommitdiffstats
path: root/calendar/lib/SabreDAV/lib/OldSabre/CalDAV/Backend/SharingSupport.php
blob: 626eade8e75446b5aa4ea12d9cf257860050c24e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
<?php

namespace OldSabre\CalDAV\Backend;

/**
 * Adds support for sharing features to a CalDAV server.
 *
 * Note: This feature is experimental, and may change in between different
 * SabreDAV versions.
 *
 * Early warning: Currently SabreDAV provides no implementation for this. This
 * is, because in it's current state there is no elegant way to do this.
 * The problem lies in the fact that a real CalDAV server with sharing support
 * would first need email support (with invite notifications), and really also
 * a browser-frontend that allows people to accept or reject these shares.
 *
 * In addition, the CalDAV backends are currently kept as independent as
 * possible, and should not be aware of principals, email addresses or
 * accounts.
 *
 * Adding an implementation for Sharing to standard-sabredav would contradict
 * these goals, so for this reason this is currently not implemented, although
 * it may very well in the future; but probably not before SabreDAV 2.0.
 *
 * The interface works however, so if you implement all this, and do it
 * correctly sharing _will_ work. It's not particularly easy, and I _urge you_
 * to make yourself acquainted with the following document first:
 *
 * https://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt
 *
 * An overview
 * ===========
 *
 * Implementing this interface will allow a user to share his or her calendars
 * to other users. Effectively, when a calendar is shared the calendar will
 * show up in both the Sharer's and Sharee's calendar-home root.
 * This interface adds a few methods that ensure that this happens, and there
 * are also a number of new requirements in the base-class you must now follow.
 *
 *
 * How it works
 * ============
 *
 * When a user shares a calendar, the updateShares() method will be called with
 * a list of sharees that are now added, and a list of sharees that have been
 * removed.
 * Removal is instant, but when a sharee is added the sharee first gets a
 * chance to accept or reject the invitation for a share.
 *
 * After a share is accepted, the calendar will be returned from
 * getUserCalendars for both the sharer, and the sharee.
 *
 * If the sharee deletes the calendar, only their share gets deleted. When the
 * owner deletes a calendar, it will be removed for everybody.
 *
 *
 * Notifications
 * =============
 *
 * During all these sharing operations, a lot of notifications are sent back
 * and forward.
 *
 * Whenever the list of sharees for a calendar has been changed (they have been
 * added, removed or modified) all sharees should get a notification for this
 * change.
 * This notification is always represented by:
 *
 * OldSabre\CalDAV\Notifications\Notification\Invite
 *
 * In the case of an invite, the sharee may reply with an 'accept' or
 * 'decline'. These are always represented by:
 *
 * OldSabre\CalDAV\Notifications\Notification\Invite
 *
 *
 * Calendar access by sharees
 * ==========================
 *
 * As mentioned earlier, shared calendars must now also be returned for
 * getCalendarsForUser for sharees. A few things change though.
 *
 * The following properties must be specified:
 *
 * 1. {http://calendarserver.org/ns/}shared-url
 *
 * This property MUST contain the url to the original calendar, that is.. the
 * path to the calendar from the owner.
 *
 * 2. {http://sabredav.org/ns}owner-principal
 *
 * This is a url to to the principal who is sharing the calendar.
 *
 * 3. {http://sabredav.org/ns}read-only
 *
 * This should be either 0 or 1, depending on if the user has read-only or
 * read-write access to the calendar.
 *
 * Only when this is done, the calendar will correctly be marked as a calendar
 * that's shared to him, thus allowing clients to display the correct interface
 * and ACL enforcement.
 *
 * If a sharee deletes their calendar, only their instance of the calendar
 * should be deleted, the original should still exists.
 * Pretty much any 'dead' WebDAV properties on these shared calendars should be
 * specific to a user. This means that if the displayname is changed by a
 * sharee, the original is not affected. This is also true for:
 *   * The description
 *   * The color
 *   * The order
 *   * And any other dead properties.
 *
 * Properties like a ctag should not be different for multiple instances of the
 * calendar.
 *
 * Lastly, objects *within* calendars should also have user-specific data. The
 * two things that are user-specific are:
 *   * VALARM objects
 *   * The TRANSP property
 *
 * This _also_ implies that if a VALARM is deleted by a sharee for some event,
 * this has no effect on the original VALARM.
 *
 * Understandably, the this last requirement is one of the hardest.
 * Realisticly, I can see people ignoring this part of the spec, but that could
 * cause a different set of issues.
 *
 *
 * Publishing
 * ==========
 *
 * When a user publishes a url, the server should generate a 'publish url'.
 * This is a read-only url, anybody can use to consume the calendar feed.
 *
 * Calendars are in one of two states:
 *   * published
 *   * unpublished
 *
 * If a calendar is published, the following property should be returned
 * for each calendar in getCalendarsForPrincipal.
 *
 * {http://calendarserver.org/ns/}publish-url
 *
 * This element should contain a {DAV:}href element, which points to the
 * public url that does not require authentication. Unlike every other href,
 * this url must be absolute.
 *
 * Ideally, the following property is always returned
 *
 * {http://calendarserver.org/ns/}pre-publish-url
 *
 * This property should contain the url that the calendar _would_ have, if it
 * were to be published. iCal uses this to display the url, before the user
 * will actually publish it.
 *
 *
 * Selectively disabling publish or share feature
 * ==============================================
 *
 * If OldSabre\CalDAV\Property\AllowedSharingModes is returned from
 * getCalendarsByUser, this allows the server to specify whether either sharing,
 * or publishing is supported.
 *
 * This allows a client to determine in advance which features are available,
 * and update the interface appropriately. If this property is not returned by
 * the backend, the SharingPlugin automatically injects it and assumes both
 * features are available.
 *
 * @copyright Copyright (C) 2007-2015 fruux GmbH (https://fruux.com/).
 * @author Evert Pot (http://evertpot.com/)
 * @license http://sabre.io/license/ Modified BSD License
 */
interface SharingSupport extends NotificationSupport {

    /**
     * Updates the list of shares.
     *
     * The first array is a list of people that are to be added to the
     * calendar.
     *
     * Every element in the add array has the following properties:
     *   * href - A url. Usually a mailto: address
     *   * commonName - Usually a first and last name, or false
     *   * summary - A description of the share, can also be false
     *   * readOnly - A boolean value
     *
     * Every element in the remove array is just the address string.
     *
     * Note that if the calendar is currently marked as 'not shared' by and
     * this method is called, the calendar should be 'upgraded' to a shared
     * calendar.
     *
     * @param mixed $calendarId
     * @param array $add
     * @param array $remove
     * @return void
     */
    function updateShares($calendarId, array $add, array $remove);

    /**
     * Returns the list of people whom this calendar is shared with.
     *
     * Every element in this array should have the following properties:
     *   * href - Often a mailto: address
     *   * commonName - Optional, for example a first + last name
     *   * status - See the OldSabre\CalDAV\SharingPlugin::STATUS_ constants.
     *   * readOnly - boolean
     *   * summary - Optional, a description for the share
     *
     * This method may be called by either the original instance of the
     * calendar, as well as the shared instances. In the case of the shared
     * instances, it is perfectly acceptable to return an empty array in case
     * there are privacy concerns.
     *
     * @param mixed $calendarId
     * @return array
     */
    function getShares($calendarId);

    /**
     * This method is called when a user replied to a request to share.
     *
     * If the user chose to accept the share, this method should return the
     * newly created calendar url.
     *
     * @param string href The sharee who is replying (often a mailto: address)
     * @param int status One of the SharingPlugin::STATUS_* constants
     * @param string $calendarUri The url to the calendar thats being shared
     * @param string $inReplyTo The unique id this message is a response to
     * @param string $summary A description of the reply
     * @return null|string
     */
    function shareReply($href, $status, $calendarUri, $inReplyTo, $summary = null);

    /**
     * Publishes a calendar
     *
     * @param mixed $calendarId
     * @param bool $value
     * @return void
     */
    function setPublishStatus($calendarId, $value);

}

© 2014-2024 Faster IT GmbH | imprint | privacy policy