Permissions in content projects

[alansemenov]

Suggestion for design of storing permissions in content project (see also https://github.com/enonic/xp/issues/7835):

 "branches": [
    "master",
    "draft"
  ],
  "data": {
    "com-enonic-cms": {
      "displayName": "Default",
      "icon": {
      },
      permissions: {
        owner: ["user:system:user1"],
        expert: ["user:system:user2"],
        contributor: ["user:system:user3"],
      }
    }
  }

• Add the following checks in ProjectService (also ProjectResource)
  • create: system.admin OR cms.admin
  • delete: system.admin OR cms.admin
  • modify: system.admin OR cms.admin OR permissions.owner
  • get: system.admin OR cms.admin OR permissions.*
  • list: system.admin OR cms.admin OR cms.cm.app
    • For each project, it is returned if system.admin OR cms.admin OR permissions.*
• Default project should have by default the following data:

  "data": {
  "com-enonic-cms": {
    "displayName": "MyProject",
    "icon": {
    },
    permissions: {
      owner: [],
      expert: ["cms.expert"],
      contributor: ["cms.cm.app"],
    }
  }
  }

[GlennRicaud]

This is layer specific. Please put in appropriate epic

[sigdestad]

Hmm, this is required to complete the project epic

[alansemenov]

@GlennRicaud Glenn, the idea is that when we create a new project, its base layer is created at the same time. so we need to settle on how we will store layers meta data before we release the projects.

[GlennRicaud]

sigdestad > Not necessary, no alansemenov > Good that you think about layers now. But I do not see anything in the project data structure that will create problems for layers and requires to store layers now. Keep it clean and separated please.

Also are you sure about those arrays (Roles, layers)?

But I stop now. I reassigned the backend epic to you Alan. I let you choose

[alansemenov]

Summary after today's discussions:

• roles are renamed to accessLevel
• a Project Admin can only modify project properties (including accessLevel), but not create or delete projects (this will be done by System Admin)
• this is similar to Layer Owner (in the future) who will only be able to modify layer properties, while creating and deleting layers will be done by Project Admins (or, again, System Admin)
• we'll skip the layers part for now (but keeping it here for future reference)

[sigdestad]

Not really happy about all these changes.. Also, its cms.admin that has all rights

[alansemenov]

There was a typo there - Project Admin of course, not Project Owner.

We'll have to write the script that will set cms.admin as admin on the default project, yes.

roles was renamed to accessLevel because roles is confusing (there can be roles, single users etc.), permissions are used in content, access is also not exactly right. do you have a better suggestion? permissionLevel?

[rymsha]

Strictly speaking it is still confusing to call it accessLevel, but at least it is not ambiguous with Roles we already have.

@sigdestad we need some clarification from you: could you please map owner editor expert contributor to actions they are permitted to do.

[alansemenov]

contributor (equal to our current cms.cm.app) has lowest privileges: can log in and work with content, but not create sites or any content in the root, change permissions on the content or access source in HTML editor expert (current cms.expert): same as contributor + can create any content, change permissions and access HTML source owner (current cms.admin, but on the layer level): same as expert + can also modify layer settings

I'm a bit confused about editor though, and where it lies in comparison with contributor and expert.

[sigdestad]

Hmm.. "Expert" cannot change permissions as far as I know? To actually change the permissions user must have "write permissions" permission (I believe).

Maybe it is related to seeing the permissions? Check what is currently implemented on this one. Lets skip "Editor" for now.