Cockpit: Example configuration / granular user permissions

Created on 20 Feb 2018 · 7Comments · Source: agentejo/cockpit

Hello!
Cockpit looks like a promising tool for a new project, but I'm having trouble figuring out how to set it up correctly for my use case. Is there any example configuration (config.yml?) available or is there any place where I can look up all possibilities? I wasn't able to find something appropriate.

To make it more clear: At the moment I'm mostly interested if it's possible to limit the viewing capabilities of users based on groups. What I basically need is:
(* one admin able to see everything/configure the system)

a bunch of editors who should be able to create/edit new items, but should not be able to see the content of other editors
a manager which is able to create/edit/delete all items in the systems, so also all items of every editor.

Is a configuration like that possible?

Thanks already for your help!

Source

ca057

Most helpful comment

You can do it in the config.yaml, but I recommend the addon cockpit_GROUPS, it adds a graphical interface to set up user types and permissions.

EDIT:: Otherwise in your yaml it should look like this:

groups:
  contenteditor:
    $admin: false
    cockpit:
      backend: true
      accounts: true
      finder: true
      rest: true
      info: true
    collections:
      create: false
      delete: false
      manage: true

For permissions to specific collections there is a tab in the configuration of the collection to set which group is allowed to do what.

Blemming on 20 Feb 2018

👍3

All 7 comments

You can do it in the config.yaml, but I recommend the addon cockpit_GROUPS, it adds a graphical interface to set up user types and permissions.

EDIT:: Otherwise in your yaml it should look like this:

groups:
  contenteditor:
    $admin: false
    cockpit:
      backend: true
      accounts: true
      finder: true
      rest: true
      info: true
    collections:
      create: false
      delete: false
      manage: true

For permissions to specific collections there is a tab in the configuration of the collection to set which group is allowed to do what.

Blemming on 20 Feb 2018

👍3

Thanks @Blemming, I will give that a try tomorrow!

ca057 on 20 Feb 2018

I think what you're looking for are the "programmatic" access rules you can do in the collections settings:

so what I'm doing here is extending any read query going against the post collection. in that special case I check whether we have a logged in user and if yes I extend the query by adding my additional query condition.

So, if a user isn't in the admin group he'll always only get items he created.

this way you can build your very own access scenarios.

aheinze on 20 Feb 2018

Not sure why try I follow the same code snippet as the above but after clicking save, the read query become disabled again the the toggle switch turned "red". Appreciate any sharing with similar experiences.

Many thanks.
Jon