Skip to content
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

Prevent registration form submission if backend checks fail (i.e. taken IA/OL username or email address) #9264

Closed
Tracked by #9205
rebecca-shoptaw opened this issue May 13, 2024 · 0 comments · Fixed by #9267
Assignees
Labels
Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Priority: 2 Important, as time permits. [managed] registration Type: Feature Request Issue describes a feature or enhancement we'd like to implement. [managed] Type: Subtask of Epic A subtask that is part of the work breakdown of an epic issue (see comments). [managed]

Comments

@rebecca-shoptaw
Copy link
Collaborator

rebecca-shoptaw commented May 13, 2024

Dependency to epic #7694. Sub-task of #9205.

Describe the problem that you'd like solved

While the real-time validation fixes in #2055 will provide helpful error messages to the user and #9244 will prevent the user from submitting a form with badly-formatted data, the user will still be able to ignore error messages re: taken email or username and submit the form.

Proposal & Constraints

I think the simplest solution would be adding a second check to the manual HTML validation currently in progress in #9245:

if (signupForm.reportValidity()) {
if (window.grecaptcha) {
window.grecaptcha.execute()
}
}

Along with running reportValidity() to trigger the HTML formatting checks, we could add a call to another function like findInvalidInputs that would check if there are any inputs with the invalid class (auto-applied to any inputs that fail realtime checks), and only run the recaptcha/submit the form when both checks pass.

This wouldn't display helpful new error messages the way the HTML checks does, but it would prevent unnecessary bad submissions, and further UI customization (i.e. highlighting existing error messages) could be included in the UI phase of #7694.

Additional context

Will only be able to begin work when #9245 is completed and merged, so as to re-use/expand its logic and avoid merge conflicts.

Stakeholders

@cdrini

@rebecca-shoptaw rebecca-shoptaw added Type: Feature Request Issue describes a feature or enhancement we'd like to implement. [managed] Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] Needs: Lead labels May 13, 2024
@rebecca-shoptaw rebecca-shoptaw self-assigned this May 13, 2024
@rebecca-shoptaw rebecca-shoptaw added Type: Subtask of Epic A subtask that is part of the work breakdown of an epic issue (see comments). [managed] State: Blocked Work has stopped, waiting for something (Info, Dependent fix, etc. See comments). [managed] labels May 13, 2024
@mekarpeles mekarpeles added Priority: 2 Important, as time permits. [managed] Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] and removed Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] Needs: Lead State: Blocked Work has stopped, waiting for something (Info, Dependent fix, etc. See comments). [managed] labels May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Priority: 2 Important, as time permits. [managed] registration Type: Feature Request Issue describes a feature or enhancement we'd like to implement. [managed] Type: Subtask of Epic A subtask that is part of the work breakdown of an epic issue (see comments). [managed]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants