Background

Datasource: InfluxDB, potentially PostgreSQL for infrequently changing data.

This feature request is a general extension of the discussions happening in:

2132, #2777, #1611

It is based on the slack post: Grafana Cloud Hosting Best Practices which I created on 20.04.2016 in the grafana channel on raintank.slack.com.

For the curious:
To find out what an off-grid or hybrid system is, please check out this very accessible document:

Hybrid power systems based on renewable energies (source: Alliance for Rural Electrification)

The Challenge

Below is an example of one of my most complex Grafana use cases.

├── Off-Grid manufacturer 1
│   └── Technical staff
│   └── Finance staff
│   └── Investors
│   └── Public (i.e. demo dashboards)
│   │
│   └── Plant hire company 1.1
│   │   ├── Finance staff
│   │   ├── Technical staff
│   │   └── Investors
│   │   └── Public (i.e. demo dashboards)
│   │   │
│   │   └── Building company 1.1.1
│   │   │   ├── Technical staff
│   │   │   ├── Finance staff
│   │   │   └── Investors
│   │   │   └── Public (i.e. demo dashboards)
│   │   .
│   │   .
│   │   └── Building company 1.1.n
│   .
│   .
│   └── Plant hire company 1.n
.
.
└── Off-Grid manufacturer n

Note that I need to deal not only with multiple organisations but multiple organisations a few layers deep.

Within Off-Grid manufacturer 1 there are 5 different groups of users namely:

• Technical staff
• Finance staff
• Investors
• Public
• Customers (i.e. plant hire companies; essentially a sub-organisation)

Each of these groups has vastly different needs in terms of data visualisation and it would be fantastic to be able to set up default dashboards applicable to each group. Some groups, like the tech folk, I want to grant full access to create their own dashboards and be able to graph anything. The public group I want to lock down completely while every other group is somewhere in between these two extremes. I don't want groups meddling with, or have access to each other either's dashboards or data sources.

Off-Grid manufacturer 1 needs to be able to access all the data from all companies beneath it, while Plant hire company 1.1 needs to be able to access all companies beneath it but not be able to access the data from other plant hire companies at the same level as itself or any organisations above itself.

A somewhat extreme example I know, but this is my reality!

The Feature Request

To simplify dashboard access, it would be great to have user groups and dashboard groups within organisations and be able to grant viewing/editing rights to dashboards for each user or user group. Sub-groups (or sub-organisations) with the ability to assign admin roles to certain users within a particular group, with those admin rights limited to that sub-group (or sub-organisation), would also come in handy 😈

If you had to draw a single organisation, it'd look something like this:

users     :  u1   u2    u3   u4   u5 |
              \ /    \ /     /   /   |
               |      |     /   /    |
user      :   ug1    ug2   /   /     |
groups    :    |   /  |   /   /      |
               |  /   |  /   /       |>- organisation
               | /    | /   /        |
dashboard :   dg1    dg2   /         |
groups    :    |      |   /          |
              / \    / \ /           |
dashboards:  d1 d2  d3 d4            |
                                   --

Note:

• User 1 (u1), via user group 1 (ug1), only has access to dashboards 1 & 2 (d1& d2).
• User 2 (u2) belongs to both user groups and therefore has access to all 4 dashboards.
• Any user belonging to user group 2 (ug2) has access to both dashboard groups and therefore also has access to all 4 dashboards.
• User 4 (u4) belongs directly to dashboard group 2 (dg2), not via a user group.
• User 5 (u5) only has the permission to view dashboard 4 (d4). As far as I understand it, this is the current permission model in place within organisations?

An organisation with multiple sub-organisations would look something like this:

                                  | sub-users     :  su1 su2  su3 su4
                                  |                    \ /     \ /  
                                  |                     |       |   
             sub-organisation 1 -<| sub-user      :    sug1    sug2 
            /                     | groups        :     |  \    |   
organisation                      |                     |   \   |   
            \                     |                     |    \  |  
     sub-organisation 2           | sub-dashboard :    sdg1    sdg2  
                                  | groups        :     |       |   
                                  |                    / \     /  \  
                                  | sub-dashboards:  sd1   sd2    sd3
                                   --

Note:

• sub-dashboard 2 (sd2) belongs to both sub-dashboard groups and is therefore accessible to all 4 users.
• sub-organisation 1 has no access to any data belonging to sub-organisation 2 or to data belonging to organisation, except it's own.

Real-Life Scenarios

Here is a usage scenario to paint a picture of how I envisage this working in reality:

I have a customer, Off-Grid manufacturer 1, who builds and sells off-grid systems to plant hire companies, who in turn hire them out to building companies who need electricity on their building sites (note: 4 organisation levels).

Off-Grid manufacturer 1 acquires a new customer, Plant hire company 1.2, who want to monitor all the off-grid systems they buy from Off-Grid manufacturer 1. Plant hire company 1.2 has two customers, Building companies 1.2.1 & 1.2.2, who want to manage their own user access rights.

Off-Grid manufacturer 1 has created a standard set of dashboards for each off-grid system which they want to give all their customers access to.

Administering Organisations example:

• I create a new organisation called Off-Grid manufacturer 1

• I create a single user within this organisation and grant them admin rights.

  Administering Groups example:

• The admin user of the Off-Grid manufacturer 1 organisation creates 2 dashboards.

  • Dashboard 1: shows sensitive financial figures for the accountants
  • Dashboard 2: shows battery voltage for the technicians
• The admin user creates a new group called "Finances" and grants it access to dashboard 1.

• The admin user creates a new group called "Technicians" and grants it access to dashboard 2.

  Administering Users example:

• The admin user of the Off-Grid manufacturer 1 organisation creates a new user (e.g. finance_user_1).

• finance_user_1 is added to the "Finances" group (they have immediate access to dashboard 1)

  Sub-group/sub-organisation admins

• The admin user of the Off-Grid manufacturer 1 organisation creates a new group or sub-organisation (e.g. hire_company_1.2).

• The admin user creates a new user called hire_company_1.2_admin.
• hire_company_1.2_admin can:
  
  
  
  • create new users (who are automatically limited to the hire_company_1.2 group.
  
  
  • create sub-user groups
  
  
  • assign sub-users to sub-user groups
  
  
  • create dashboards
  
  
  • create sub-dashboard groups
  
  
  • assign dashboards to sub-dashboard groups