You may have noticed that the email field type in your Catalog Item isn’t validating email addresses in the Service Portal.
There is a simple fix for this, and you can get as creative as you want, or keep it simple. I’ll show you a simple method today.
Wait, what just happened?
I was working on a project for a client, and was asked why the email validation on a catalog item wasn’t working, when they were shown a demo of it working. I was at a loss, so I said I would confirm the issue and dig into it.
I’ll admit it pretty quickly, I don’t know everything. What? I know right…I mean I got called out at the airport for stating there was sugar in saltines – little did I know, there was a lady behind me with a box of saltines and she was happy enough to show me I was wrong. But I digress…
I first looked at the client scripts for the catalog item to see if someone wrote a validation for the variable in question and it was somehow broken, but I found nothing. I did though find that variable was an email type which I would assume gets validated out of the box (now what does assume do?)
So inside the platform we can see that yes, the email field does get validated when the form is validated. It will not let you submit until it finds a valid email address.
But in the portal, it allows that email address through as though it’s a valid email address. Now, according to the doc page for catalog variable types, it states:
Support in Service Portal
Unless specified, all variables are supported in Service Portal.
And under the Email variable it states:
The email variable creates a widget for users to enter and select an email address. It accepts only valid email expressions containing @ and domain information.
No mention of not being supported in the Service Portal, though it does state that it is not supported in the mobile UI, and that should be a dead give away for anyone who has spent anytime with the portal side.
No biggie though, we can whip up a quick Catalog Client Script to deal with this and handle it just the same.
So let’s head over to the item:
Service Catalog -> Catalog Definitions -> Maintain Items -> Report an Issue
For the sake of efficiency I have added an Email variable (email type) to the ‘Report an Issue’ catalog item (this should be a standard out of the box item, if not use any catalog item you wish).
Once we have the catalog item up, lets click on the the Catalog Client Scripts tag towards the bottom and create a new one. It should look something like this:
Pro Tip *
Pay attention to the ‘UI Type’ this will help it from colliding with the platform side. So do NOT select ‘All’ or ‘Desktop’ – that already works. We want this functionality strictly on the Service Portal and Mobile.
Let’s walk through the code we want to use:
1. var fieldName = 'email'; //sets the field name to 'email'
2. var email = g_form.getValue(fieldName); //this gets the value of the field
3. var regEx = new RegExp(/^(([^<>()[]\.,;:s@”]+(.[^<>()[]\.,;:s@”]+)*)|(“.+”))@(([[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])|(([a-zA-Z-0-9]+.)+[a-zA-Z]{2,}))$/); //this sets up a new regular expression so we can test the value against it. This is a pattern for correct email address formats.
4. if (!regEx.test(email)) { //if the value of email matches a correct pattern for an email address
5. alert(“The following fields contain invalid text: Email“); //show an alert message on the screen
6. return false; //stop the submission process
7. } //closes the if statement
This checks the value of the email field to see if it matches a pattern of correct email addresses. I know it looks like a whole lotta gobbeledygook, but it really does mean something. It’s out of the scope of this post because there is a lot of information on the subject.
Pro Tip *
It would be wise to glean at least a basic understanding of regular expressions, as they can come in handy in various circumstances and knowing how to look up simple patterns when needed.
After the pattern, you are basically testing against it and if it fails it will show an alert saying it’s failed. It will look exactly like it does inside the platform.
If it passes, it will submit like normal.
Well there you go, it probably took longer to explain it then it will to implement – but now you can validate those pesky email addresses in the Service Portal on your catalog items.
Our experienced practitioners work with customers to provide a concise understanding of how each organization, service, process, and tool should work together and be measured to ensure continued success. Contact a Cask expert today!
