Email address stupidity check

[UKenGB]

When an email address is entered, it is checked and rejected if the PBX decides it is not valid, which means it is impossible to enter addresses which do not contain the @ and I think maybe it likes to see at least one period. Anyway, the problem is, in my local network, there is NO domain part required, just the username. In fact, it is kinda tricky to make it work with any domain part. For local email, it is just sent to the username. But, snomONE WILL NOT LET ME add this as an email address.

 

First of all, I would point out that that the username on its own is an entirely valid email address and works PERFECTLY once I have edited the relevant XML file, but this is a PIA (not least because of the total lack of readable formatting in pbxnsip's XML files - a daft omission).

 

Secondly, I firmly believe it is not appropriate to attempt to FORCE users into adopting the practices perceived as 'correct' by the developers, even when correct, but especially not when those beliefs are themselves invalid or inaccurate. Sorry, but this is a case of TOO MUCH CONTROL.

 

So, please, could we not be allowed to enter whatever we want as an email address? If it's wrong, it won't work and we correct it. What's so bad about that? Why do we need these idiot checks by the software developers - as I said, particularly when they GET IT WRONG.

 

Perhaps some support here would convince snom of the error of their ways so they remove such checking and let us enter any email addresses we want.

[pbx support]

Well we had it 'whatever' way. But 90% of the customers suggested that it is always good to do the standard email address check. We generally listen to the customers

 

For the rest 10%, there is always a way out. You can change the script that does email syntax checking (validate_email function under client_side_scripts.js). Use the "Web Page Control" to modify this function. Just delete everything but the last line in this function. Reload the page & should be all set.

 

You seem to contradict your own philosophy by telling what others should do.. take it easy!

[mattlandis]

you can blame snom ONE for some things, but not being too picky about what is typed in a field!! ;-)

snom ONE is the "wild west" in this respect. (with all due respect) And this capability is a "doubled edged sword".

 

Anyway, the point that validation can be changed/or xml edited does provide a work around to what I would expect is a somewhat esoteric situation.

[UKenGB]

Well we had it 'whatever' way. But 90% of the customers suggested that it is always good to do the standard email address check. We generally listen to the customers

 

For the rest 10%, there is always a way out. You can change the script that does email syntax checking (validate_email function under client_side_scripts.js). Use the "Web Page Control" to modify this function. Just delete everything but the last line in this function. Reload the page & should be all set.

 

You seem to contradict your own philosophy by telling what others should do.. take it easy!

 

No contradiction there at all. I'm just preaching freedom from control. To view that as some sort of control in itself is one of the great philosophical fallacies.

 

As regards other customers requesting the validation check, it saddens me that they have requested a feature that actually prevents the use of valid email addresses. It's just the way of the world these days. CONTROL everything - not because it's necessary, but just because you can.

 

The ability to modify the validation function is however a truly great feature and I'm delighted to find it's included. Where would I find this mentioned in the manual?

[pbx support]

The "Admin->Web Page Control" lets you change pretty much everything about the web interface. If you or your customer did not like certain translation on the web pages or format or style or anything else on the web interface, you can changes it on the fly,

In the original manual, we did not highlight it too much(Also, it was hidden under "Email" tab). But going forward we are highlighting it.