Permissions for UI availability

Problem

One can restrict (action) availability based on user roles, but not based on user permissions at given workspace / path.

Concrete case

As of Magnolia 5.2.1, actions are not disabled if user has no permission to act on selected node. This is an issue with e.g. read-only pages, as captured by the following Jira ticket:

MGNLUI-2510 - Getting issue details... STATUS

Current configuration

Let's take the deactivation action as an example, with following base path /modules/pages/apps/pages/subApps/browser/actions.

• actions
  
  • deactivate ( ActionDefinition )
    
    • availability ( AvailabilityDefinition )
      
      • access (
        $webResourceManager.requireResource("info.magnolia.sys.confluence.artifact-info-plugin:javadoc-resource-macro-resources") AccessDefinition
         )
        
        • roles
          
          • demo-publisher = demo-project-publisher
          • superuser = superuser
      • ruleClass = info.magnolia.ui.api.availability.IsNotDeletedRule ( AvailabilityRule )
    • class = info.magnolia.ui.framework.action.DeactivationActionDefinition
    • ...

As a side note, the AccessDefinition property is named access in the case of actions but it is generally named permissions, as in AppDescriptor or AppLauncherGroupDefinition.
This has been reported to be misleading, in particular in documentation, and should be inlined whenever is appropriate.

Options

• Add a requiredPermissions property under AvailabilityDefinition or AccessDefinition
  
  • comma separated list of JCR permissions (aka action strings)
    
    • add_node, set_property, remove, read
    • we should rather use Magnolia permissions
    •  doesn't fit for upcoming custom permissions
  • naming is debatable (permissions > requiredPermissions)
• Add a writePermissionRequired boolean property under AvailabilityDefinition or AccessDefinition
  
  • simply checks for Magnolia WRITE permission
  •  which entry point? cannot use PermissionUtil
  • for custom permissions, people will need to implement AvailabilityRule

Forward thinking

• Availability / AccessDefinition is a broad concept meant to be reused across several UI components (e.g. fields, tabs, templates).
• Can one configure custom permissions for an action? e.g. forum moderator can only perform moderation at specific path
• Can one plug basic permission rules for non-JCR datasources (no ACLs)?
• ActionExecutor is probably not where availability / permission checks belong.

Decisions

• Validate API
  • requiredPermissions (String) under AvailabilityDefinition
  • semantically redundant with access (AccessDefinition)
  • for 5.2.2 / 5.2.x VS. 5.3
• Problem with the add_node permission X subnodes-only ACLs
  • with /A readonly and /A/B/* read-write, add_node is not granted on /A/B
  • JCR spec is a bit unclear as to what absPath means in that case
    • adding a node at absPath VS. adding a node under absPath
  • tested adding /* whenever checking for add permissions
    • couldn't find any incorrect permission assertion
  • otoh, 4.5 was wrong as well in similar subnodes-only permissions
  •  We don't check for add-specific permissions
• Currently hooking in AbstractActionExecutor#isAvailableForItem
  • added #hasPermissionsOnItem
  •  item is null when root is selected, no way to assess permissions then
  • #isAvailable() is (the sole) JCR Item dependent api in ActionExecutor interface and doesn't belong here
  •  Not for 5.2.x either anyway
    
• Plans for the long run