feat: pick number, phone, email and web address when adding a question - #3639
Open
global-prog wants to merge 2 commits into
Open
feat: pick number, phone, email and web address when adding a question#3639global-prog wants to merge 2 commits into
global-prog wants to merge 2 commits into
Conversation
The validation for phone numbers, email addresses and numbers already exists, but it can only be reached from the input-type menu inside a short-text question that has already been created. Someone adding a question sees only "Short answer" and has no reason to know the rest is there. These four appear directly in the add-question menu. Each is a preset: an ordinary short-text question created with its validation already set, applied client-side after creation, so no new backend type is introduced and nothing changes on the server. Email is deliberately a preset rather than a type of its own. Question::checkEmailType() recognises an email question only as short text carrying email validation, and the confirmation-email recipient picker depends on that test, so a dedicated type would have quietly broken it. Web address uses the existing regex validation, since there is no dedicated URL validator. The pattern is kept simple because it must be valid in both JavaScript and PCRE - the browser and the server each apply it - and was checked against both to behave identically: http and https in any case are accepted, other schemes, bare text and addresses containing spaces are rejected. The preset mechanism is generic, so further presets cost only an entry in the answer type list. Signed-off-by: global-prog <raqeeb@uosamarra.edu.iq>
Collaborator
|
I don't think that we should add this overhead. |
Author
|
Thanks for taking a look. So that I address the right thing — do you mean the four extra entries in the add-question menu, or the preset mechanism itself? What I was trying to fix is discoverability rather than capability. Phone, email and number validation already exist, but they can only be reached from the input-type menu inside a short-text question that has already been created, so someone adding a question has no particular reason to know they are there. If menu length is the concern, two smaller options keep that without four new entries:
And if you would rather not have any of it, I am happy to close it — no objection from me. Just say which you prefer. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation for phone numbers, email addresses and numbers already exists — but it can only be reached from the input-type menu inside a short-text question that has already been created. Someone adding a question sees only "Short answer" and has no particular reason to know the rest is there.
This makes four of them pickable directly from the add-question menu:
How
Each is a preset: an ordinary short-text question created with its validation already set, applied client-side after creation. No new backend type is introduced and nothing changes on the server.
Email is deliberately a preset rather than a type of its own.
Question::checkEmailType()recognises an email question only as short text carrying email validation, and the confirmation-email recipient picker depends on that test — a dedicatedemailtype would have quietly broken it.Web address uses the existing regex validation, since there is no dedicated URL validator. The pattern is kept simple because it has to be valid in both JavaScript and PCRE — the browser and the server each apply it — and it was checked against both engines to behave identically:
https://example.org/xhttp://a.bHTTPS://X.Ynot a urlftp://x.yhttps://has spaceThe preset mechanism is generic, so further presets cost only an entry in the answer type list.
Scope
openapi.jsonunaffectedTesting
npm run lint,npm run typecheckandprettier --checkall cleanmainwith no errors