[feature-request] calendar appointments support

[Alexander Adolf]

This is an feature proposal/enhancement request.

I am running standardisation groups, and often schedule conference calls, Web meetings, etc. To invite the working group members, I add a mailman list as an invitee to the calendar appointment on my calendar. That way, everybody on the list gets and invitation, and also update emails are delivered when I drag the appointment around on my calendar. Everyone stays in sync. Nice. I don't care who of the list members actually accepts the appointment, because the dates are fixed by other means beforehand (e.g. doodle.com).

But of course I never see any accept/decline responses. This causes my calendaring app to consider the appointments as "unconfirmed" since none of the invitees has confirmed their participation. I hence have to manually edit such appointments in order to make them show up as "confirmed, busy".

To alleviate this. it would be awesome if mailman could optionally be configured to automatically respond to the sender of an email containing a calendar appointment, and accept the invitation. Maybe this could fit in the content filtering section?

That way, mailman operated lists would confirm their attendance on behalf of their members, and the calendar appointment on the organiser's calendar would have the proper status.

[Barry Warsaw (barry)]

This can probably be done as a plugin to the commands processor. I.e. a new command that would be something like 'accept-invite'. Probably would be relatively easy to implement in Mailman 3.

[Alexander Adolf (c-alpha)]

Hm, the commands processor is only invoked for mails that go to the -requests address? So I should invite both, the normal list address, and the -requests address? Also, my calendar application does not allow me to edit the message before sending (in fact the mail is sent by a remote calendar server I have no control over), so putting in the new 'accept-invite' command would seem close to impossible in my case.

To me it seems that a new archiver would look more promising? That would be presented all messages to the regular list address, and I don't need to remember inviting the -requests address. I presume I should be looking at /src/mailman/archiving? From what I saw it seemed that all archivers are invoked in turn on each message?

[Abhilash Raj (raj-abhilash1)]

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/52