Stuff I wish I knew earlier

Thursday, November 27, 2014

I just upgraded from the Basis Carbon Steel to the new Peak. The data was preserved in the migration and all I needed to do was install a new app on my iPhone and log in again.

Some random thoughts:

The screen is larger but it is less thick. As such it feels smaller in some sense.

The new charger doesn't require the unit to be slid in; you can just drop it on there. However, it seems to have the same problem that if you aren't paying attention, you can put it on the 'wrong way' and even though it is seated snugly, it doesn't appear to charge.

A 'power brick' for the USB adapter wasn't provided. I don't mind since I have the Anker 40W 5-port USB charger.

Firmware updates can be done from the phone now so it doesn't look like you need to periodically attach it to a computer.

Sync'ing is now continuous so you don't need to remember to manually sync (or forget and fill the memory of the unit).

The constant connection to the iPhone 5 doesn't seem to be a bad battery drain

From a marketing perspective for current customers, they offered a $30 credit after I had already pre-ordered and received the Peak from Amazon. That was really bad timing and what is disappointing is that they aren't offering that credit towards something like a second charger.

At this point, none of the advanced functionality (seeing texts on the screen, stop watch, etc.) is available which is a little disappointing. Hopefully, it won't be too long before these updates come out.

If you run the code, you'll see that gs.dateDiff() returns the same value for the difference between date1/date2 and date1/date3 even though there is a 10 minute difference. Why is it rounding to the full number of days?

Well, it turns out that the default string conversion is not what gs.dateDiff() is expecting. Instead, it is expecting the date/time string in the user's display format.

(so if your default date / timeformat matches the internal, then you'd actually get the correct results and wonder what I'm complaining about.)

Instead of just failing, gs.dateDiff() seems to do the math where it can (e.g. the difference in days). This seems a poor choice in that you are giving the impression of valid results when the results are not accurate.

What you need to do to make sure you get the correct results is the following:

Sunday, June 29, 2014

You would think it would be really simple to specify where you want to go when you are done with a Survey created by a Survey Wizard. You'd be mostly right.

If you select the Survey Wizard in question, you'll notice that there is nothing on the page, because, well, that'd be too easy. You'll need to Personalize the form and add 'Redirect' to the form. After that, it is a 40 character (beware long urls) string field that you can put in a url that you will be redirected to at the end of the survey.

Do not waste your time by trying to use a redirect panel. They don't seem to work. If you do go down the redirect panel path and wonder why they aren't showing up on the main survey wizard panel under 'survey panels', that's because you need to personalize the form and add 'redirect panels' as its own tab.

What would have been nicer is if everything were hidden. That way, you'd know to go look. Rolling 1d4 to see if the field should be hidden seems bordering on cruel and inhumane.

If you are on Eureka, it looks like there is a newer survey mechanism so all this may be moot.

Tuesday, June 24, 2014

However, you enable the listener and you get the error: "[LDAP: error code 12 - Unavailable Critical Extension]" Boo!

Turns out that when you configured your LDAP server ages ago, you may have set the 'Vendor' field to be 'Active Directory' because, hey, that was the default or you wanted to see if changing the vendor field did anything. Since it didn't, you may have forgotten to change it back. It doesn't help that the server configuration page doesn't show this field (so you probably want to add it back to the page).

After changing the vendor to 'Other' (the only other choice), the error doesn't seem to be occurring now. Now, the fun part to see how persistent search interacts on imports.

Saturday, March 15, 2014

You’re trying to save your spiffy new record but var incSid = current.insert()
is returning null.Boo.

To make matters more fun, this code is an Inbound Email Action. One might suspect that the guy responsible for anything with the letters e-m-a-i-l in ServiceNow must really like creating puzzles or hate wasting disk space on silly things known as error messages.

The first thought is that it could be an ACL issue. You don't have create rights to the table so that must be why it is failing. The only problem with that theory is that you are an admin and so theoretically the code is running in your authorization context.

So what now? Bad data maybe? Ok, so off to our friend 'Background Scripts'. Let's try a field that doesn't exist

var x = new GlideRecord('incident');

x.u_something_that_cant_exist = true;

gs.log(x.insert());

Well, that returned a sys_id and not null. But it did seem to return some log messages.

So, this was a fruitful path to investigate. I went ahead and replaced incident with the table in question and voila, we get an error message when running the background script: