Closed
Conversation
Contributor
Author
|
Oops. This is caused by me testing this with NC25 but diffing against master. Actually, I do not have the master branch running such that I could do real testing ... so this needs quite a bit of polishing. The commits should actually work with v25. |
Member
|
That is fine for a proof of concept |
25fe2fa to
5219c61
Compare
3167c73 to
4025649
Compare
50c14cc to
1195397
Compare
9bc44d7 to
c829cff
Compare
Contributor
Author
|
Ok, there was much more than mere compatibility between v25 and master. For the moment most tests seem to have passed. |
Contributor
Author
|
"continues integration" fails due to some S3 issues. I do not think that this is related to my changes. |
This was referenced Feb 17, 2023
c829cff to
5219c61
Compare
Contributor
Author
|
I have moved the SharingSupport stuff to a separate pull-requests as my impression currently is that this does not bring us closer to sending invitations, see #36766. |
76d5902 to
4ad3f07
Compare
This is basically the original commit, but with the addition that CalDavBackend::getCalendarObjectByUID() also takes object in writable shared calendars in to account and adjusts their uri s.t. the Sabre library can find the returned object uri in the user's calendar collection. Signed-off-by: Claus-Justus Heine <[email protected]>
Signed-off-by: Claus-Justus Heine <[email protected]>
… over private objects. Signed-off-by: Claus-Justus Heine <[email protected]>
4ad3f07 to
bad66ad
Compare
This was referenced Mar 12, 2024
Merged
Merged
Merged
Merged
Contributor
|
Looks like this one was solved with -> #45054 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Oh, wait a bit: this is just a study to sort things out. Hence the "Draft" attribute.
Disclaimer: this is not the answer to all problems and not "the solution". It's just a bit of code in order to test the scenario.
Summary
As indicated in the linked issue, support for writeable shared calendars is currently sub-optimal in several respects:
TODO
Checklist
I do not care ATM. This pull request is currently only "for the record" in order to support the discussions in #26668 with a little bit more than more than just words.
Explanations
As discussed in the linked issue #26668 invitations for events created in shared (then obviously writeable) calendars are not send.
There was an attempt in commit a9c313c which was then reverted in commit 98a93d5. The reasons for reverting were a couple of loose ends and the fact that a9c313c was incomplete: it only initiated the notifications to be send to the participants but did not address the problem that the underlying Sabre Dav library was not able to process the feedback (accept, deny, maybe) of the invited parties.
This pull request is then kind of a study: can we do it somehow, starting with the original commit and fixing the problem that replies are not properly processed.
The linked issue #26668 mentions a function
getUsersOwnCalendars()which at least nowadays is hardly used any more safe in one place. Instead, we have to inspectgetCalendarObjectByUID()as this is the real show stopper: if you start to examine things and try to understand why the responses of the invited parties are not processed, then you finally hit this point in the Sabre library:https://github.com/sabre-io/dav/blob/2d8f6d9b9851a3d5fec007b7033d86b1dc241663/lib/CalDAV/Schedule/Plugin.php#L492
This point is met when the invitees send back their responses (accept, decline, not yet). The problem is now that the API documentation states:
"unfortunately" NC sticks to this requirement, and consequently the referenced event cannot be found.
This pull-request just ignores this requirements and changes
getCalendarObjectByUID()such that it also finds objects in shared writeable calendars and adjusts their URI to the currently used..._shared_by_...layout.This seems to be enough to establish the basic functionality which unfortunately still is advertised by the Nextcloud calendar frontend but up to now just does not work and irritates (not only end-)users.
As mentioned at the start of this too-long-a-comment: I do not consider this as "the solution". Just a code study ...