fix(proposal): notify invited participants when a proposal is converted to an event

[AlessioDiPretoro]

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

1. User A creates a meeting proposal and invites user B.
2. User B votes/accepts a date.
3. User A converts the proposal into an event.
4. ❌ User A gets the event, but user B still only sees the original "[Proposed]"
   tentative blocker — the finalised event never reaches B.

Root cause

ProposalService::convertProposal() writes the finalised event only to the
organiser's calendar (applyCalendarBlockersOrganizer()), but never sends the
iTIP scheduling message to the participants. At proposal creation time,
syncCalendarBlockers() correctly calls both applyCalendarBlockersOrganizer()
and applyCalendarBlockersParticipant(); the conversion path is missing the
second 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 (handleIMip with ['absent' => 'create']) updates the participants'
existing tentative blocker into the real event.

How tested

• Reproduced the issue on Calendar 6.5.0 (Nextcloud 32) with two users.
• Applied the fix: after conversion, the invited user's tentative blocker is
  correctly replaced by the finalised event. Verified on staging and production.

[SebastianKrupinski]

Hi @AlessioDiPretoro

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.

[AlessioDiPretoro]

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]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[SebastianKrupinski]

Tested working.

Made a couple small changes,

a) squashed commits
b) the calendarUri and EventUri where not being used in applyCalendarBlockersParticipant so I removed them from the method and all call sites

[SebastianKrupinski]

/backport to stable6.5