[Rikdekker]

• Resolves: PARTSTAT change on a single occurrence of a recurring event triggers METHOD:REQUEST re-invite to all other attendees #60452

Summary

When something changes for a single occurrence of a recurring event, every attendee gets an iMIP mail, even when nothing changed for them. This happens when an attendee declines one occurrence (processing the REPLY adds an override to the organizer's copy), and when the organizer adds or removes someone on one occurrence.

TipBroker::parseEventForOrganizer decides significance for the event as a whole, for two reasons:

• a new override grows every attendee's set of instance keys;
• significantChangeHash is computed over all components, so any new override changes it for everyone.

This PR decides significance per attendee instead, over the occurrences they take part in before or after the change. A new override that matches the occurrence it replaces, such as one that only stores another attendee's PARTSTAT, is not significant. Attendees' calendar copies are still updated; they just don't get a mail for it.

Testing

• 7 new unit tests in TipBrokerTest; 5 of them fail on master. The CalDAV unit suite passes (776 tests), and psalm and php-cs-fixer are clean.
• Tested manually on a 35.0.2 instance: CalDAV steps with three attendees, all mail captured in Mailpit. Recipients per step:

Step	35.0.2	This PR + #64635
Add attendee C to the series	nobody	C
Remove C from the series	nobody	C
Add C to one occurrence	A, B, C	C
Remove B from one occurrence	A	B
A declines one occurrence	organizer, B	organizer
A declines the first occurrence	organizer, B	organizer

This complements #64635: that PR makes sure the added or removed attendee gets a mail at all, and this one stops the mails to everyone else. With both applied, only the affected attendee is notified. It builds on #64317, which handled the series-level case.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

The analysis, fix and tests were made with the help of Claude Code (Anthropic). I verified the results myself on a 35.0.2 instance.

[Rikdekker]

/backport to stable35

[Rikdekker]

/backport to stable34