Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-23738

Permissions UI granularity

    XMLWordPrintable

    Details

    • Epic Name:
      Permissions UI granularity

      Description

      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).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              andre.romcke@ez.no André Rømcke
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated: