Page History

...

This screenshot shows sets which are hierarchical bundles of privilege resources.  In this case "caHostFind.jsp" is a resource which is a screen in the system, and it is in the "ca" set, which is in the "officeJSP" set.

...

Wiki MarkupThis screenshot shows the view/assignment screen where you can assign privileges to a group, or to a user in a group. !authAssignment.gif! In this Image Added
In this case, some entries are red and green (if allowed or forbidden).    Most resources inherit permissions from a parent set or a parent group.    There is an explicit assignment on this screenshot for the Loan Inquiry group to have access to mainPageLoanOfficer.jsp.
Since permissions can have three states (allow, forbid, unassigned \ [inherit\]), then the decision making process to see if someone is allowed to do something is as follows:

1. See if there is an explicit permission for the user/group combo for the resource.
2. If so, done, if not, walk up the hierarchy of parent Set's until you find answer.
3. If not found, then do the same thing for the group in general (not user/group), then the parent group, etc.
4. If no privileges assigned, default is forbid.

That decision making logic is inside the framework in one place (though copied for each app).  It is complex logic, and not something that we would want apps to have to reinvent.
There is an API to ask the framework if the current user has access to a resource:

  if (Authorization.isAllowed(currentUser, FastPropertyType.CUSTOM_DATA, "org123")) {
      ... whatever ...
  }

There are two "lists" (grouper term) for each privilege assignment, for access to the privilege resource, or to be able to admin (assign others) to the privilege resource.  Anyone who has access to the admin screen (which is not a lot of people) can view all permissions (but perhaps not assign).

...