makesaltlake / heimdall Goto Github PK

Per https://makesaltlake.slack.com/archives/CGDLBCCCT/p1610320781275700

We need a way to allow developers to upload new firmware for the badge readers and writers and allow them to download it over-the-air and update themselves whenever it's changed.

Current thinking is to have that baked into Heimdall itself, probably in the form of something like:

• A new model, DeviceFirmware, that has an Active Storage attachment for a binary firmware blob
• Some way of flagging which uploaded firmware should be the current one that gets rolled out to all devices
• Some way of having different sets of firmware for badge readers and badge writers (and other devices in the future)

Open questions:

• Is there any sort of CI pipeline attached to this or is the expectation that a developer builds the firmware on their local computer and uploads it manually to Heimdall?
  • How feasible would a CI pipeline be with Espressif's SDK's requirements?
• How best to support anyone outside of Make Salt Lake who wants to deploy a Heimdall instance? It wouldn't be any good if they had to install Espressif's SDK themselves, build the firmware, and upload it to their own instance. (If CI is feasible, perhaps firmware releases could be built automatically on repo push and Heimdall could pull them in from GitHub and expose them in the UI, with the ability to also upload firmware blobs by hand in case a developer wants to test out some changes they've made locally but haven't pushed.)

The only thing keeping MSL's WordPress instance (which costs a pretty penny to run, more than Heimdall itself) around now that the website has been moved to makesaltlake/public_website is that it handles member signup and membership changes (like changing plans and adding card info). That's a lot of money to spend just for that.

I had a look around some time ago at other self-service recurring subscription signup and management portals and all of the options I found were even more expensive at our scale (in no small part because they tend to bill on revenue percentage) or missing features we need (like a way to log in and switch between plans).

So, given all of that and given that a lot of neat possibilities open up if members are able to sign into Heimdall (like certifiers being able to enter certifications themselves instead of Jen having to enter them manually, members being able to purchase gift cards, and Heimdall sending emails to all members certified in a given area when an access code changes), I'd like to try writing a membership signup and management system into Heimdall.

The way I'm thinking that would go down is as follows:

• Write a prototype membership signup form. It should accept all the same fields our current one does and should embed a Stripe credit card field to accept payment. It should create Stripe subscriptions but not do any other functionally useful stuff. It should also use a hardcoded plan.
• Enhance it to use multiple plans - probably hardcode them at first, but perhaps add a DB model where plans can be configured. Whether or not there should be a page to pick between plans is an open question; it may be fine to have the plan chooser live in makesaltlake/public_website and link to a page specific to each plan.
• Enhance it to support coupons. This will require investigating whether Stripe's built-in coupon support is sufficient for our needs (it wasn't for MemberPress, the WordPress plugin we currently use to manage memberships, so they implemented their own coupon system that creates plans from scratch for each new signup; it's possible we may have to do the same).
• See if anything else is missing from the existing membership signup system feature wise
• Ask MSL staff how they want the "where did you hear about us" field to work and if there's any other data they'd want to collect from new members going forward
• Wire up email sending to Heimdall in production using something like Sendgrid, SparkPost, or Mailgun. Now that SparkPost no longer offers their 10,000 emails/month free plan, MailGun's flex plan ($0.80/1,000 emails sent) is probably the cheapest for us considering our low volume (which I imagine will be one email receipt per month to each member, and possibly not even that since Stripe also sends receipts on our behalf).
• Configure the signup form to create users in Heindall on signup and send an email with a link to set up the user's account when created. It should only send that email when a user signs up through the form, not when a user is manually created or automatically created by signing up through the old form. There should, however, be a way to send it manually from the admin console, and it would be ideal if an already-existing user who signed up again through the form (perhaps because they cancelled a while back and are signing up again) got the email as well if they hadn't yet set a password.
• Build a page where an authenticated user can update their Stripe card info on file. It will need to do something useful if they don't have a corresponding Stripe customer yet. It will also need to do something useful if they have multiple Customers in Stripe (and we should see if and how many of such users exist).
• Build a page where an authenticated user can change their plan. We'll need to think through whether they should be able to apply a coupon when they do that (and how to limit most coupons from being used more than once by the same user).
• Build some sort of way for existing members to sign up for a Heimdall account and manage their membership there
• Do a pass through to see if there are any other member management features we need for round 1 that are missing and implement them.
• Try having a few new members we talk to on tours sign up through the new system and see how it goes for them. Make any changes needed based on their feedback.
• (Possibly consider A/B testing the new signup form vs the old one to make sure there isn't a notable decrease in conversions, and make any changes needed to address that if there is)
• Roll out the new system to all new member signups
• Put a note on the old WordPress system directing users to the new system (but leave the old one running for a bit)
• Announce the new system to the membership somewhere
• After some time, sunset the old system and possibly consider moving/aliasing Heimdall to membership.makesaltlake.org

This was an earlier ask from Rio's era; it's possible Jen and Michael may not want it. We should talk to them about the pros and cons of doing this.

Add a system to allow certifiers to:

• Create certification issuances for users
• View certification issuances for certifications they certify
• Revoke certification issuances for certifications they certify
• Not view any other data in the system, including information about whether a user is paid up

There may need to be some way for a certifier to create users in the system, or alternatively we could just expect them to enter tentative names for unknown users and someone else can do the reconciliation.

This is per a request from Jen, though I can't find the source at the moment - we would like to be able to view users who have a particular discount applied at the current moment.

This may be tricker than it sounds, because MemberPress creates oneoff Stripe plans for each user and doesn't appear to expose to Stripe which MemberPress-side discount was applied when the user signed up. We may need to talk to MemberPress's API to do that...

...and, given #8, it's debatable whether we should do that now or whether we should wait a bit to see if we're able to do #8 and import all subscriptions, including MemberPress discount data, into Heimdall and save ourselves some trouble.

That will allow the synchrotron reporter to report instantly without having to iterate through all Stripe subscriptions via Stripe's API each time it's about to post.

It will also make #10 easier to implement since we can detect if the subscription in question already has unpaid set to true - in which case there's no need to re-notify about a failed payment.

The Synchrotron notification bot posts "failed payment" messages to Slack every time a payment retry fails. Jen tells me that's noise, and having one single "failed payment" message when a member's payment starts failing and another "payment is no longer failing" message when their payment issues have been resolved would be sufficient.

Change the bot to do that.