On v0.16.23, when an attendee declines a meeting via JMAP and sets participationComment, the comment is not transmitted to the organizer. Internal scheduling between two local accounts, JMAP only.
Expected Behavior
The iMIP REPLY carries the comment as COMMENT (RFC 5546 allows COMMENT in a REPLY), the organizer’s copy of the event gets participationComment for that attendee (RFC 8984: “a note from the participant to explain their participation status”), and the generated email shows the text.
Actual Behavior
The organizer receives the REPLY (“Declined: …”), but its text/calendar part has no COMMENT property and the email body does not contain the text.
In the organizer’s copy the attendee becomes “declined”, but participationComment is missing.
The comment only remains in the attendee’s own copy.
Interestingly, when the organizer sets participationComment on their own participant and updates the event, it is sent as JSPROP;JSPTR=participants/o/participationComment:“…”, so the property is known but not mapped to COMMENT.
Reproduction Steps
User A (anna@) creates an event with user B (ben@) as attendee, CalendarEvent/set with sendSchedulingMessages: true.
User B updates their copy:
CalendarEvent/set, sendSchedulingMessages: true
update: { “”: {
“participants/a1/participationStatus”: “declined”,
“participants/a1/participationComment”: “Out of office until 12 Oct, please contact Clara.” } }
Check A’s inbox (REPLY email and its text/calendar part) and A’s event (CalendarEvent/get, participants).
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
Own JMAP client (web/desktop), no CalDAV. Use case: “decline all meetings during an out-of-office period” with a short message; for now we send the message as a separate email. Tested on a test instance; written with the help of an AI assistant.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
I looked at the scheduling code (crates/groupware/src/scheduling) and can confirm this is a gap in the current implementation, not something you’re missing in your JMAP calls.
When an attendee’s iTIP REPLY is built (attendee_handle_update / attendee_decline in scheduling/attendee.rs), the internal Attendee snapshot struct used to construct the reply only tracks fields like part_stat, role, delegated_from/to, rsvp, force_send, etc. There is no comment field carried through this struct, and the REPLY-building path doesn’t pull COMMENT out of the updated participant at all. So participationComment set via CalendarEvent/set is stored in your own copy (since it’s just a JSCalendar property on that copy) but is never read when the outgoing REPLY iCalendar is assembled, which is why the organizer never sees a COMMENT: line in the iMIP/text-calendar part and their copy of the event never gets the participant’s comment applied.
This matches your reproduction: the property is recognized well enough to round-trip via JSPROP;JSPTR=participants/.../participationComment when you set it on your own participant entry, but nothing in the scheduling/iTIP layer maps participationComment to the iCalendar COMMENT property (in either direction: outbound REPLY generation, or inbound REPLY ingestion into the organizer’s copy).
This is a genuine bug in the current scheduling implementation rather than a documented limitation. A human or staff member will need to follow up on getting participationComment wired into the REPLY generation and inbound-REPLY processing.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
participationComment has no iCalendar mapping in the JSCalendar to iCalendar conversion draft, which is why it goes out as a JSPROP, and JSCalendarbis now lists it as reserved until iTIP is updated to carry it. Our attendee REPLY includes the attendee’s own status plus a handful of core event fields, so nothing turns the comment into a COMMENT property. The 1.0 branch behaves the same.
The receiving end is already there. A REPLY that carries a COMMENT shows up as the comment on the organizer’s CalendarEventNotification, and the HTTP RSVP page lets an attendee add one (Scheduling | Stalwart).