We stumbled across an interesting loophole today. The general rule is that you put things inside of a scoped app so that you can make sure things aren’t touching the records in your scoped app.
However, if your scoped table is a child of something in the global scope (like the task table), then you can actually make changes to the task-related fields from the global scope.
Something that might either trip you up, or which could be really useful at some point.
It turns out that if you use an invalid field name on a GlideRecord.addQuery() method call, it doesn’t fail (which is what I would have expected it to do). Instead, I runs through all of the records in the underlying table you’ve queried.
That’s annoying in a situation where you’re just querying for informational purposes and you get back several thousand times more records than you were expecting to get. It’s a lot worse than that if you’re in a situation where you’re making an update and you’ve got a typo in the field_name. It will result in an update being made to every record in that table.
Something else to watch for. I always recommend running any update query with a count variable and the update piece commented out first. That lets you confirm that you’re getting the expected number of records back, after which you can go ahead and perform the updates.
A hat tip to my amazing co-worker, Jasmine, who helped figure this out.
Here’s an example of how not to do it:
var gr = new GlideRecord('incident');
gr.addQuery('descriptio', 'Something...');
gr.query();
while(gr.next()) {
gr.setValue('short_description', 'Redacted');
gr.update();
}As you can see, I’ve used ‘descriptio’ instead of ‘description’ in line two.