sys_id glideAggregate

Viktor Stepanov
Mega Contributor

Hello all,

Would anybody here possibly know a trick how to query a sys_id from assigned_to field when using GlideAggregate?

(function executeRule(current, previous /*null when async*/) {

    //assigned to mi vrati sys_id

var ga = new GlideAggregate('incident');
ga.addQuery('active', 'true');
ga.addQuery('assigned_to', current.sys_id)
ga.addQuery('state', 2);
ga.addAggregate('count');
ga.orderByAggregate('count');
ga.groupBy('assigned_to');
ga.query();

while(ga.next()) {
     var taskCount = ga.getAggregate('count');
     current.u_assigned_to_sum = taskCount;

}
    //ga.assigned_to.name ==

})(current, previous);

 

I think it's the last touch to this script ot be working.

Thanks!

VS

1 ACCEPTED SOLUTION

Mark Stanger
Giga Sage

What you're doing shouldn't be a problem as long as the script is running from the 'sys_user' table.

The ga.addQuery('assigned_to', current.sys_id) says grab the sys_id from the 'current' record.  The only table with records that could match here is the 'sys_user' table because that's what 'assigned_to' references.  If you're running from another table then you probably need 'current.FIELD_NAME.sys_id' to pull from something like a reference field to compare to the 'assigned_to'.

View solution in original post

3 REPLIES 3

Mark Stanger
Giga Sage

What you're doing shouldn't be a problem as long as the script is running from the 'sys_user' table.

The ga.addQuery('assigned_to', current.sys_id) says grab the sys_id from the 'current' record.  The only table with records that could match here is the 'sys_user' table because that's what 'assigned_to' references.  If you're running from another table then you probably need 'current.FIELD_NAME.sys_id' to pull from something like a reference field to compare to the 'assigned_to'.

Hello Mark,

 

Thanks for the tip, yeah it really did grab the sys_id and now is able to populate the correct number - thank you!

I wonder now how to get the whole table updated with this when loaded or changed - the Business rule at is set to Before at the moment and current.update() makes very strange things happen.

'current.update()' is always going to cause you problems and should be avoided at all costs.  Your business rule is already operating around a 'current.update()' that you get for free from hitting 'Save', 'Submit', or 'Update' on the record.  If you're using a 'before' business rule, your code runs before the 'current.update()' so you don't need to include it in your code at all.  If you're running an 'after' business rule, the 'current.update()' has just barely run so you're going to be duplicating time stamps, field entries, email events, and anything else triggered in a business rule or workflow...so it's very bad in both cases.

Please mark my answer above as correct if it's answered your question.