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?

[Uncle Rob]

I'm still trying to figure out what bits actually go into the script include and where that would be called.

Because I have demo with the C's tomorrow, I just opted for every scoped app having its own "executive view" role/ACL suite.   Then I control the Executive View role globally which contains all the scoped roles.   Probably not maintenance friendly but best decision I could make with the remaining time.  

[coryseering]

I'm still trying to figure out what bits actually go into the script include and where that would be called.

I'm thinking of ACL's where the permission is handled via a script. You can create a Script Include in one Scoped App which is marked globally accessible (available to all application scopes). That Script Include would have one or more "canRead"-type methods, which take in the current record, and look up the current user's roles, or relationship to that record, and then via your logic, return true or false.

It sounds like your apps are structured similarly, and they all use the same algorithm for figuring this out, just using different roles per application.

By putting the Script Include with the logic in one application, and calling it in the others, you centralize managing the logic, while maintaining the ability to have different roles installed by each application, and referenced in each application's ACLs.

It may not be what you are actually trying to do- I have a fuzzy idea of what you want to accomplish, but I'm very much a hands-on visualizer. I need to see a problem in action to really be able to understand (and hopefully resolve) it.

I hope your demo goes swimmingly!