Glide Record is always empty

[bigbacon]

I am trying to get a script to go look up a record and grab a value to return during an onChange event.

I have this include:

var HRTT4UTicket = Class.create();
HRTT4UTicket.prototype = Object.extendsObject(global.AbstractAjaxProcessor, {
getJobTitleCodeHRIS: function() {
		var sysid = this.getParameter('sysparm_sysid');

		try {
			var ghjobGR = new GlideRecord('sn_hr_core_greenhouse_job_import');
			ghjobGR.addQuery('sys_id', sysid);
			ghjobGR.query();
			
			if(ghjobGR.next()) {
				//var objReturn = {
				//	jobcodeHRIS : ghjobGR.JobCodeHRIS.toString()
				//};
				//return JSON.stringify(objReturn);
				return ghjobGR.JobCodeHRIS;
			}
			else {
				return 'nothing';
			}	
		}
		catch(e) {
			return 'error' + e;
		}		
	},
    type: 'HRTT4UTicket'
});

and what seems to be happening is even though I am sending a valid sys_id to this function, it just returns an empty record set for the given table, which causes it to always send a null value back.

I cannot figure out why this doesn't work. The sys_id being sent is valid, I can go to the table data list manually and look up the record but it will not do it through this client script. We have other similar scripts that seem to work just fine. 

I have also tried it as just a .get(sys_id) and that return the same result. 

It is like the script doesn't have access to the table yet it does?

I can make the script just return any random string and it gets returned just fine.

What am I missing here? 

[Brad Bowman]

The box is checked and read only for new tables, and a User role is required.  Your account has the admin role so this shouldn't matter, unless you have an ACL that doesn't have admin override.  You can view ACLs via the left nav (ACL) but to modify and sometimes fully view them (not in read only mode) you have to Elevate role to security admin in the avatar menu.  ACLs were formerly used only to deny access, so you don't need an ACL to allow, but having one not configured correctly could prohibit access.  In recent releases there are now also 'allow' ACLs.  Generally, if you can see data in every field on records, then you have access.  With the script running as your user, the 'execute' rule might come into play.  

I've lost track - have you tried running the same script with the sys_id you are testing hard-coded in a Fix Script with a line to gs.print the results - just to take the Client Script and Script Include possible obstacles out of the equation? 

[bigbacon]

At this point I don't even know what I'm looking for. the ACL thing is out of my league. I will have to either delete the table and see if someone else creating it fixes my issue or figure out some other route to do what I need because I'm wasting to much time trying to figure this out and no one here knows what to do about it either.