Phase 1: Membership (implement sign-up on universal login)

[melanierogan]

What is it and who's it for?

We currently have a pre-registration form on https://catalogue.wellcomelibrary.org/selfreg which captures limited information on users applying for library membership. This was designed to enable users to pre-register before coming to the building and allow them to access functionality such as Requesting in advance to being a full library member.

We would like to migrate this sign up process to wellcomecollection.org to sit alongside the new login/requesting flows for existing members and to minimise the disruption and change in experience between signing up/registering and logging in/requesting.

An example of how this could work in the background is here.

This could incorporate this ticket, but in the design options that show the expanded membership copy. #7812

It is likely membership will be formed of multiple phases:

• Phase 1 will migrate the existing form
• Phase 2 will look at how to capture additional data fields (e.g. address)
• Phase 3 will tackle how to align the offline experience.

User story

As a non-library member
I want to create an account
So that I can request materials to see on my library visit

We need to implement the link/flow to sign-up on the universal login page. This will start with just taking the email address and password, before progressing to a full form represented by the original ticket #7808

This ticket represents the work needed to implement the process of sign up. It will involve putting a post-login action in place where we redirect to the full sign up form after we take the initial email and password.

Measurement

• Visits to page

All Phase 1 stories

#7808 - Replicate existing form
#7809 - Confirmation of application
#7811 - Verification of email
#7812 - Update sign in
#7814 - Update editorial content
#7815 - Reporting
#7848 - Temporary member messaging - account

[melanierogan]

Slight side step that blocks David and l, I need to make a jwt handler to encode the formData (in weco identity app) to send it back to the auth0 action.

[melanierogan]

Once the above PR (feat:jwt hanlders to recode and encode formData for auth0 action) is merged, it can be used in David's form on #7902

[melanierogan]

David integrated 7905 into his membership form PR 7902 🎉 - so i've closed 7905

[melanierogan]

I have requested an api key for the test sierra account so that I can test making POST requests to Sierra to create patrons. We could use this in our testing process. I found mention of the sierra test account on slack https://wellcome.slack.com/archives/C0198JT4GTG/p1602596552059000
https://wellcome.slack.com/archives/C0198JT4GTG/p1602595866053000

[melanierogan]

Liz from Library Support Services has opened a ticket with D&T as there’s a problem with setting up an API key in the Sierra test environment as the process is reliant on email verification and there's issue with this involving the mail server that requires D&T to help.

TODO: Once we have a key/access document this on our repos so that we know how to obtain keys in future and any details around the use cases for this sierra test account so that knowledge is not lost.

[melanierogan]

There's been a delay in getting things sorted for the Sierra Test account, I've opted to test in production and based on that I've opened a PR to add createPatron method to sierra-http-client on Identity. This will link up with David's UI work, and ultimately the PR which adds the Identity API endpoint

[melanierogan]

It is worth noting that at this point, due to limitations of redirecting to auth0 action directly from the submission of the full form in weco identity, we are now creating an endpoint /registration in the Identity API to add firstname and Surname to an auth0 user.

[melanierogan]

We'll need to slightly change what the auth0 action does as we are adding the formData (firstname, lastname) to auth0 using the endpoint mentioned above.

• user starts registrations, fills out email and password
• auth0 action redirects to full registration form
• formData posts to new identity endpoint (/register updateUserAfterRegistration)
• endpoint makes use of createPatron sierra-http-client method to create patron in sierra
• we send user to auth0 '/continue' endpoint with state to complete the redirect process

I'll create a ticket to more specifically address this change to the action.

[melanierogan]

The user flow is now as follows for membership sign up on weco. This updates the previous flow mentioned in the comment on 10th May:

1. user starts registration going to library sign up
2. user fills out email and password
3. create script on auth0 creates a patron with this email and pin, then assigns them a password based on their barcode
4. auth0 action redirects to full registration form with email address
5. user fills out firstname, lastname and accepts terms
6. form PUTs to /registration in Identity API with firstname and lastname
7. Identity API, /registration updateUserAfterRegistration - in this function, updateUser will update auth0 user with names and then updatePatron will update Sierra
8. on successful put and running of updateUserAfterRegistration in Identity API, the user will be sent to /continue with state and jwt token and the onContinuePostLogin part of the action runs
9. At the moment onContinuePostLogin will set appMetadata to show the user has accepted terms, and will send the users then to a success page on Identity weco frontend

[melanierogan]

David and I got stuck at point 6 above as Identity API was not authorizing a PUT to change user data. This meant we could not validate that the rest of the flow would work. It is at this point that Alex stepped in to work on authorizing the /registration endpoint wellcomecollection/identity#342 - there are further more in-depth explanations available on slack, and in the Identity API PR. A good explanation is also here wellcomecollection/identity#341

[melanierogan]

David has put a toggle and things in place to keep 'sign up' hidden in prod auth0 and weco production. This is so we could safely test the user flow.

[melanierogan]

Tidying up any possible questions for later. We were hoping to use test sierra to make testing a little easier.

I have requested an api key for the test sierra account so that I can test making POST requests to Sierra to create patrons. We could use this in our testing process. I found mention of the sierra test account on slack https://wellcome.slack.com/archives/C0198JT4GTG/p1602596552059000 https://wellcome.slack.com/archives/C0198JT4GTG/p1602595866053000

I chased this again and got not reply as of yet. Our networks team needed to do something to enable a mail server for test sierra, we need a mail server to assign api keys

[melanierogan]

Please also see #7812 - update sign in and #7808 create registration form

[pollecuttn]

@melanierogan can I chase this whilst you're away? If you have a D&T ticket number I can pick it up.

[alexwlchan]

We've implemented sign-up for universal login! Well, kinda – the flow works in staging, but there's a bunch of rough edges we'll need to fix before it goes live.

• Make sure we're happy with the story around CloudFront server access logs, especially PII in JWTs
• Review the copy on the pages, in particular "enter your name and password" and "success"
• Double-check we're putting names in Sierra correctly; I think we're missing some punctuation
• Document the sign-up process
• Scrub PII from the nginx logs (Remove PII from the nginx logs in the identity web app #8121)