I have a fun one here.
We have a business rule that assists with an auto-assignment process that we have on the Incident table (and a few others). As a part of this process, this business rule runs a glideaggregate to the incident table and determines the workload each technician has at that exact moment. Whoever has the lowest perceived workload, gets the assignment.
Here is the GlideAggregate code we're running. It's about as simple as one can get
//count up the incidents
var inc = new GlideAggregate('incident');
inc.addAggregate('COUNT');
inc.addEncodedQuery('active=true^assigned_to=' + tech);
inc.query();
if(inc.next()){
incPoints = inc.getAggregate('COUNT');
}
Here's the issue: this business rule appears to be honoring ACLs that are in place against the incident table, although I believe I've read that this shouldn't be the case, both here on the Community and in the docs somewhere.
My reason for thinking ACLs are the culprit is if I submit an incident via our Service Portal using my own account (with the admin role), the glideaggregate pulls back and tallies all active incidents assigned to each tech, as intended.
However, when I run this as an ESS user via the Service Portal, the glideaggregate only pulls back records for which the user is in the caller_id or opened_by fields, or on the watch_list. Coincidentally, these are the exact conditions for our ACLs that we have applied to ESS users on the incident table.
Not that it provides much evidence to my theory, but below is a quick shot of some logs I created for troubleshooting.
You can see my admin account pulls back a lot more records from the incident table that the ESS users account does not
Oddly enough, one of the other lookups we do is to the sc_req_item table, which is working just fine. We are only experiencing this issue on the incident table.
So, my question is, do business rules, in fact, ignore ACLs and run as the system? Or are those ACLs being honored here? If the latter, is there anything I can do to bypass this?
