Script Include Query Returns Undefined

[Matt Dumont1]

I am modifying Chuck Tomasi's Loaner Request Module and have run into a problem.   The e-mail notifications included in the update set do not appear to be triggering.   I also confirmed that the below simple script returns "undefined" when fired in a script include, but not when fired from the Background Script module.   This would likely be the source of the problem as Chuck's code uses a script include to query for the loaner requests that need an e-mail triggered.

var gr = new GlideRecord('loaner_request');

gr.query();

while(gr.next()) {
gs.log(gr.number);
}

It works fine if I run it from a script include on the incident or even loaner_task tables.   I noticed by debugging the script that gr.query() does a role check for "loaner_admin" role that is not performed when querying other tables.   I tried disabling all of the non-field-specific ACLs on the loaner_request table just to test this theory, but was still receiving the same results.   I'm sure it is something obvious that I am overlooking.   Any suggestions would be helpful.   Thanks!

Edit: I have determined that the only time the query does not work is when I specifically access it from a scheduled job and query the loaner_request table.   If I use the same scheduled job to query the incident table, it does not fail.   If I use the background script to run the script include, it does not fail.   Curiouser and curiouser.

Message was edited by: Matthew Dumont

[Chuck Tomasi]

I agree with Trey. I just checked my loaner request dev system and noted that Run as was set to "System Administrator" (the default one that comes with the demo data.) If you disabled the account, it should still work. If you removed it entirely, then it's a null pointer. I'm not sure who is running the script if you set it, then blank it out.

[Matt Dumont1]

Indeed, it appears that the "System Administrator" user does not exist in the system.   One of the unfortunate side-effects of inheriting a code base.   There are several scripts currently running without a user in the "Run As" field.   This may be indicative of a systemic problem if we do not resolve that issue.   I'm surprised more jobs have not failed.   Thanks so much for the quick response!

[andrew_venables]

I believe a scheduled job with no Run as set will run as the system account. Note this is not the System Administrator user account.

I can't find the link to the Wiki that confirms this but i've just tried it on a demo instance and it looks right.

[Matt Dumont1]

Andrew,

        Thanks for the info.   If you do find the documentation,   I would appreciate if you could post it here.     The only article I found on the subject had just this to say about "Run As":

The user creating and running the scheduled job. To have the scheduled job assigned to system behavior instead of the person creating the scheduled job, create a system or "dummy" user and add that user to this field.

Cheers!

Matt Dumont