fix(proposal): notify invited participants when a proposal is converted to an event#8532
Conversation
|
Thank you for the PR, I see the issue, can you link a existing GH ticket to this PR (if there is one) also the tests will need to get fixed. |
|
Hi @SebastianKrupinski, thanks for the quick look! I didn't open a dedicated issue for this. The closest reference is the related PR #8284, which addresses the same problem (a converted meeting proposal not reaching the invited participants) on an older Calendar version. That fix forced a fresh UID for the event, but it no longer applies to 6.5.x: convertProposal() was reworked to find and convert the existing blocker keeping the proposal's UID, so forcing a new UID would actually break the per-UID update on the participants' side. On the current code the root cause is different: convertProposal() writes the finalized event only to the organizer's calendar (applyCalendarBlockersOrganizer()) and never notifies the participants, while proposal creation (syncCalendarBlockers()) calls both the organizer and the participant paths. This PR adds the missing applyCalendarBlockersParticipant() call, so the invitees' tentative blocker gets updated into the real event via iTIP (same UID). Tested on Calendar 6.5.0 / Nextcloud 32 with two users. Pushed a test update: testConvertProposalSuccess now mocks the participant lookup (getByEmail) and asserts that the internal participant is notified via handleIMip when a proposal is converted. That fixes the failing unit test and adds coverage for the new behavior. Happy to split it into a dedicated test or add stricter assertions on the iTIP payload (e.g. METHOD:REQUEST and the recipient UID) if you prefer. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
41e29c5 to
bccff61
Compare
…ed to an event Signed-off-by: AlessioDiPretoro <alessiodipretoro@gmail.com>
bccff61 to
65c2741
Compare
|
Tested working. Made a couple small changes, a) squashed commits |
|
/backport to stable6.5 |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Summary
When the organiser converts a meeting proposal into a real event, the invited
participants do not receive the event. They keep the tentative "[Proposed]"
blocker in their calendar indefinitely.
Steps to reproduce
tentative blocker — the finalised event never reaches B.
Root cause
ProposalService::convertProposal()writes the finalised event only to theorganiser's calendar (
applyCalendarBlockersOrganizer()), but never sends theiTIP scheduling message to the participants. At proposal creation time,
syncCalendarBlockers()correctly calls bothapplyCalendarBlockersOrganizer()and
applyCalendarBlockersParticipant(); the conversion path is missing thesecond call.
Fix
After writing the organiser's event, also call
applyCalendarBlockersParticipant()with the finalised event. Since the event keeps the proposal's UID, the iMIP
message (
handleIMipwith['absent' => 'create']) updates the participants'existing tentative blocker into the real event.
How tested
correctly replaced by the finalised event. Verified on staging and production.