STRIPESFF-39: ECS - display Cancel confirmation popup on users edit page with not uniq username #121
Conversation
…age with not uniq username
There was a problem hiding this comment.
@alisher-epam, IIUC, this change pulls submitSucceeded off the list of form-properties the FormSpy subscribes to. It doesn't "set submitSucceeded to true as suggested in the PR description. IOW, the same effect could be achieved by omitting that key, rather than setting it to false, which I think would be a cleaner implementation.
Regardless, I don’t understand how there is anything specific to ECS going on here. Can you explain why you think this is the correct change, and why this bug would be present in an ECS env but not a single-tenant env?
CHANGELOG.md
Outdated
| @@ -2,6 +2,8 @@ | |||
|
|
|||
| ## 8.2.0 IN PROGRESS | |||
|
|
|||
| * ESC - Cancel confirmation popup does not appear on user edit page after entering not unique Username. Refs STRIPESFF-39. | |||
There was a problem hiding this comment.
@zburke It is a very interesting and tricky bug. QA could only reproduce it in the ECS environment. Because the username uniqueness can be validated for the current tenant on username input change. That's why the behavior is reproducible via cross-tenant check only.
There was a problem hiding this comment.
My concern is that you have described ECS-specific behavior but this is not an ECS-specific fix; it will change the behavior for everybody.
If we can't reproduce the behavior in a single-tenant setting, we should not change the behavior in a single-tenant setting. Instead, we should look at why cross-tenant username validation isn't correctly triggering the navigation-confirmation dialog.
|
| @@ -121,7 +121,6 @@ class StripesFinalFormWrapper extends Component { | |||
| <FormSpy | |||
| subscription={{ | |||
| dirty: true, | |||
| submitSucceeded: true, | |||
There was a problem hiding this comment.
It's hard to predict how this change will affect all the other forms in FOLIO. It might be safer to add a separate prop for FormSpy configuration.
Purpose
The issue arises when a user tries to edit their
usernamebut enters a non-unique (already taken) username, then clicks the Cancel button. In this scenario, the Cancel confirmation dialog does not appear as expected.The reason for this behavior is that
submitSucceededproperty here is initially set totrue, which means the form mistakenly assumes that the submission was successful, even though it wasn’t due to the username conflict. This causes the form to skip the Cancel confirmation prompt.Approach
Screen.Recording.2024-11-11.at.14.56.53.mp4