feat: pick number, phone, email and web address when adding a question - #3639
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>
|
I don't think that we should add this overhead. |
|
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. |
|
@global-prog I'd prefer creating a user-facing documentation/manual that describes the features. see #2643 |
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