feat: change email updating workflow [DHIS2-18493]

[tomzemp]

Background / Notes

See ticket description.

This PR adds a modal for changing a user email (/ removing one). And does some light refactoring related to email verification button / email verification warning (e.g. moving them, clearing up some language if there is no email).

Now there's a row of buttons that let you work with your email:

(see ticket for detailed requirements)

Known issues

Unfortunately, posting ''/undefined/null to api/me (e.g. payload of {email: null}) is not allowed / does not remove value.
Additionally, api/me does not appear to support PATCH, so cannot use a remove operation.

I'm just interpreting anything an email that evaluates to email.trim() === '' as a non existent email, but there's room for improvement here and we would need a backend change.

See also point below in testing section below about lack of rollback on failure.

Testing

There's no automated testing in this app, and I don't want to add it here 🫤.
I've done a number of manual tests changing/removing emails to make sure that things work as expected.

One weak point here is that the backend currently accepts pretty much anything you throw at it for an email, which makes it hard to test for what happens when/if the email fails to update. A general problem with the user app is that the app does not rollback the inputs when they fail to post. For consistency (🤨) I've not done anything about that in this PR, so if an email is rejected by the backend, it still updates the input field. You'd need to just try again if that happens, but that's how this app generally works 🙃.

I did not test in conjunction with verifying email as that was part of another ticket, so we will probably want to test the entire workflow manually at some point when all the user profile changes are done.

[dhis2-bot]

🚀 Deployed on https://pr-1470--dhis2-user-profile.netlify.app

[tomzemp]

this is just updating the validator to be consistent with what we have in the email modal

[tomzemp]

initially, we'd done valueStore.setState({...valueStore.state, email}) (or similar), but then this did not actually set the new email state 🤔 (I think there's some nuances to component setState that I no longer know)

[tomzemp]

if user updates the email, we assume by default that it is no longer verified

[Birkbjo]

Kind of minor. But I think I would've preferred this (The modal with the contents) to be it's own component. Not just for the sake of extracting this out - but it would also mean that we don't have to manually reset the state of this modal during closeModal, if we were to conditionally render it.
I haven't done a full analysis of what it would look like, or if would be annoying to do - just an observation.

[tomzemp]

I think that's fair. We just started writing it this way and then it was easier to continue on with what we had and do a manual reset of the component state. But it became a bit longer than what we had originally, so seems fair to also break it up into a separate component. I've updated to put it in its own component but within the EmailField.js file as I think it's functionally easier to read the code when this is in one file.

[Birkbjo]

I'm a bit confused about the naming of this component (and file). When I read "ModalField" I would expect this to be a generic field that somehow opens a modal. I would expect this to be called EmailField.

[tomzemp]

I've updated to use EmailField, and to make some of the related functions/props correspond to this update

[Birkbjo]

I don't think it's necessary to both pass down onUpdate and an setUserEmail property?

Why can't we just override onUpdate - and omit setUserEmail? And then set emailUpdated within that override?
eg:

            onUpdate: (
               field, // Imo we should remove this so the component doesn't have to call this with the fieldName
                value
            ) => {
                onUpdate('email', value)
                onUpdate('emailUpdated', true)

            },

[tomzemp]

Yeah. I should have cleaned that up. We had implemented the state update before we realized we needed to change the onUpdate to get the update to fire.

[Birkbjo]

Suggested change

	props: {
	onUpdate,
	userEmail: valueStore.state['email'] || '',
	userEmailVerified: d2?.currentUser?.emailVerified,
	setUserEmail: (email) => {
	valueStore.state['email'] = email
	valueStore.state['emailUpdated'] = true
	valueStore.setState(valueStore.state)
	},
	props: {
	onUpdate: (
	value
	) => {
	onUpdate('email', value)
	onUpdate('emailUpdated', true)
	},
	userEmail: valueStore.state['email'] || '',
	userEmailVerified: d2?.currentUser?.emailVerified,