“The greatest performance improvement of all is when a system goes from not working to working.”
— John Ousterhout
The other day I was showing off my Incident email hack, and to my surprise, the thing did not work. I was reminded of something my old boss used to tell me whenever we had blown a demonstration to a potential customer. “There are only two kinds of demos,” he would say, “Those that don’t count and those that don’t work.” But my email hack had been working flawlessly for quite some time, so I couldn’t imagine why it wasn’t working that day. Then I realized that I couldn’t remember trying it since I upgraded my instance to Madrid. Something was different now, and I needed to figure out what that was.
It didn’t take much of an investigation to locate the failing line of code. As it turns out, it wasn’t in anything that I had written, but in an existing function that I had leveraged to populate the selected email addresses. That’s not to suggest that the source of the problem was not my fault; it just meant that I had to do a little more digging to get down to the heart of the issue. The function, addEmailAddressToList, required an INPUT element as one of the arguments, but for my usage, there was no such INPUT element. But when I looked at the code inside the function, the only reference to the INPUT element was to access the value property. So, I just created a simple object and set the value to the email address that I wanted to add, and then passed that in to the function. That worked just fine at the time, but that was the old version of this function.
In the updated version that comes with Madrid, there is new code to access the ac property of the INPUT element and run a function of the ac object called getAddressFilterIds. My little fake INPUT element had no ac property, and thus, no getAddressFilterIds function, so that’s where things broke down. No problem, though. If I can make a fake INPUT element, I can add a fake ac object to it, and give that fake ac object a fake getAddressFilterIds function. I would need to know what the function does, or more importantly, what it is supposed to return, but that was easy enough to figure out as well. In the end, all I really needed to do to get past that error was add these lines to the incident_email_client_hack UI Script:
input.ac = {};
input.ac.getAddressFilterIds = function() {return '';};
Unfortunately, things still didn’t work after that. Once I got past that first error, I ran right into another similar error, as it was trying to run yet another missing function of the ac object called resetInputField. So, I added yet another line of code:
input.ac.resetInputField = function() {return '';};
Voila! Now we were back in action. I did a little more testing, just to be sure, but as far as I can tell, that solved the issue for this version, and since all I did was add bloat to the fake INPUT element that would never be referenced in the old version, it would be backwards compatible as well, and work just fine now in either version. Still, now that all the parts were laid out, I decided that I could clean the whole mess up a little bit by defining the fake INPUT element all in a single line of code:
var input = {
value: recipient[i].email,
ac: {
getAddressFilterIds: function() {
return '';
},
resetInputField: function() {
return '';
}
}
};
There, that’s better! Now, instead of adding three new lines of code, I actually ended up removing a line. For those of you playing along at home, I gathered up all of the original parts and pieces along with the updated version of this script and uploaded a new version of the Update Set for this hack.
