-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
send invitations for shared calendars #9609
send invitations for shared calendars #9609
Conversation
17fdafd
to
95165f9
Compare
note to myself: Can this solution cause issues with infinite invitation loops? Should the address list only be limited to the current user accessing it and not to all users possibly having access to it? |
Possibly
Yes, just replace |
Saved this patch as a gist because I might need the Principal changes for future work: https://gist.github.com/georgehrke/ce704d4370b8e9d60231f2ea35d15f0c |
95165f9
to
b11a043
Compare
Codecov Report
@@ Coverage Diff @@
## master #9609 +/- ##
============================================
- Coverage 51.15% 2.07% -49.09%
- Complexity 25692 25697 +5
============================================
Files 1568 1568
Lines 88039 88052 +13
============================================
- Hits 45036 1824 -43212
- Misses 43003 86228 +43225
|
Signed-off-by: Georg Ehrke <developer@georgehrke.com>
b11a043
to
a9c313c
Compare
In contrast to the previous patch this doesn't check whether the current user is a rw-share, but then a person with a ro-share should not be able to update calendar objects and trigger the |
$oldObj = null; | ||
} | ||
|
||
$this->processICalendarChange($oldObj, $vCal, $addresses, [], $modified); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if new participant addresses don't have an e-mail set does this do 💥 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is properly handled by processICalendarChange
.
As I said in the methods comment, this is basically just a copy of parent:: calendarObjectChange
, i just replaced line 133. That's why I also didn't write tests 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough!
Tests would be appreciated as this is something we might else easily break in the future |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and works 👍
Reverted in #15676 |
fixes #3830