-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Make identity reset consistent with EX #29701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
5ca414f
to
fec5e88
Compare
0edccfe
to
dab78ad
Compare
dab78ad
to
8f0073e
Compare
8f0073e
to
f3035e1
Compare
f3035e1
to
94c7056
Compare
94c7056
to
4fdc53e
Compare
4fdc53e
to
fff5732
Compare
fff5732
to
eccb05c
Compare
eccb05c
to
4abde33
Compare
/** | ||
* Called when the identity is reset (before onFinished is called). | ||
*/ | ||
onReset: MouseEventHandler<HTMLButtonElement>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a bit weird for 'onReset' to take a mouse event: it's hard to see how the original click would be relevant.
}, | ||
onFinished: () => { | ||
// The user cancelled the reset dialog or click away - go back a step | ||
this.onResetBackClick(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
onFinished is called in either case isn't it? Is there a risk this will confuse things by clicking back after the dialog is done (also I don't love that we are calling click handlers for reasons other than when a click happened).
onReset: () => { | ||
// The user completed the reset process - close this dialog | ||
this.props.onFinished(); | ||
this.onDoneClick(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per below on calling click handlers rather than them just handling clicks.
// Wrappers for ResetIdentityBody's callbacks so that onFinish gets called | ||
// whenever the reset is done, whether by completing successfully, or by | ||
// being cancelled | ||
const onResetWrapper: MouseEventHandler<HTMLButtonElement> = (...args) => { | ||
onFinished(); | ||
onResetFinished(...args); | ||
}; | ||
const onCancelWrapper: () => void = () => { | ||
onFinished(); | ||
onCancelClick(); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General feedback: this seems to immediately change in the next commit, so reviewing it is trickier than it needs to be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Struggling to follow this :/
} else if (phase === Phase.Busy || phase === Phase.ConfirmReset) { | ||
icon = <span className="mx_CompleteSecurity_headerIcon mx_E2EIcon_warning" />; | ||
title = _t("encryption|verification|after_new_login|verify_this_device"); | ||
} else if (phase === Phase.ConfirmReset) { | ||
icon = <span className="mx_CompleteSecurity_headerIcon mx_E2EIcon_warning" />; | ||
title = _t("encryption|verification|after_new_login|reset_confirmation"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about what's going on here. Don't we still need a confirmation step? why do we show "verify this device" (?) when we're in the "ConfirmReset" phase?
* "forgot" is shown when the user has just forgotten their passphrase. | ||
* "forgot" is shown when the user chose 'Forgot recovery key?' during `SetupEncryptionToast`. | ||
* | ||
* "confirm" is shown when the user chose 'Reset all' during `SetupEncryptionBody`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be good to detail how the behaviour is different, rather than when it is called.
} else if (phase === Phase.ConfirmReset) { | ||
return ( | ||
<div> | ||
<p>{_t("encryption|verification|verify_reset_warning_1")}</p> | ||
<p>{_t("encryption|verification|verify_reset_warning_2")}</p> | ||
|
||
<div className="mx_CompleteSecurity_actionRow"> | ||
<AccessibleButton kind="danger_outline" onClick={this.onResetConfirmClick}> | ||
{_t("encryption|verification|reset_proceed_prompt")} | ||
</AccessibleButton> | ||
<AccessibleButton kind="primary" onClick={this.onResetBackClick}> | ||
{_t("action|go_back")} | ||
</AccessibleButton> | ||
</div> | ||
</div> | ||
); | ||
} else if (phase === Phase.Busy || phase === Phase.Loading) { | ||
} else if (phase === Phase.Busy || phase === Phase.Loading || phase == Phase.ConfirmReset) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, bit confused about why it is safe to get rid of the confirm step, and why we now show a spinner for "ConfirmReset".
Fixes #29227
This adds
IdentityResetDialog
, which wrapsIdentityResetBody
in a dialog, and launches it fromSetupEncryptionBody
, instead of doing the reset directly there.This is mostly work by @uhoreg , rebased and refactored a bit here.
I recommend reviewing commit-by-commit.