[feature-request] calendar appointments support

Bug #1191911 reported by Alexander Adolf
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Triaged
Wishlist
Unassigned

Bug Description

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.

Revision history for this message
Barry Warsaw (barry) wrote :

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.

Changed in mailman:
status: New → Triaged
importance: Undecided → Wishlist
tags: added: mailman3
Revision history for this message
Alexander Adolf (c-alpha) wrote :

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?

Revision history for this message
Abhilash Raj (raj-abhilash1) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.