Skip to content

feat: pick number, phone, email and web address when adding a question - #3639

Open
global-prog wants to merge 2 commits into
nextcloud:mainfrom
global-prog:contrib/input-type-presets
Open

feat: pick number, phone, email and web address when adding a question#3639
global-prog wants to merge 2 commits into
nextcloud:mainfrom
global-prog:contrib/input-type-presets

Conversation

@global-prog

Copy link
Copy Markdown

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:

  • Number
  • Phone number
  • Email address
  • Web address

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 dedicated email 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 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:

input result
https://example.org/x accepted
http://a.b accepted
HTTPS://X.Y accepted
not a url rejected
ftp://x.y rejected
https://has space rejected

The preset mechanism is generic, so further presets cost only an entry in the answer type list.

Scope

  • two files, frontend only
  • no schema change, no API change, openapi.json unaffected

Testing

  • npm run lint, npm run typecheck and prettier --check all clean
  • built against current main with no errors
  • checked each of the four: created from the menu, validation applied immediately without a reload, an invalid value rejected on submit, and the confirmation-email recipient picker still offering a question created via the Email preset

global-prog and others added 2 commits September 9, 2026 04:18
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>
@Chartman123

Copy link
Copy Markdown
Collaborator

I don't think that we should add this overhead.

@global-prog

Copy link
Copy Markdown
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:

  • surface the input type at add-time on the existing Short answer entry, instead of adding separate ones;
  • or add Number only, as the one that is arguably a distinct question type rather than a text field with a pattern.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants