1. Generate QR code image from some unique registration ID (https://registration-webapp/qr/Stripe_Charge_ID?)
2. Email QR code image to registrant using their email address
   1. What happens if one email address has multiple Stripe_Charge_IDs associated with it? Ideally send 1 email with multiple QR codes to save spamming them/save confusion.
3. At the convention, registration committee member scans QR code from registrant using a QR code scanner
4. QR code scanner decodes QR code, launches web browser, which visits https://registration-webapp/qr/Stripe_Charge_ID
5. Handler in registration webapp func getStripeChargeID(ctx context.Context, r *http.Request, w http.ResponseWriter) does a database lookup to see if that Stripe_Charge_ID is NOT in the Scanned table. If it is, Fail, If it's not, then check its in the User table. If it is, then Succeed, if it's not then Fail

Currently gorilla/schema returns:

could not encode registration form: schema: error converting value for "Donation_Amount"

Host it all internally.

Similar but more flexible than #22

Can one person do multiple registrations e.g.: {1 x AA, 2 x ALANON, 2 x Alateen} with a combined bill?

https://stripe.com/docs/payments/checkout/server

In September, Stripe will be changing their API to support Strong Customer Authentication (SCA), so we need to update the code for the pre-reg form.

Seems straightforward.

⚠this limits me to developing on my laptop. Google Cloud Console uses go version go1.10 linux/amd64

https://medium.com/@matryer/the-http-handler-wrapper-technique-in-golang-updated-bc7fbcffa702

Required by September 2019.

Match https://eurypaa2018.com/registration/

#10,
#14,
#15

Fix Stripe payment screen's 'back button', which currently 404's.

Traditions 7 statement - better to make it a required tickbox "I am an AA
member"

Seems very easy!

https://cloud.google.com/appengine/docs/standard/go/runtime#go-1.13

Just change app.yaml field runtime like so:

runtime: go113

Blocked at the moment, awaiting further info.

1. How much do the t-shirts cost each?
2. What do we plan to do with people that have already registered and indicated Yes they want a t-shirt?
3. Sizes?
4. What will t-shirt look like?

Estimated time to complete action: unknown - I first need to know the answer to the above questions. Assuming the answer to Q2 is "Nothing", my estimate is 4 weeks.

• Add new handler for /registrations.csv or so, in app.yaml with login: required
• Restrict access so that only Registration Chair can access this

Ideally we won't be so tightly coupled with Google Appengine's Datastore.

I'd like to be able to easily swap in different databases e.g. sqlite, postgres, etc.

We are collecting/storing email/data.

Do we need to use the github.com/gorilla/sessions key rotation?

At the moment, we don't have it. Write a test to assess the impact of not having rotation of store and encryption keys, and if it's not a problem, leave it. If it is a problem we may need to add it as per the example on http://www.gorillatoolkit.org/pkg/sessions

var store = sessions.NewCookieStore(
    []byte("new-authentication-key"),
    []byte("new-encryption-key"),
    []byte("old-authentication-key"),
    []byte("old-encryption-key"),
)

https://godoc.org/github.com/gorilla/sessions#Session.AddFlash

What if someone wants a refund? We currently have no way of marking this in the DB.

Possibly a terrible idea.

See this for inspiration:

https://github.com/kainlite/whatismyip-go

Follow-on from #55

Now that #52 has been merged, I can see that there are failing unit tests:

https://travis-ci.org/github/tintinnabulate/registration-webapp/builds/706673834?utm_source=github_status&utm_medium=notification

This issue has been created to track fixing the unit tests for the online 2020 version of the code base.

At the moment, the app will create a new Customer object in Stripe even if the same email address already exists in Stripe.

This is silly, and will make checking pre-registration a pain in the future!

The fix will involve checking if the entered email address already exists in the User table. If it does, use that Customer ID for the new payment, otherwise create a new Customer.

Member_Of option 962654a#diff-783e2c958a66b9f2f8ab5865e21f786eR60

is not relevant to online 2020 donation site. Needs to be removed and replaced with a statement about Tradition 7:

AA is fully self-supporting declining outside contributions. In keeping with Tradition 7, EURYPAA can only accept donations from AA members - please only donate if you are a member of AA.

or something like that

Currently this is bodged here: dbf10ca#diff-4ed45fac7458c5e3ff6bf61665d3d263R11

For this ticket, we need to use the datastore to actually fetch the latest convention from the Convention table.

Test #24

Currently, Stripe payments Description field just says "SCANCYPAA Registration". We want to improve this, by having:

• First Name
• Email
• Tshirt?
• From (Country + City)
• Fellowship?
• Helper?
• Outreach?

So that these details can be visible from Stripe.

In a separate payment form, separate to the registration form, add the feature to donate one/two/X registration fees of EUR20.00, where X is a number specified by the donator.

ENGLISH:
"We know many love EURYPAA, but some can't make it (which sucks). If you would like to support the convention, please feel free to donate 1, 2 or more registrations for newcomers and help support the event."

SPANISH:
"Sabemos que son muchos los que les encanta EURYPAA, pero algunos no pueden asistir (qué lástima!). Si deseas apoyar la convención, puedes donar 1, 2 o más inscripciones para recién llegados y ayudar apoyar el evento".

If we can have it in Spanish as well, I guess there might be text in the option box that would need to be translated too. If so, let me know and we can translate this too.

Estimated time to complete: 3 weeks.

Add the following text underneath the existing English text "Bienvenido a EURYPAA! Para empezar, haz clic en el enlace abajo para confirmar tu dirección de correo electrónico".

Proposal

This issue proposes removing the verification flow entirely, going straight to the /register endpoint.

Rationale against change

Currently the form mails a verification link to each donator's email address so that we KNOW we have a valid email address.

• This makes it possible to issue refunds with Stripe.

Rationale in favour of change

For the Online 2020 convention, we are asking for a donation, NOT a registration fee... so they're very unlikely to request a refund.

• Much quicker to take donation.
• However - we are no longer guaranteed to be able to issue refunds because they may enter an invalid email address.

https://phraseapp.com/blog/posts/internationalization-i18n-go/

Read this: https://blog.trailofbits.com/2019/11/07/attacking-go-vr-ttps/

I suspect there are a lot of tools/techniques in here that I can use to improve the quality of my code.

Mailgun, or Mailjet.

SendGrid seem terrible.

...probably using OAuth2 Google Account and an access control list (ACL).

Use memcached for #24

• Does the form have validation ? E.g. needed fields?
• Can the databse be wiped and reused fresh again the next year? Or is the data backed up as required and the process is then restarted?
• What is the initial form field?
• Since IRE and EUR use the same codebase, why not just have one app, and have /eury/signup and /irey/signup select which registration form to load?
• Fix go lint warnings.
• Use eury email provider to send out verification email
• Use Braintree? Stripe can only receive payments in 26 countries, whereas
  Braintree can receive payments in 45 countries!
• Add registration pin map showing country/city where people have registered from (Google Maps?)
• Status Bar:
  • N users registered today, N users registered total
  • N users registered from your country
  • Today’s daily reflections reading using https://github.com/tintinnabulate/daily_readings

Will require stripping A LOT of functionality, so this is not to be merged.

Do not merge.

This is nothing to do with Issue #23

/selfsupporting that returns true / false

Compare a Convention db entry with Stripe API query

For rate-limiting, and to stop abuse.

See title

Handle when

• Donation_Amount < 1 (i.e. handle Stripe returning error code 400: parameter_invalid_integer)

• Donation_Amount > 9999999 (i.e. handle Stripe returning error code 400: amount_too_large

checkErr(err) is not just lazy, it's bad as it can bring the application down