Grafana: [Solicitud de función] Ampliación del modelo de organización para incluir (sub) grupos de usuarios y paneles

Creado en 3 may. 2016 · 3Comentarios · Fuente: grafana/grafana

Fondo

Fuente de datos: InfluxDB, potencialmente PostgreSQL para datos que cambian con poca frecuencia.

Esta solicitud de función es una extensión general de las discusiones que tienen lugar en:

2132, n.o 2777, n.o 1611

Se basa en la publicación slack: Grafana Cloud Hosting Best Practices que creé el 20.04.2016 en el canal grafana en raintank.slack.com .

Para los curiosos:
Para averiguar qué es un sistema híbrido o sin conexión a la red, consulte este documento muy accesible:

Sistemas de energía híbridos basados en energías renovables (fuente: Alliance for Rural Electrification )
El reto

A continuación se muestra un ejemplo de uno de mis casos de uso de Grafana más complejos.

├── 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

Tenga en cuenta que necesito tratar no solo con varias organizaciones, sino con varias organizaciones en unos pocos niveles de profundidad.

Dentro de Off-Grid manufacturer 1 hay 5 grupos diferentes de usuarios, a saber:

• Personal técnico
• Personal financiero
• Inversores
• Público
• Clientes (es decir, empresas de alquiler de plantas; esencialmente una suborganización)

Cada uno de estos grupos tiene necesidades muy diferentes en términos de visualización de datos y sería fantástico poder configurar paneles de control predeterminados aplicables a cada grupo. Algunos grupos, como la gente de tecnología, quiero otorgar acceso completo para crear sus propios paneles y poder graficar cualquier cosa. El grupo público que quiero bloquear por completo, mientras que todos los demás grupos se encuentran en algún lugar entre estos dos extremos. No quiero que los grupos se entrometan o tengan acceso a los paneles de control o las fuentes de datos de los demás.

Off-Grid manufacturer 1 necesita poder acceder a todos los datos de todas las empresas debajo de él, mientras que Plant hire company 1.1 necesita poder acceder a todas las empresas debajo de él pero no poder acceder a los datos de otras plantas de alquiler empresas al mismo nivel que ella o cualquier organización por encima de ella.

Un ejemplo un tanto extremo que conozco, ¡pero esta es mi realidad!

La solicitud de función

Para simplificar el acceso al tablero, sería genial tener grupos de usuarios y grupos de tablero dentro de las organizaciones y poder otorgar derechos de visualización / edición a los tableros para cada usuario o grupo de usuarios. Los subgrupos (o suborganizaciones) con la capacidad de asignar roles de administrador a ciertos usuarios dentro de un grupo en particular, con esos derechos de administrador limitados a ese subgrupo (o suborganización), también serían útiles 😈

Si tuviera que dibujar una sola organización, se vería así:

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

Nota:

El usuario 1 ( u1 ), a través del grupo de usuarios 1 ( ug1 ), solo tiene acceso a los paneles 1 y 2 ( d1 & d2 ).
El usuario 2 ( u2 ) pertenece a ambos grupos de usuarios y, por lo tanto, tiene acceso a los 4 paneles.
Cualquier usuario que pertenezca al grupo de usuarios 2 ( ug2 ) tiene acceso a ambos grupos de paneles y, por lo tanto, también tiene acceso a los 4 paneles.
El usuario 4 ( u4 ) pertenece directamente al grupo de tablero 2 ( dg2 ), no a través de un grupo de usuarios.
El usuario 5 ( u5 ) solo tiene permiso para ver el panel 4 ( d4 ). Hasta donde yo lo entiendo, ¿este es el modelo de permisos actual que existe dentro de las organizaciones?

Una organización con varias suborganizaciones se vería así:

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

Nota:

el subpanel 2 ( sd2 ) pertenece a ambos grupos de subcuadros y, por lo tanto, es accesible para los 4 usuarios.
sub-organisation 1 no tiene acceso a ningún dato perteneciente a sub-organisation 2 ni a ningún dato perteneciente a organisation , excepto los propios.

Escenarios de la vida real

Aquí hay un escenario de uso para pintar una imagen de cómo imagino que esto funcionará en la realidad:

Tengo un cliente, Off-Grid manufacturer 1 , que construye y vende sistemas fuera de la red a empresas de alquiler de plantas, que a su vez los alquilan a empresas de construcción que necesitan electricidad en sus obras (nota: 4 niveles de organización).

Off-Grid manufacturer 1 adquiere un nuevo cliente, Plant hire company 1.2 , que quiere monitorear todos los sistemas fuera de la red que compran desde Off-Grid manufacturer 1 . Plant hire company 1.2 tiene dos clientes, Building companies 1.2.1 & 1.2.2 , que desean administrar sus propios derechos de acceso de usuario.

Off-Grid manufacturer 1 ha creado un conjunto estándar de paneles para cada sistema fuera de la red al que quieren dar acceso a todos sus clientes.

Ejemplo de organizaciones administradoras:

Creo una nueva organización llamada Off-Grid manufacturer 1
Creo un solo usuario dentro de esta organización y le otorgo derechos de administrador.
Ejemplo de administración de grupos:
El usuario administrador de la organización Off-Grid manufacturer 1 crea 2 paneles.
- Tablero 1: muestra cifras financieras sensibles para los contadores
- Tablero 2: muestra el voltaje de la batería para los técnicos
El usuario administrador crea un nuevo grupo llamado "Finanzas" y le otorga acceso al panel 1.
El usuario administrador crea un nuevo grupo llamado "Técnicos" y le otorga acceso al panel 2.
Ejemplo de administración de usuarios:
El usuario administrador de la organización Off-Grid manufacturer 1 crea un nuevo usuario (por ejemplo, finance_user_1 ).
finance_user_1 se agrega al grupo "Finanzas" (tienen acceso inmediato al panel 1)
Administradores de subgrupos / suborganizaciones
El usuario administrador de la organización Off-Grid manufacturer 1 crea un nuevo grupo o suborganización (por ejemplo, hire_company_1.2 ).
El usuario administrador crea un nuevo usuario llamado hire_company_1.2_admin .
hire_company_1.2_admin puede:
- crear nuevos usuarios (que se limitan automáticamente al grupo hire_company_1.2 .
- crear grupos de sub-usuarios
- asignar sub-usuarios a grupos de sub-usuarios
- crear cuadros de mando
- crear grupos de subcuadros
- Asignar paneles a grupos de subcuadros