ACL Structuring Scenario (Now with scoped apps!)

[Uncle Rob]

I think I have a way to solve this.   Just wanted to make sure I wasn't overcomplicating or missing something obvious.

I'm rolling out some requested executive functionality.   The executives of various operational business units want visibility to their businesses' consumption of services.

We're building a solution where they can see any work that dot walks up to them (user.cost_center.u_exec)

1)   No problem!   You just need a task read ACL with a task.comment write ACL.

That would be true if most task types didn't have explicit ACL's on Comments.   Because most task extensions are already managing this, you'll almost never get to evaluate a task.comment write ACL.   See "Using Access Control Rules" section 4.1.1

2)   So ... build <tablename>.comment write ACL for each Task table, right?

True.   However the custom task types we're building are all contained in scope.   So we're managing the Exec oversight solution across 1 Global Update Set and 3+ Scoped Apps.   Doable, but not as low maintenance as I'd like.

3)   What if each app had their own solution?

So I started thinking of adding a "read + comment" role for each app, then containing those roles in the Exec Oversight role in Global Scope.   Handy, since each app could actively manage (1) whether or not there was exec level visibility and (2) exactly what that visibility means.   However, by associating <Table> Read to that app role, I risk Execs being able to see WAY more than I want them to (specifically, the records for other execs).

Am I missing any other options?

[coryseering]

Hi Robert,

You don't have to limit yourself to roles in the ACLs. You could combine that with some JS to do lookups against the current user and current record, so you are sure they see only the records you want them to.

I don't have a clear vision of the scenario you are facing, but it seems that something like:

answer = canView();

function canView() {

       var rollsUpTo = current.user.cost_center.u_exec + ''; //string sys_id

       return (rollsUpTo == gs.getUserId()) //userID is sys_id of current user


}

That way the rule requires both the role (which the exec will have based on your description of how you plan to implement them), and for the exec to have a relationship with *this* record.

[Uncle Rob]

Yeah, I have something similar at the moment.   The problem its a to control the Comments field.   The trouble with field level ACL's is that you basically have to write them for every task table.   That's what I'd call "mechanically possible" but not very pragmatic.   I have 4 scoped apps (and counting) and so my executive interaction solution will be splattered across X apps and one Global Update set.

Make sense?

[Uncle Rob]

Ugh... do table level ACL's work the same as field level?   That is, if I have a table level ACL that a user fails, it does not evaluate ACL's on a parent table?

IE if I have table read ACL's on sc_req_item that I fail, and table read ACL's on Task that I pass, is the net effect a fail?

[coryseering]

IE if I have table read ACL's on sc_req_item that I fail, and table read ACL's on Task that I pass, is the net effect a fail?

Correct- you explicitly do not have permission to view that record.

I have 4 scoped apps (and counting) and so my executive interaction solution will be splattered across X apps and one Global Update set.

You could create one scoped app to hold your validation rules, say in a Script Include which is accessible to other scopes. Mark your scoped apps as dependent on this new one. In the ACLs you ship with your scoped apps, reference the script include validation rules in this new validation app. Then you have one place where all of the logic lives, and each app simply calls into it from it's own ACL scripts as needed.