Steps to reproduce
- Nextcloud 33.0.2, Mail 5.10, cron working. "Automatically create
tentative appointments" enabled for the account
(oc_mail_accounts.imip_create = 1).
- Receive an external iMIP invitation (METHOD:REQUEST) and let
IMipMessageJob process it. The event is created in the calendar and
rendered as tentative (server writes STATUS:TENTATIVE via
absentCreateStatus; attendee PARTSTAT remains NEEDS-ACTION). Do not
respond to the invitation.
- Have the organizer modify the event (e.g. change the time), which
sends an update: a new METHOD:REQUEST with the same UID and a bumped
SEQUENCE.
- Let IMipMessageJob process the update.
Expected behavior
An auto-created event that the user has not yet responded to should
remain visibly tentative after organizer updates (updated details, new
time, but still rendered as tentative). This matches the Outlook
behavior that motivated the feature in #7750.
Actual behavior
The update takes the existing-UID branch in
OC\Calendar\Manager::handleIMip() (lib/private/Calendar/Manager.php,
v33.0.2): the organizer's event data is applied via handleIMipMessage()
WITHOUT reapplying absentCreateStatus. The organizer's copy carries
STATUS:CONFIRMED, which overwrites the locally stamped
STATUS:TENTATIVE. Because the attendee's PARTSTAT is still
NEEDS-ACTION, the event silently flips from rendering as "tentative" to
"did not respond" in the Calendar app — losing exactly the visual cue
the feature exists to provide, without any user action.
Suggested fix: in the existing-UID/update path, when the invitation
was auto-created and the user's PARTSTAT is still NEEDS-ACTION,
reapply the tentative status (or preserve the local STATUS property)
so unanswered auto-created events stay tentative through updates.
Related: #7750, PR #12144, server PR #56924.
Companion issues from the same investigation: nextcloud/server#63333,
#13503.
Mail app version
5.10
Nextcloud version
33.0.2
Mailserver or service
No response
Operating system
No response
PHP engine version
None
Nextcloud memory caching
No response
Web server
None
Database
None
Additional info
No response
Steps to reproduce
tentative appointments" enabled for the account
(oc_mail_accounts.imip_create = 1).
IMipMessageJob process it. The event is created in the calendar and
rendered as tentative (server writes STATUS:TENTATIVE via
absentCreateStatus; attendee PARTSTAT remains NEEDS-ACTION). Do not
respond to the invitation.
sends an update: a new METHOD:REQUEST with the same UID and a bumped
SEQUENCE.
Expected behavior
An auto-created event that the user has not yet responded to should
remain visibly tentative after organizer updates (updated details, new
time, but still rendered as tentative). This matches the Outlook
behavior that motivated the feature in #7750.
Actual behavior
The update takes the existing-UID branch in
OC\Calendar\Manager::handleIMip() (lib/private/Calendar/Manager.php,
v33.0.2): the organizer's event data is applied via handleIMipMessage()
WITHOUT reapplying absentCreateStatus. The organizer's copy carries
STATUS:CONFIRMED, which overwrites the locally stamped
STATUS:TENTATIVE. Because the attendee's PARTSTAT is still
NEEDS-ACTION, the event silently flips from rendering as "tentative" to
"did not respond" in the Calendar app — losing exactly the visual cue
the feature exists to provide, without any user action.
Suggested fix: in the existing-UID/update path, when the invitation
was auto-created and the user's PARTSTAT is still NEEDS-ACTION,
reapply the tentative status (or preserve the local STATUS property)
so unanswered auto-created events stay tentative through updates.
Related: #7750, PR #12144, server PR #56924.
Companion issues from the same investigation: nextcloud/server#63333,
#13503.
Mail app version
5.10
Nextcloud version
33.0.2
Mailserver or service
No response
Operating system
No response
PHP engine version
None
Nextcloud memory caching
No response
Web server
None
Database
None
Additional info
No response