Ran into this one myself when checking to see whether accounts had been imported. The current behaviour made me wonder if it hadn't been implemented, or was broken.

Would need answer from developers to: "Which UI framework was used to build the UI?". We then could see what styles are predefined for errors, notifications and provide a mockup to a developer to implement the feedback.

I'm assuming it's vuetify and will proceed under that assumption until someone tells me otherwise

n.b. https://github.com/wbstack/ui/pull/497 is a draft of what @Charlie_WMDE and I thought it should *look* like

The code probably needs some refactoring (and perhaps adding some testing) to get it to a mergable state

In T305819#8184603, @Tarrow wrote:

The code probably needs some refactoring (and perhaps adding some testing) to get it to a mergable state

It's currently possible to get a success message without putting an email in the box and just pressing submit immediately.

It's currently possible to get a success message without putting an email in the box and just pressing submit immediately.

This is also the case with the existing implementation.

I'll look at adding some *very simple* validation and try as best as possible to follow the vuetify norms.

Addshore already stuck an approved tick on this; let me know if you need or would like to discuss the patch in order to give it an "internal team" tick. I appreciate that as a team we haven't got copious Vue/frontend experience.

https://github.com/wbstack/ui/releases/tag/4.1

https://github.com/wmde/wbaas-deploy/pull/534

production: https://github.com/wmde/wbaas-deploy/pull/535

We may still need to agree exactly what should happen on server errors perhaps we should just call this thing done and pick up T305932

Overall looks really good to me!

Apart from the error message showing which was already captured in this ticket T305932 there's two more things i noticed that probably belong in separate tickets since they weren't part of the initial ACs

1. when an error or success message is displayed, the input field and submit button change to a disabled state. I can not find any good reason to justify this behavior. On the contrary, if the user were to realise, that they made a typo in their email, they'd have to reload the page in order to try again. I would like to suggest that this would be changed, to a version, where the input field gets cleared but stays active, and the submit button stays active as well.

2. My second point is regarding the reset email i was sent. This is how it currently looks like:

Also is there a reason why it says "Regards, WBaaS Wikibase Production"?

Happy to discuss with you @Evelien_WMDE and from my side we can close this ticket as done :)

As a user, I think it makes sense to turn it disabled while it is being submitted, so that I don't accidentally double-submit the form by double-clicking or input bounce. I don't know if doing so would result in a second email and if that would invalidate the first email sent, but if so that would be bad because if the user then opened the first email, the reset would then "not work". It also indicates to the user that the input has been accepted by the browser.

However once the message has been sent (or not sent, in the event of a failure) and the rest of the UI updated, it would make sense for it to be enabled again, either because you have multiple accounts to reset or, as Charlie says, you might have the email wrong the first time.

One more thing I found out. When I hit Enter instead of Reset Password, it didn't work and I received no email.

In T305819#8236182, @dang wrote:

One more thing I found out. When I hit Enter instead of Reset Password, it didn't work and I received no email.

That's a really good point Dat, I've been meaning to bring up before! All our primary buttons do not respond to "enter". I think that is something we should change throughout the page and maybe also look into generally making the page more keyboard accessible.

In T305819#8236018, @GreenReaper wrote:

As a user, I think it makes sense to turn it disabled while it is being submitted, so that I don't accidentally double-submit the form by double-clicking or input bounce. I don't know if doing so would result in a second email and if that would invalidate the first email sent, but if so that would be bad because if the user then opened the first email, the reset would then "not work". It also indicates to the user that the input has been accepted by the browser.

However once the message has been sent (or not sent, in the event of a failure) and the rest of the UI updated, it would make sense for it to be enabled again, either because you have multiple accounts to reset or, as Charlie says, you might have the email wrong the first time.

Thank you for sharing your perspective @GreenReaper , that is a valid point. Ideally we'd have the button be disabled for a second or so to avoid the scenario you described. Since the input field would be cleared after hitting submit I would assume that a rapid second click of the submit button would not result in a second email, but rather in an error message, letting the user know that the field can not be empty. This is something we'd have to test to make sure that the UI reflects the system accurately. That would be a great acceptance criteria for the follow up ticket, thank you!

Closing this as done. As per

@Charlie_WMDE

Happy to discuss with you @Evelien_WMDE and from my side we can close this ticket as done :)

Opened a new ticket for "the submit with enter issue mentioned T317978. Happy to see another new ticket opened to handle if we should indeed disable form after submission