Closed briri closed 3 weeks ago
me(): Promise<User>
users(): Promise<User[]>
userById(userId: number): Promise<User>
userByEmail(email: string): Promise<User>
userEmails(userId: number): Promise<UserEmail[]>
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.
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)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')updatePassword(oldPassword: string, newPassword: string): Promise<boolean>
addUserEmail(userId: number, email: string, isPrimary: string = false): Promise<boolean>
removeUserEmail(userId: number, email: string): Promise<boolean>
designatePrimaryUserEmail(userId: number, email: string): Promise<boolean>
lockUser(userId: number): Promise<boolean>
unlockUser(userId: number): Promise<boolean>
deactivateUser(userId: number): Promise<boolean>
activateUser(userId: number): Promise<boolean>
anonymizeUser(userId: number): Promise<User>
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.
ssoId
attribute will be populated. ssoId
attribute, remove itResearcher
(unless the user is a SuperAdmin)@briri, Just a few comments:
User:
UserEmail:
Queries:
Mutations:
isPrimary
field in the mutation?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.
Would it work to have a surname field that is large enough to accommodate multiple names?
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.
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:
Would it be possible to detect the user's country and show an extra last name field?
🤷♂ I guess. Is that something easily detected on the frontend? I added a secondarySurName
field to the definition
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.
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.