Limit Data visibility with ACLs

#1

I have a type Facility that mixes AclEnabled, now I created a EnableAclPrivilege for this type as follows:

{
  "enabled" : true,
  "id" : "facility_acl_controlled",
  "name" : "Facility Acl Controlled",
  "typeName" : "Facility"
}

1- Do I have to manually refresh ACLs for existing Facility instances? i.e. calling

Facility.populateAcl()

or

Facility.refreshAcls(spec)

2- How can I customize the AclEntry beeing created? Can we create AclEntry per AdminGroup to not have to manually add an entry per member. It seems by default AclEntry will have this shape:

{
  "canUpdate" : true,
  "canRemove" : true,
  "canModifyAcl" : true,
  "member" : {
    "id" : "user_id"
  },
  "source" : "PrivilegePolicy"
}

3- I have defined an ActionCondition that limits the visibility of facilities as follows but it does not seems to work:

{
  "id": "FacilityVisibilityRole",
  "name": "Allow read access to any facilities related to customer  in Consip App",
  "permissions": [
    "allow:Facility::*"
    . . .
  ],
  "actionConditions": [
    "Facility::*:(denormParents.from.Facility.billingAccounts.memberAccounts.member.id== _context.userName)"
     . . .
  ]
}

And the following command is returning nothing for Facilities I’ve created:

c3Grid(Facility.fetch({include: "acl", filter: "exists(acl)"}))
0 Likes

Access Control for Fields on a Type
#2

1— I imagine that if you are setting AclEnabled.enabled to true for the first time, you should probably call refreshAcls (the batch version of populateAcl) before you’ll see the effects.
2— The types that extend Member are User, Role, and AdminGroup. So yes, you can (and should!) create an AclEntry per AdminGroup.
3— Make sure you’ve added the Role to the correct AdminGroup and that there are no conflicting actionConditions—and double check that your user is a member of that AdminGroup

When testing, make sure that your expected EnableAclPrivilage, Role, and AdminGroup data exists in your tenant—these types are facaded so all tags within a tenant share the same data. If different data is provisioned to another tag, your changes may be overwritten. And double check that your EnableAclPrivilege looks how you’d expect it to after provisioning. EnableAclPrivilege mixes PrivilegeBase, which mixes SeedData, so user edits are preserved. If you’ve made changes to a record via the console, then any future edits you make it in seed data will be ignored.

1 Like

#3

OK this is why I was provisioning with enabled to true but on console I see false all the time! But this means I will have to manually check on all environments.

0 Likes

#4

Do I have to create a CRON job that will trigger the ACL refreshing?

0 Likes

#5

Yes, don’t edit seed data manually, this is why we call it “SeedData” and not “MetaData”

0 Likes

#6

No it will happen automatically when data is added or changes (like analytics)

1 Like