Page History

...

• 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  For 5.2.x we add a writePermissionRequired boolean property under AvailabilityDefinition or AccessDefinition
  
  • simply checks for Magnolia Permission.WRITE permission
  • we add this to the availability evaluation sequence
    
    • as of 5.2.2 this is in AbstractActionExecutor (action availability) and in BrowserSubApp (section availability)
    • use PermissionUtil when processing
     which entry point? cannot use PermissionUtil
  • for custom permissions, people will need to implement AvailabilityRule
  •  After another round of reviews, we ultimately decided against using voters for availability
    
    • We found important to instantiate whatever criteria (voters or rules) on subapp scope
    • In order to make it possible to inject components in these rules - which are then also resolved on subapp scope
      
      • as opposed to voters which are instantiated by n2b on global webapp startup
      • similarly as we have now ruleClass configured in ActionAvailability, which is instantiated on the fly by subapp's componentProvider.
    • We did not want to revise voters or introduce voter definitions at this time
    • We also chose the flag approach for 5.2.x so that we don't introduce any new mechanism and leave the door open to finalize the proposal for 5.3.
•  For 5.3 we now aim at improving use and flexibility of the AvailabilityRules.
  
  • by configuring a collection of such rules in AvailabilityDefinition, instead of one single ruleClass, so that we can compose multiple rules
  • by introducing an AvailabilityRuleDefinition to make these rules configurable
  • yet to be decided
•  We unify availability's access, ruleClass and other criteria using voters, in a future major version
  
  • supports custom permissions (forum), even non-JCR based, using dedicated voters
  •  Do we keep availability's "shorthands"?
    
    • nodeTypes, root, properties...
    • yet update underlying implementation to work with voters
      
    • Proposal: how about maintaining all the shorthands we have and also providing a rather smooth mechanism of moving from old impl to the new one by implementing a custom Node2BeanTransformerImpl
      that would build voters based on the properties from AvailabilityDefinition (e.g. once the property name is nodes - we generate a corresponding voter)?
•  For 5.2.x, we introduce a delegating AvailabilityRule which helps us already start working with voters
  

  • getting well prepared for migrating to the next approach

...

• Currently hooking in AbstractActionExecutor#isAvailableForItem
•  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
•  We keep this as a separate topic, not for 5.2.x anyway
  • We may cover that for 5.3 (by e.g. having a single AvailabilityChecker component).

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.

...