ACL Help Needed - Make sys_user_group Name field visible to end users in a catalog variable

[t_a_rogers]

Hi Everybody!

In a catalog item I have a Lookup Select Box that pulls a filtered set of groups from our sys_user_group table. This will ultimately determine routing of a specific request, which all works fine simply using "task.setDisplayValue('assignment_group', current.variables.ourvariablename);" in the task we want pointed.

Unfortunately, during testing I found out our end users cannot see the items in this select box, most likely due to no ACL existing which by default allows end users to read data from the Group table.

What is the most basic way I can make an ACL which grants access to the Name field on sys_user_group? I've tried the following and thus far haven't seen any success:

Access Control:

Type: Record

Operation: Read

Admin Overrides: True

Name: Group [sys_user_group]

Field: Name

Advanced: True

Script:

if (gs.getUser().hasRoles())

  answer = true;

else

  answer = false;

Is there an easier way to simply allow this field for anybody to see?

[t_a_rogers]

We have the Navpage link also redirect to ESS.

Hmm, well that debug option seems very useful! Seems to be telling me some script is preventing the access, but I'm not sure where that would be coming from.

[Chuck Tomasi]

If you click the link next to red X, you will be taken to the exact ACL rule. There's a script field that is forcing a false result.

There's your fix!

Yes, I love the ACL debugger. Eureka is when it came about - so much better than the old days.

[t_a_rogers]

That link took me to the OOB sys_user_group ACL. I thought ACLs can't conflict, so that as long as a single ACL reads true you would be able to access something.. Hmm.

Any tips with this one? I'm not capable of following most of the script here. I could always open a case, but you seem so knowledgeable.. lol

EDIT: I suppose i could just inactivate that ACL since we are now allowing anybody to read the sys_user_group table, right?

[Chuck Tomasi]

Hi Travis,

Don't inactivate the existing ACL. Create a new one with just the public role for read access on the table. See my image I included earlier. That will work.

If ACLs conflict, the one with the most access wins. If one says "no" and the other says "yes", you get a "yes" answer.

[t_a_rogers]

Strange. I did create that other ACL earlier and still no-go. So basically I'm back where I was a few steps ago

Why isn't this ACL "winning" the yes/no battle?