Administration d'une organisation

Organisation

Une organisation est le nom donné à un compte client sur Serenytics, qui regroupe tous vos utilisateurs et vos objets (Datasources, Dashboards et Automations).

Utilisateurs

Il y a 4 types d'utilisateurs dans Serenytics :

• Viewer

  Un Viewer ne peut que consulter des dashboards dans l'application Viewer de Serenytics (avec l'URL https://app.serenytics.com/viewer. Il ne peut pas créer ni éditer de dashboards.

• Business Analyst

  Un business analyst a les droits d'un Viewer. En plus, il peut aussi créer et éditer des dashboards. Il ne peut pas créer des nouvelles sources de données, ni accéder aux automations. Généralement, un Business Analyst est une personne non spécialiste de la data (e.g. marketing, finance) à qui on a préparé des sources de données. Le business analyst peut alors simplement créer ses propres analyses et les partager à d'autres personnes.

• Studio

  Un utilisateur Studio a tous les droits dans le studio Serenytics (URL https://app.serenytics.com/studio) sauf les droits d'administration. Il peut créer/éditer des sources de données, des dashboards et des automations. Mais il n'a pas accès au menu d'admninistration.

• Admin

  Un utilisateur Admin a tous les droits (les droits de l'utilisateur Studio + les droits d'administration). Dans le menu administration, il peut gérer les utilisateurs et leurs permissions.

Groupes

Les groupes d'utilisateurs vous permettent de partager un dashboard à une liste d'utilisateurs (en mode Viewer, i.e. pour faire apparaitre un dashboard dans l'application Viewer d'un utilisateur). Cela simplifie la gestion de ces partages, notamment à l'arrivée et au départ d'un membre dans une équipe.

Voir la section Partages Viewer pour savoir comment partager un dashboard à un groupe. Les groupes ne servent qu'à partager les dashboards dans l'application Viewer. Pour partager des objets (datasources, dashboards et automations) à d'autres utilisateurs Studio, il faut utiliser les permissions sur les répertoires (voir ci-dessous).

Permissions Studio

Dans le studio Serenytics, les droits sur les 3 types d'objets (DataSources, Dashboards et Automations) sont gérés par répertoire. Par exemple, un utilisateur studio peut avoir un droit d'accès en édition sur un répertoire de DataSources "Sources en production". Cela signifie qu'il pourra ouvrir et éditer toutes les Datasources de ce répertoire.

Les permissions ne sont modifiables que par un utilisateur de type Admin. Un Admin peut se donner tous les droits qu'il souhaite sur tous les répertoires de son organisation. Pour ne pas surcharger son interface, par défaut, quand un autre utilisateur de l'organisation crée un répertoire, un admin ne le verra pas dans ses répertoires d'objets. Mais s'il se donne des droits dessus, alors il le verra.

Warning

Dans Serenytics, les droits de visualisation d'un dashboard en lecture seule (dans l'application Viewer) sont gérés par dashboard. Les permissions expliquées dans ce paragraphe concernent les droits d'accès aux objets dans le Studio. La documentation sur le partage de dashboards en consultation est disponible ici : Partage de dashboards

Note

Dans Serenytics, un objet n'appartient pas à un utilisateur. Il appartient à un répertoire de l'organisation, et ce répertoire est accessible ou non par certains utilisateurs. Par défaut, quand un utilisateur crée un nouveau répertoire, il a le droit le plus fort sur ce répertoire.

Permissions sur les répertoires de Datasources

• Permission Can use in dashboards

  Si un utilisateur a ce droit sur un répertoire de Datasources, il aura accès aux sources de données de ce répertoire quand il éditera un dashboard. Il pourra rajouter des widgets dans le dashboard qui interroge cette source de données. Ce droit ne permet pas de modifier la configuration, ni les formules d'une source de données. Ce droit petmet par exemple de partager des datasources à des Business Analyst et d'être sûr qu'ils ne modifient pas la source de données.

• Permission Can edit formulas

  Si un utilisateur a ce droit sur un répertoire de Datasources, il pourra modifier les formules des sources de ce répertoire. Ce droit ne permet pas de modifier la configuration d'une source de données. Ce droit est utilisé pour permettte à d'autres utilisateurs Business Analyst ou Studio de modifier les formules d'une source existantes.

• Permission Can edit config and delete

  Si un utilisateur a ce droit sur un répertoire de Datasources, il peut effectuer toutes les modifications sur les sources de ce répertoire.

Permissions sur les répertoires de Dashboards

• Permission Can view and edit

  Si un utilisateur a ce droit sur un répertoire, il peut ouvrir et éditer ses dashboards dans le studio. Mais il ne peut pas supprimer les dashboards de ce répertoire.

• Permission Can delete

  Si un utilisateur a ce droit, il peut supprimer les dashboards de ce répertoire.

Partage d'un dashboard en mode Viewer

Pour partager un dashboard à un utilisateur en consultation (i.e. dans l'application Viewer), il ne faut pas utiliser ces permissions, mais éditer les options de partage du dashboard (voir Partage de dashboards).

Edition d'un dashboard sans permission sur ses sources

Il est possible d'avoir les permissions d'édition d'un dashboard, mais que l'une de ses sources soient dans un répertoire qui ne vous est pas partagé. Dans ce cas, le dashboard refusera de s'ouvrir et la liste des répertoires sur lesquels une permission est nécessaire est affichée.

Permissions sur les répertoires d'Automations

• Permission Can edit, run, delete

  Si un utilisateur a ce droit sur un répertoire d'automations, il a tous les droits sur ses automations.

Le cas particulier du répertoire Home

Pour chaque type d'objet (Datasources, Dashboards, Automations), un utilisateur Studio a un répertoire Home (ce qui fait 3 répertoires Home par utilisateur Studio). Un répertoire Home est un répertoire particulier car il n'est pas partageable. Il n'est utilisable que par l'utilisateur en question et sert de "bac à sable" pour faire des tests.

Cycle de vie des objets

Nous présentons ici ce qu'il advient lorsqu'un objet est supprimé.

Suppression d'un utilisateur Viewer

Pour tous les dashboards qui étaient partagés en lecture à cet utilisateur, cet utilisateur est supprimé de la liste des utilisateurs autorisés à lire ce dashboard dans l'application Viewer.

Suppression d'un utilisateur Studio/Business Analyst/Admin

Pour tous les dashboards qui étaient partagés en lecture à cet utilisateur, cet utilisateur est supprimé de la liste des utilisateurs autorisés à lire ce dashboard dans l'application Viewer.

Toutes les permissions de cet utilisateur sont supprimées. Seules les permissions sont supprimées, les répertoires et leurs objets existent toujours.

Si cet utilisateur était marqué en run-as-user pour certaines automations, ce champ run-as-user devient non-défini. Voir Le champ Run-as-user pour les automations pour avoir plus de détails sur ce champ.

Répertoire orphelin

Si cet utilisateur était le seul a avoir un droit sur un répertoire, en supprimant cet utilisateur, vous créez un répertoire orphelin. C'est à dire un répertoire qui existe, avec des objets, mais sur lequel personne n'a de permission. Cette situation est visible très simplement par un utilisateur Admin qui verra dans les permissions ce répertoire, sans aucune permission attribuée.

Les répertoires Home d'un utilisateur supprimé

Lorsqu'un utilisateur (e.g. John.Doe@serenytics.com) est supprimé, ses répertoires Home (qui étaient jusque là utilisables par lui seul), sont renommés en Old home folder for deleted user LOGIN (e.g. Old home folder for deleted user John.Doe@serenytics.com). Ce sont maintent des répertoires classiques. C'est à dire qu'un utilisateur Admin peut maintenant les partager (à lui ou à quelqu'un d'autre). En général, après la suppression d'un utilisateur Studio, la première étape pour l'admin est de se partager ses répertoires Home et d'aller voir leur contenu pour décider s'il faut les conserver ou pas. Pour un utilisateur Studio ou Admin, cela représente 3 répertoires (pour les 3 objets DataSource, Dashboards et Automations). Pour un utilisateur Business Analyst, il n'y a que le répertoire de Dashboards. Attention, il peut être nécessaire de rafraichir l'application dans votre navigateur pour visualiser ces répertoires renommés.

Suppression d'un répertoire de Datasource (ou de Dashboards, ou d'Automation)

Un répertoire n'est supprimable que lorsqu'il est vide. S'il contient des objets, vous devez d'abord supprimer ces objets avant de supprimer le répertoire.

Lorsque vous supprimez un répertoire, il disparaitra de la liste des répertoires pour les autres utilisateurs qui avaient des droits sur ce répertoire.

Suppression d'une DataSource

Une Datasource ne peut être supprimée que si elle n'est pas utilisée (ni dans aucune source de type Join, ni dans aucun dashboard, ni dans aucune Automation (hors script Python, voir encadré ci-dessous)).

Suppression d'une Datasource utilisée dans un script Python

Une source de données peut être utilisée (en input ou output) dans un script Python. Dans ce cas, l'application Serenytics vérifie si l'uuid de cette source apparait dans le code Python du script. Si c'est le cas, un message indiquera que cette source de données ne peut pas être supprimée. Mais si vous accédez à cette source de données dans le code Python en utilisant son nom au lieu de son uuid (pratique déconseillée), la source de données ne sait pas qu'elle est utilisée dans ce script, et la suppression sera acceptée.

Suppression d'un Dashboard

Si un dashboard est supprimé, les utilisateurs qui pouvaient consulter ce dashboard dans le Viewer ne le verront plus.

Suppression d'une Automation

Une Automation ne peut pas être supprimée si elle est appelée par une Chain Task.

Suppression d'une formule d'une Datasource

Si une formule est utilisée dans une autre formule de la source, sa suppression sera refusée. Si une formule est utilisée dans un dashboard, sa suppression sera refusée. Si une formule est utilisée comme clé dans une jointure, sa suppression sera refusée. Si l'uuid d'une formule apparait dans le code d'un script Python, la suppression sera refusée.

Sinon (i.e. si cette formule n'est pas utilisée), alors la suppression sera autorisée.