Define schema for Users

[briri]

We need to review the wireframes related to User sign in, registration and profile editing and define the initial schema, queries and logic that the backend will need to provide.

[briri]

User

• id Int!
• role String! (options: Researcher, Admin, SuperAdmin) (default: Researcher)
• givenName String!
• surName String!
• secondarySurName String
• affiliationId String! (ref to Affiliation)
• password String! (encrypted)
• orcid String
• ssoId String (The user's SSO eppn id if applicable)
• accepted_terms Boolean! (default: false)
• last_sign_in String (Date time stamp)
• last_sign_in_via String (options: password, sso)
• reset_password_token String
• reset_password_token_ttl Int
• language String! (default: en-US)
• oauthClientId Int (ref to API access info)
• notification_comment_added Boolean! (default: true)
• notification_feedback_complete Boolean! (default: true)
• notification_plan_shared Boolean! (default: true)
• notification_template_shared Boolean! (default: true) (admin only)
• notification_plan_visibility_change Boolean! (default: true)
• locked Boolean! (default: false) (a way to lock the account after too many failed login attempts)
• active Boolean! (default: true) (a way for an admin to deactivate the user account)
• created DateTime! (default current timestamp)
• modified DateTime! (default current timestamp)

UserEmail

• userId Int!
• email String!
• primary Boolean!
• confirmed Boolean! (default: false)
• confirmation_token String
• confirmation_ttl Int
• created DateTime! (default current timestamp)

UserInvitation

• email String!
• InvitedToType String (options: Template, Plan)
• InvitedToId Int
• created DateTime! (default current timestamp)

Queries

• Get the current user me(): Promise<User>
• Search for users (admin only) users(): Promise<User[]>
• Get a specific user by Id userById(userId: number): Promise<User>
• Get a specific user by Email userByEmail(email: string): Promise<User>
• Get a user's emails userEmails(userId: number): Promise<UserEmail[]>

Mutations

Sign in, Register, password reset, email confirmation and invitiation acceptance methods are handled outside of GraphQL by specific endpoints which interact with the Schema and dataSources and create access tokens.

• Invite a user to create an account inviteUser(email: string, inviteType: string, inviteId: number): Promise<boolean> (InviteType can be 'Plan' or 'Template' and InviteId is the id for the thing they are being invited to collaborate on)
• Update a specific user updateUser(userId: number, givenName: string, surName: string, affiliationId: string, newAffiliation: string, orcid: string, language: string, [all the notification_ types): boolean: Promise<User> (errors included) (newAffiliation is used to pass the name along when the user selects 'My affiliation is not in the list')
• Change the password updatePassword(oldPassword: string, newPassword: string): Promise<boolean>
• Add an email for a user addUserEmail(userId: number, email: string, isPrimary: string = false): Promise<boolean>
• Remove an email from a user removeUserEmail(userId: number, email: string): Promise<boolean>
• Mark an email as primary designatePrimaryUserEmail(userId: number, email: string): Promise<boolean>
• Lock a user account lockUser(userId: number): Promise<boolean>
• Unlock a user account unlockUser(userId: number): Promise<boolean>
• Deactivate a user account deactivateUser(userId: number): Promise<boolean>
• Activate a user account activateUser(userId: number): Promise<boolean>
• Anonymize a user account anonymizeUser(userId: number): Promise<User>
• Merge user accounts mergeUsers(mergeFromId: number, mergeToId: number): Promise<User>

The newAffiliation field should also be added to the register endpoint so that user's can provide this when creating a new account.

Other Logic

• If a user creates their account via SSO the ssoId attribute will be populated.
• When a user changes their affiliation
  • If they had an existing ssoId attribute, remove it
  • Set their role to Researcher (unless the user is a SuperAdmin)
  • If the new Affiliation has SSO allow them to authenticate (similar to the functionality on the registration page)
• Password change should send out an email with messaging like "If you made this change you can ignore this email. Otherwise contact us"
• When a new user registration occurs, we should check for an existing record with an outstanding invitation first.

Questions

• Should changing the primary email address send out an email to the original address? With messaging like "If you made this change you can ignore this email. Otherwise contact us"
• What behavior should the system take if an email is unconfirmed?
• What thresholds should we set for locking a user's account? 5 unsuccessful logins?

[jupiter007]

@briri, Just a few comments:

User:

• Will we need any additional name fields (e.g., some countries have two last name fields)

UserEmail:

• Does this need to include the userId field in order to associate the email with the user?

Queries:

• Would it be possible to make just one request to GraphQL server to get the data to populate the Profile page?

Mutations:

• For the updateUser mutation, would we need another field for the scenario where we have no affiliation id yet when the user selects the checkbox "I cannot find my institution in the list".
• For addUserEmail, the wireframe does not have a way for users to specify whether that new email is primary, so do we need to include the isPrimary field in the mutation?
• I believe we will need an updateEmail mutation for when a user wants to change an email to be the primary email.

[briri]

Good catch on the missing 'userId' in the Email table definition. I also added a 'newAffiliation' field to the updateUser mutation as a way to pass the name when they click 'not in the list'. I made a note to add that to the register endpoint as well.

Yes, we can probably get a single GraphQL query to fetch all of the data for the profile page.

I thought the wireframe had a link that said 'primary' next to the alternate emails as a way to change the designation. If not, we should update the wireframes to allow for the user to change it. I added a designatePrimaryUserEmail mutation.

I'm not sure on adding an additional field for a secondary surname. I'm trying to think through the logic of how they get used and displayed in different situations.

• displaying in the first - last format: "Jane Doe Smith"
• displaying in the last - first format "Doe Smith, Jane"
• How do hyphenated names work?
• How do names with prepositions like 'van' work?
• There are probably other scenarios I'm missing

Would it work to have a surname field that is large enough to accommodate multiple names?

[jupiter007]

Thanks @briri. The existing alternate emails do have an option to update those emails to "primary", but when a user adds a new email address, there is currently no option in the wireframe to specify that is is primary. I was assuming that the "addUserEmail" mutation would be for that field, and not updating the existing emails.

[jupiter007]

Lets run the name fields by Becky today to see if she has any ideas for how to handle that. Maybe we don't need it, but I checked our visitors on Matomo yesterday, and the second country listed was Brazil:

[jupiter007]

Would it be possible to detect the user's country and show an extra last name field?

[briri]

🤷‍♂ I guess. Is that something easily detected on the frontend? I added a secondarySurName field to the definition

[andrewebdev]

The way other apps and sites to this is to just have two fields, one for the first name, and a second for any number of lastname(s) family names, middle names etc. This kind of stuff gets hard when you try to accommodate every locale, so I would advocate the simplest approach.