We have a particular web product that we use for all of our clients. It is a pretty incredible system and has several hundred clients. We are one of their largest ones so, between our implementation, and their normal customer needs its understandable why they cannot accomodate every one of our requests right away.
Ooohhh, that’s bad. 😉 I let the company know but I proceed on.
Turns out they, being the creative bunch they are, make use of jQuery. This is definitely turning into a possibility with my toolbox already stocked and ready to go.
Well, I can. 🙂 The vendor also allows us to upload documents to a library that our users can download from. So, I upload the script. Uh, oh, didn’t work. Turns out they block all but a few extensions. So, instead of calling it myscript.js I change it to a text file called myscript.txt. That uploads great and, guess what, the browser is happy to execute it. Great! On my way.
After a few tests it turns out I’m able to quite nicely make our little “issue” a thing of the past. First I check to make sure the page in question is the one being viewed. That way the bulk of the code (all 6 lines of it) runs only when necessary. Then it cleans up after itself by removing my injected code from the page DOM. Nice!
OK, that covers the techy issues, what about the people ones? Well, as you may have guessed, no matter how many times we alerted our users to the changes we made, some users started calling the vendor’s Help Desk asking what happened to the report they were used to. The vendor then called me after spending two days trying to solve the issue they weren’t seeing. They didn’t really care for the changes. They understood the necessity and gave me props for how I handled it but now their Help Desk had no idea if a problem call was because of their system or my code. Granted, this totally makes sense.
So, they gave us a choice. We can continue to develop our own “customizations” but we have to take over all Help Desk calls for our users for the entire system. I understand that, but directly supporting 5,000 users is not something we are capable of doing. I have to note also that the Help Desk is absolutely outstanding, one of the best Ihave ever worked with.
So, after the vendor agreed to look into implementing our change we are allowed to keep the code and support the Help Desk for any questions regarding this one issue. Once the vendor has solved the problem we will remove it and go on our way.
So, here is the moral of the story: Hacking your vendor’s site open doors to lots and lots of capabilities, however, it may aggravate your vendor a little or, quite possibly, cause an early termination to your contract. I suggest you keep this little tool in your developer’s pocket for extreme cases.
It was fun and our vendor is great. Once I put the change in place we started to come up with lists of additional “nice to have” features I could implement, but, in the end, we’ll just hand those over to our vendor and see if they make it in someday.