Permissions Graphviz

--- Sorry for intruding, but here is another way to show graphs (SteveB) ---

Create a box with "formatted" text. Put the cursor in the box and select "graphviz.dot" from the "transformations" drop down (to the right of the extensions box)

--- Awesome! That's about 100 times easier than a single lump of text. Thanks! (anbrcyp) ---

Main Idea

By separating inherited and local permissions, you can create an implication that any permission defined as inheritable should always cascade. This means that permissions must be managed a little more aggressively.

Cascade should occur anytime a change effects inheritance.

To prevent auto-cascades from killing intentional changes deeper in a branch, inheritance denial should be permitted on a per page basis. Once a denial is set, it will prevent that particular grant from cascading through that page or effecting the local permissions of that page.

Fringe cases?
- Intended cascade doesn't match the intended denial? Not certain how to handle. Allowing many/granular denials essentially creates the negative-grant case, which I think is more confusing than useful in practice.
- Denials and grants only exist as a single entity per page? Since grants are additive, there should be only one entry per control element per page for a particular user/group. Denials should simply toggle inheritance on/off and be targeted by user/group name?
  - How does single entity work with complex grants. Example: user1 should be allowed to edit until 12/31/2008, but remain as viewer/commenter indefinitely. Maybe grant enhancements and conditions are applied to each flag, instead of the grant as a whole?
  - Lowering a user's permission level requires denying inheritance, then building completely new grant set? Does that make sense?

General Usage

General map of how a page figures out its grants. All data elements are actually local to that page (don't see any point to recursively evaluating back to the root node). Parent inheritance data is created when the page is created, and updated during a cascade event, so a page should be up-to-date if inheritance cascades every time it changes.

On Page Create

Creating a page still works pretty much like it did before. The parent determines the result.

On Page Move

Idea is that a page move will always trigger a recalculation of page and inheritance grants (and cascade if needed). This is because the incoming parent grants need to be updated. The move should effect the result for the end user, but not remove anything an admin may have added... even if they no longer apply. Green shows where a change is possible. Other data should remain the same to prevent controls from being modified by a page move even if it no longer has an effect.

Example: There may be an inheritance denial which is no longer applicable under the new parent, but removing it could potentially let people get around restrictions by moving pages.

On Page Delete/Restore

When a page is deleted, if a placeholder is required it should have the exact same permission data as the deleted page. It should also be able to function like a regular page for setting access and cascading grants. If the page is recreated or restored, it should automatically be given the original grants if no placeholder is present or use placeholder grants to maintain current permissions instead of possible regression (maybe query admin?).