Community
OpenEnergyMonitor

Community

User capabilities module for multi-user setups

Tags: #<Tag:0x00007f6e036e0820>

I just thought I’d post here about some work I’ve been doing at the Carbon Coop for our multi-user EmonCMS installation. We’ve been installing smart meters across many different physical locations as part of the EU Nobel Grid project, and while administrating that I thought that it would be useful to be able to grant or deny access to different bits of functionality for different users.

Enter the user capabilities module:

It provides a framework for fine-grained access control on a multi-user EmonCMS setup. The list above is from my test system, showing the capabilities from the capabilities module as well as those from a (modified) group module.

A capability is just the ability to do something. You can see on the editor screen that there are different pieces of functionality you can enable or disable for different roles. Users are then assigned to one or more of those roles. It’s a common way to manage permissions on online systems - for example, both WordPress and Amazon Web Services use a model resembling this.

Here’s a slightly chaotic(!) collage showing how it works. On the right is the admin user who is editing the permissions for the group ‘Groups admin’. User ‘catsmith’ is in this role. On the right, ‘catsmith’ is logged in and using the group module. The top pair of screenshots shows what things look like for her when the ‘create groups’ capability is turned off for that group, and the bottom pair show what it looks like when it’s turned on:

That is, turning on the capability lets her create new groups. Pretty basic really, but it’s flexible enough that you can grant people the ability to do just the things you want them to be able to.

Setting up this kind of permissioning in a module is pretty straightforward - I can write a bit more about this if anyone is interested, or you can just take a look at the capabilities branch of the group module.

So, I’m mostly posting here to see if anyone else is interested in this kind of functionality. It is already pretty much working for our purposes at Carbon Coop but if there is wider interest then I am happy to work on it further and alter it for different use cases. Any takers? :slight_smile:

2 Likes

Wow! Thankyou for sharing @anna_carboncoop, this looks really great!

I agree :wink: this looks great!

Do you by any chance plan further steps in this direction? For example user permissions for modules in general. I am a big fan of this module and am looking forward to test this on our servers… and hopefully take a look into helping with the further development as well, hence my interest in your future plans with it.
e.g. I could imagine great usage of account dependant permissions for modules in general like

  • Feeds:
    • [x] read
    • [ ] write
  • Inputs:
    • [ ] read
    • [ ] write

Where the input module could be completely hidden and only feeds shared by groups could be viewed. I know this would not be trivial but I am thinking about this for a while now and maybe you did as well? :slight_smile:

Hi Adminde. I have been meaning to reply for some time! We’re actually not using EmonCMS so much at the moment in Carbon Coop so progress here has stalled, but I thought I should note that there there is someone working on it again in an issue on the github repo who has also submitted a pull request to emoncms.

There has been a request a bit like this in Help to change default user interface to limit access to certain things on a per user basis.

Hi @anna_carboncoop ,

do you know if this module will work with Emoncms Version: 10.2.3 ? You installation notes refer to the settings.php but these are now in settings.ini and in a different format?

This looks to be a great module and I would love to use it if possible.

Andrew

The actual settings are the same, just the format has changed from a PHP file to an ini.

The settings may be the same for the standard Emoncms features, however, I don’t see any references as to how to set PHP constants?

const CAPABILITIES_ALWAYS_SUPERUSER = ;

So what would the format be?

I don’t know if it’ll work, and I don’t know how that fits in the new scheme. It also won’t do much unless you use the groups module from the specially-adapted branch, which I believe is now out of date.