opnsense
Could you please do this behind the scenes rather than have the user edit the value manually?
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [ x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Is your feature request related to a problem? Please describe.
N/A
Describe the solution you like
Since the code already knows all of the requirements that the value has to satisfy, it can instead do all of the replacements itself, instead of having the user go back and perform them manually. I.e. it could add a leading underscore in front of numbers, behind the scenes, replace the spaces, dashes, or periods also behind the scenes, and trim the excess of 32 characters. The current approach kills the sysadmin's productivity.
Describe alternatives you considered
Manually replacing each invalid character.
Additional context
I'm afraid that's not a blanket solution to the subtleties that validation can bring. We cannot fix all the time what the user assumed he wanted and APIs also need to be made aware of this otherwise save will go through and the client and the config will differ in what they've set.
There are only so few characters that encompass 99.9% of the input into this field. They are common punctuation marks found in company names:
- spaces
- periods
- commas
- dashes
- and leading digits
These 5x are all that should be handled behind the scenes. I am not hallucinating that any reasonable software developer will be prepared to handle the entire ASCII or Unicode character set. You are already throwing a detailed message, i.e. the code knows which rules are being violated. The only change would be that they will be automatically corrected in the code instead of telling the user to go back and edit. At the minimum, the code behind the scene could add a leading underscore in front of company names that begin with a digit, which is not uncommon: 1A Auto, 123 Hosing, etc. There are 10s of 1000s of such popular company names, and admins have to remember to manually add an underscore in front of them all the time. The code could do it if it can't stand the leading digit. It does not even need to appear anywhere on screen.
I see your point and your tickets are all rather valid from a UX perspective. In the past, however, i.e. the spaces situation went as far as removing spaces from password input and stored it wrong in the config.xml. We do normalize some data (like MAC addresses) when we can, but it's not a priority for us to fix user input from a pure slop perspective. The API's task is to force rejecting input because otherwise you will not find them in your scripts. Diverging from this is possible but was never done historically (except when it did, see password-spaces-situation) and few people expect this to take place, certainly not in the scope of commercial firewall vendors like we try to compare with when we can.
Cheers, Franco
The comparison to password input is apples and oranges, TBH. One is telltale, the other is masked. One is for display only, the other has to be verbatim. Also, the restriction on the leading digit that requires the user to manually add a leading underscore is also a no-brainer: add it in the code and don't even inform the user that it's there. It's a 1-liner from the coding perspective, whereas the productivity gained is dramatic in terms of time no longer wasted.
Well, you already made one exception to your generic request which was my point earlier.
Cheers, Franco
Sorry, but I do not follow. I am not asking you to fix errors that you refer to as slop. I am asking you to address the restrictions on otherwise reasonable user input that you yourself impose. From the user's perspective the alias name that matches the entity name that it applies to is perfectly reasonable and valid, but the system refuses to accept it for its internal reasons, whereas it could have transparently and gracefully adjusted that input to suit itself. What am I missing?
I’m just not sure where to start and what the scope should be. The model? The backend? The frontend? The JS code client side? You have downsides in all approaches. Syntax errors are an established way to indicate errors. Passing errors to underlying components is not working either. The config.xml either is a way for correct input or not. For the moment it certainly is.
Cheers, Franco