- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 08:56 AM
Hello
I have a UI Macro that contains a script that is supposed to look for entries in a certain table and display them in table format in the Service Catalog. The users that would be using this macro have a particular role.
At the same time, the security on the target table is quite strict. To try to get around this, I had created read ACLs for table, and table.* for the same role.
However, no matter what I do in the macro, it doesn't seem to want to search for any records. Wondering if I should be using a different type of ACL, is there a Query ACL that I can use?
Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 02:29 PM
As it turns out Macros do work well with ACLs
What DOESN'T Work well is if you use a variable that was previously unknown to be a reserved keyword. As I found out, UI Macros interpret the "gr" variable as a global variable unlike business rules that assume that gr is local to the rule itself.
Once I changed the gr to something more distinctive (i.e. grec), the script worked as expected.
*bangs head*

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 09:38 AM
Can you share the UI macro so we can take a look? Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 10:12 AM
<?xml version="1.0" encoding="utf-8" ?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
<g:evaluate var="jvar_asc_client_list">
var gr = new GlideRecordSecure ('table');
var tableData = "<td>";
gr.addQuery ('active', true);
gr.addQuery ('reference.sys_id', reference);
gr.addQuery ('another field', true);
gr.query();
while (gr.next())
{
tableData += "<tr>" + gr.name + "</tr>";
}
tableData += "</td>";
tableData;
</g:evaluate>
<g:no_escape>${jvar_asc_client_list}</g:no_escape>
</j:jelly>
Note that I changed some of the fields as the data in question is confidential.
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 10:17 AM
Check that series of queries (ah, poetry.) You shouldn't need to dot walk to a sys_id (especially in the field name) as a reference field is already a sys_id.
The fact that it shows the right fields to the elevated user indicates the queries should be working. If it's an ACL issue, turn on security debugging (System Diagnostics> Debug Security) and then test your macro to see if you can isolate which ACLs may be causing the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 10:21 AM
The problem is that the restricted user has role A. The enhanced user has roles B, C, and D. The table already deals with ASCs for roles B, C, and D.
Obviously the fix would be to use an ACL to role A to open it up to the table. But that has not worked.
For some reason, ACL logging is not working on the restricted user.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2016 10:23 AM
Just to double check, you enabled debugging then impersonated the user, right? If you logging out and logging back in, that disables/turns off debugging. It remains persistent through an impersonation.