search

Brixel / HaSpMan

0 stars 0 forks source link

As an admin/board member, I want an easy method to contact active members #95

Closed vyruz1986 closed 1 year ago

vyruz1986 commented 2 years ago

Concrete use case I have right now is for sending out invitations to our yearly all members meeting, but the scope of this issue should be broader than that. There are several occasions in which board members need to contact all active members (General purpose communications, invitations, questionnaires, ...). HaSpMan should offer an easy way to accommodate this.

I have 2 general ideas in my head, and would like to gather some feedback about them before deciding on which to implement:

Generic email functionality from the web UI

The HaSpMan web UI could offer a component where free HTML or plain text could be entered and then sent as an email to all active members. For official communications which need an audit trial, the boards email address could be put in (b)cc of the email. This would offer the best user experience in my opinion, since everything could be done from the browser with no extra actions needed elsewhere. Added bonus: No risk of leaking private user data (email addresses) since the code would enforce that either individual emails are sent, or all email addresses are put into the bcc field. Just an idea, but this functionality could be extended in the future to also offer communication through e.g. a post into a slack #members channel

Ability to copy email addresses of active members to clipboard

Another options would be a way to easily copy all email addresses of active members to the clipboard, separated with the ; (semicolon) character so it can easily be pasted into most email clients. A board member would then proceed to use whatever email client is used to create and send the email to the members. There's a risk of human error in which email addresses are pasted into the to: field, making all email addresses of members visible to each member, and thus leaking personal data. Also, a user might forget to send the email on behalf of the board, making it not show up in the board's sent emails, removing the guarantee of an audit trail of such communication. This would be the easier solution, and arguably a more flexible one, although being less user friendly and more error prone.

Possibly related to #90 (depending on the outcome of the selected choice)

BerendWouters commented 2 years ago

Another solution, based on the last one: Use the mailto: a-attribute, you'd reduce the risk of human error. It doesn't mitigate the privacy related issues, nor does it remove the risk of sending from the wrong person, or not using a defined template.

A few thoughts on the automated process too:

vyruz1986 commented 2 years ago

Another solution, based on the last one: Use the mailto: a-attribute, you'd reduce the risk of human error. It doesn't mitigate the privacy related issues, nor does it remove the risk of sending from the wrong person, or not using a defined template.

I somewhat like the idea, especially since the mailto: syntax seems to support cc/bcc as well as some basic subject and body templating: https://stackoverflow.com/a/13384884/1177847 I say somewhat, since it alleviates the main issue I have with the automated process, which is a dependency on some 3rd party service like SendGrid. For us (Brixel) specifically, I don't think this would be a user friendly solution, since, to my knowledge, none of the board members use their default email client (which is what mailto: would trigger to start) for Brixel-related email.

A few thoughts on the automated process too:

  • The sender should be a valid and trusted e-mail address known by the members

Agree, but that is infrastructure setup and does not need to be taken care of by the codebase in this repository.

  • We'd be able to allow templating/styling the e-mails
  • We'd be depending on an external provider (e.g. SendGrid). This is just a thought, not some risk assesment.

The automated solution I suggested was to allow free HTML/plain text to be entered in a web component, which would then make up the body of the email (and of course add a plaintext field for subject as well). So no templating would be needed as such. For future issues (e.g. automated membership expired emails) it would make sense, but I don't consider those cases in scope of this issue, and how templating is implement can be discussed if and when we decide to implement it.

Leaving templating aside for now, we could send emails using a regular SMTP connection. Which I feel more comfortable with implementing in HaSpMan from a community perspective. If more hackerspaces start using this project, we should not implement a hard dependency on a commercial service, but rather an open source technology like SMTP. (As a side-note, I also know that new SendGrid accounts can't be purchased through the azure sponsorship anymore, and even though we do have a subscription paid through the sponsorship, how long will it keep working?)

BerendWouters commented 2 years ago

In short:

I would prefer the automated flow, because - as you mentioned - it's just infrastructure that needs to be configured.

Regarding the SMTP provider: it's just configuration, so it shouldn't matter.

BerendWouters commented 1 year ago

I'm still a fan of the quick solution of the mailto option, because this introduces a lot of flexibility. However, I don't think implementing the component to send an e-mail using SMTP would be too difficult either, especially if we just create a component that does the following:

vyruz1986 commented 1 year ago

Question @BerendWouters @Kenny-Lacroix Is it OK if the sender address of these mails is configured globally at the application level (e.g. bestuur@..) for now?

Kenny-Lacroix commented 1 year ago

Being that it is a general mail from us it is ok for me to use the bestuur mailbox