Use case: Toggle UI elements depending on user permissions.

This is an epic as it touches many areas of the system, what is needed is

• PHP Repository API possibility to do reverse lookup on permissions
• Extend REST to add permissions info in response, this should vary by user hash
• Expose/use this info in REST client(s)
• Use this info in UI to toggle buttons / actions

Design:

Per content item, return hash of content policies accessible within current user rights (hash/context):

• true (full access)
• false (no access)
• hash (some policies gives access under current limitations on UI choices):
  • "owner" (Access if current user is owner): either "item" or "parent"
  • "types" (List of classes, only applicable to content/create like policies where current context is parent)
  • "sections" (List of sections, only applicable to content/create like policies where current context is parent Is this valid? Or should be be evaluated by parent?)
  • "languages" (List of languages, applicable in all cases)

Simplified editor example on folder items:

'permissions': {
   'create': {'sections': [1, 2, ...], 'types': ['article', ...]},
   'edit': true,
   'read': true,
   'remove': true,
   'versionread': true,
   ...
}

If this was full example it would mean user here is missing

Owner

While [Parent]Group limitations can safely be evaluate and cached, Parent[Owner] can not, and is thus returned for UI / Client to verify this.
While we could handle this in API if we could vary cache per user, that might not be very efficient when combined with rest embedding for everything (very low cache hit ratio).