As an Organiser, I want to register new members without an email address

[ineffyble]

For new features:

Background:

As an organiser, I often receive incomplete details about new members - this may mean that I have the mobile phone number of a new member, but no email address. It might also mean that this is a low-tech member, who does not use email.

I want to be able to store these members in Rabble Rouser, and ideally add more contact details for them when I gather them.

User research:

As an administrator of a system similar in intent to Rabble Rouser for several years, I've seen the issues that enforcing an email on contact creation can cause. Often, our users would put a dummy email address, or their own email address, to get around this issue.

Technical notes:

I'd suggest not requiring an email address at the controller level or in the admin interface - instead, the email address field can be (and already is) mandatory on user-facing forms, etc.

[camjackson]

That sounds like a reasonable use case. Actually right now there's no way for an admin to create a member through the admin console, only through the member signup page.

So maybe the existing code used for signing up members stays the same, but we should add an admin-specific way to create members, which can allow a bit more freedom? What do you think?

This is tangentially related to #130, as that task will more explicitly differentiate things that were triggered by members vs. admins.

[ineffyble]

That makes sense to me. It came up because I was thinking about making a Twilio integration, where supporters could SMS a number to sign up, as a good starter project.

However based on my glance of the code, I think there’s validation that requires an email from the backend, regardless of event source, so I wouldn’t be able to make my integration.

[camjackson]

Ah interesting, Twilio integration would be cool! And actually, if we're talking about a new integration, then the existing validations might not be a problem.

I could be wrong but my understanding is this: You're right that when a request comes into the core backend to register or edit member, email is a compulsory field. And so it will refuse the request, meaning it doesn't put any event onto the event stream.

But when it comes to reading events off the stream that were put there by another service, the stream is considered a trusted source of data, like reading from a database, so the data is not re-validated.

What that means is that if you want to do twilio integration, you could create a new microservice for it, and that service can just receive SMS data from twilio, and put register-member events onto the stream without specifying an email address. Other services will receive those events and will consider the member registered!

Of course, we would want to double check that existing code is able to handle email-less members. I suspect that the mailer and group-mailer services currently assume that an email will already be present, so one or both of them would probably need to be updated to skip over members that we're not able to email. But that's not a big deal.