CV Request Generator - warn/prevent submission when submitting short (typo) request reasons

[Tyler-H]

A cv-pls request was submitted recently using the request generator script recently that just had "e" as the reason for closure. It was brought to my attention that the script supports shortcuts such as "r" for the 'No Repro' reason, and that this was likely a typo.

My enhancement request is:

Add a warning (which prevents submission) if someone posts a 1 or 2 character close reason in the generator window that isn't detected as mapping to an abbreviation. E.g. someone posts "e" or even "re" or "er", the generator does a quick mapping attempt and, if nothing is found, warns the user of no abbreviation match and likely typo reason, and prevents them from submitting the request.

[Tyler-H]

As someone who doesn't use the CV Request Generator userscript, I'm not familiar with the shortcuts, so I was close to binning the request before Dharman and John Dvorak explained what likely happened here. This feature would help prevent similar situations from occurring in the future (and will help with clarity/transparency for anyone else not using the script who reads the room messages/transcript wondering why a question was closed).

[Tyler-H]

After getting a screenshot of the options from Scratte (https://i.stack.imgur.com/4zl7d.png), it seems the situation is a bit stickier... "E" is an option but "e" isn't... and the options are case-sensitive. :-(

[makyen]

OK. The alpha version provides a preview of what the request actually looks like, including expanding any shortcuts. Shouldn't the user look at the preview to verify that the actual request that will be sent is what they want?

I guess that we can just have a warning (warnings require the user to click through a confirm() dialog) that checks that the request reason used equates to some minimum number of characters. How many characters should be the minimum at which we require the user to confirm()?

[Tyler-H]

My personal preference now that I see the list would be a full re-design of the shortcuts to avoid case-sensitivity (and make each shortcut 3 or 4 characters for safety). However, I know that's not likely to happen as there'd be a lot of complaint by users having to re-learn the shortcuts. I would thus suggest the following (start at the top circle):

If we get issues with short-length reasons that are longer than 1 character, we could probably revisit the length requirement then.

[makyen]

Why not just set a minimum required length for the request reason that would actually be sent? The full request is already generated on every keystroke in order to provide the preview, and the request reason is already checked to verify that the request reason is not empty.