UserRoles

Configuration des droits utilisateurs

Descriptions des rôles utilisateurs ainsi que l’aide à la configuration de ceux-ci.

Tout utilisateur de la plateforme se doit d’avoir un groupe de permission. Ce groupe permettra donc de savoir les droits qu’il détient sur la plateforme, que ça soit en lecture ou écriture. Il est essentiel de rappeler en dehors de l’invitation des guests, de la gestion des facilitys ou des admins le portal n’est pas fait pour les utilisateurs.

Par défaut, il existe 11 Permission Groups.

Groupe de permission#

SUPER ADMIN : Ce groupe de permission est destiné au personnel de Creativeone, il offre l’intégralité des rôles possible sur la plateforme. Ce rôle permet également de créer de nouvaux tenants .

ADMIN : Groupe de permission destiné au personnel administratif du tenant. Il s’agit de la ou des personnes qui autont accès en intégralité au portal. Cette personne gèrera tout le portal allant de la création d’utilisateurs, gestion des salles, des réservatations ainsi que la facturation. En dehors de la création des GUESTS, il s’agit des seules personnes qui ont accès au portal.

COMPANY ADMIN : Groupe de permission destiné aux administrateurs des entreprises présente dans la plateforme. Ces personnes-ci n’ont pas accès aux portal. Toutes les interactions se font via la client meeting. Ce groupe de personne permet de gérer les crédits, les informations de son entreprise, les réservations ainsi que son personnel.

USER : Groupe de permission destiné aux simples utilisateurs. La majorité des utilisateurs auront ce groupe de permission. Celui-ci permet d’inviter des guests sur le portal (Seule fonctionnalité accessible sur le portal) et de réserver des salles de réunions sur le client meeting.

FACILITY USER : Groupe de permission un peu particulier, celui-ci offre l’accès au portal pour le le master-data (en lecture) ainsi que l’onglet Facility (lecture/modification). Ce rôle est destiné aux utilisateurs qui ont besoin de cette section.

PENDING VALIDATION : Groupe de permission qui n’est pas destiné à être assigné à un utilisateur. Dans certain client, l’inscription d’un utilisateur nécéssite un validation de l’admin. En attente de la validation, il possède ce groupe qui une fois valider deviedra “USER”.

DEVICE : Groupe de permission destiné aux appareils Myc1. Pour avoir accès aux informations, les appareils ont besoin de certains droit, il s’autentifie donc sur le serveur avec ce groupe de permission. (UNIQUEMENT pour les appareils, pas fait pour les utilisateurs)

GUARD : Groupe de permission destiné aux gardes d’un bâtiment. Ce groupe offre la possibilité d’avoir accès à la liste des invités de la journées ainsi qu’aux réunions en lecture.

CREDIT DEBTOR : A compléter, je ne sais pas à quoi ça correspond

COMPANY POOL ADMIN : Groupe de permission assigné aux personnes qui font parties de plusieurs entreprises. Pour à éviter qu’ils se connecte avec l’addresse de chacune de ses entreprises pour effectuer différentes réservations, ce groupe permet que l’utilisateur se connecte avec le compte qui a ce droit et ainsi réserver pour ses multiples entreprises.

ANONYMOUS : Groupe de permission fait pour l’accès en lecture sur les différents clients (Meeting, Meeting-light, Vision) lorsque personne n’est authentifié.

Editer groupe de permission#

Les groupes de permissions sont configurer par défaut via certains critères de sécurités que nous avons nous même décider. Il n’est pas forcément conseiller de les modifier. Cependant, si besoin, il est tout de même possible de le faire. Il est également possible d’en créer des nouveaux si un type d’utilisateur n’existe pas encore.

La configuration de ces groupes de permission est divisé en 6 sections :

Permission Templates : Liste qui permet de définir quels seront les sections affichées dans le menu de gauche. L’idéal est de ne laisser afficher que les sections dont l’utilisateur aura besoin.

Global : Il s’agit du rôle global qu’un utilisateur aura droit dans l’application. Il faut le mettre par défaut comme “Role user” excepté ci celui-ci est destiné à être admin de la plateforme. Le role Prospect étant destiné aux utilisateurs en attente de validation.

Role Master data, membership, GuestOne, Meeting One, VisioOne et invoicing : Permet de définir les accès en lectures ou en écritures pour les différents services. Nos services ont des informations qui se croisent et il n’est pas toujours évident de savoir quelles sont les informations dont on a besoin. N’hésitez pas à contacter le service technique ou dev pour vous éguiller.

Template de groupe de permission#

Les templates de groupes de permission sont génér& automatiquement à partir de la configuration des groupes de permission. En effet, pout chaque menu sélectionné dans un groupe de permission (section Permission templates), un template de groupe de permission sera créer.

Configuration des templates de groupes de permissions#

La configuration des templates de groupes de permissions ne gère que l’affichage des sous menu de chacune des sections du menu de gauche. Prenons l’exmple de Master data qui possède 15 sous menu. Un utilisateur n’a pas forcément besoin d’avoir accès à tous ces sous-menu. Il est alors possible de lui en masquer certains. La confguration du sous-menu apparait sous forme d’un JSON clé-valeurs (Valeur étant un booléen true pour afficher et false pour masquer).

{
    "key": "MENU_MASTER_DATA",
    "buildings": false,
    "locations": false,
    "devices": false,
    "components": true,
    "companies_pools": true,
    "companies": true,
    "pools_of_persons": true,
    "user_profiles": true,
    "welcome_email": true,
    "times_profiles": true,
    "actions_sets": true,
    "web_clients": true,
    "setting_configurations": true,
    "users_rights": true,
    "search": true
}

Dans l’exemple ci dessus, on peut voir que l’on choisi de masquer les sous menus les bâtiments, emplacements ainsi que les appareils du menu master data, tandis que les autres seront afficher.

Notes aux développeurs#

Lorsque l’on rajoute une section ainsi que des sous menus, il est important de respecter une certaine syntaxe et procédure afin que la personnalistion de ces menus restent fonctionnelles.

<li *jhiHasAnyTemplates="['MENU_ACCESS_ONE']" routerLinkActive="active" #hasSub class="has-sub">
    <a>
        AccessOne <i class="fas fa-caret-right"></i>
    </a>
    <ul class="nav flex-column">

        <li routerLinkActive="active" *jhiHasAnySubMenu="{key : 'MENU_ACCESS_ONE', value:'accesses_type'}">
            <a [routerLink]="['/access-one', { outlets: {'access-one': ['access-type']}}]">
                {{ 'portalApp.accessType.home.title' | translate }}
            </a>
        </li>
        <li routerLinkActive="active" *jhiHasAnySubMenu="{key : 'MENU_ACCESS_ONE', value:'accesses_list'}">
            <a [routerLink]="['/access-one', { outlets: {'access-one': ['access-list']}}]">
                {{ 'portalApp.accessList.home.title' | translate }}
            </a>
        </li>
        <li routerLinkActive="active" *jhiHasAnySubMenu="{key : 'MENU_ACCESS_ONE', value:'accesses_list'}">
            <a [routerLink]="['/access-one', { outlets: {'access-one': ['presence-access-list']}}]">
                Presence access list
            </a>
        </li>


    </ul>
</li>

jhiHasAnyTemplates : Ce tag est nécéssaire afin de vérifier si la section est disponible dans le groupe de permission de l’utilisateur. La liste des valeurs possibles est notamment disponible : ici

jhiHasAnySubMenu : Ce tague demande un objet au format JSON. Ces tags font référence aux templates de groupes de permissions.“Key” : fait référence au menu (section) et la “value” fait référence au sous menu. La liste des valeurs possibles est disponible ici

Lors de la création de nouvelles section ou sous menu, il faut absolument maintenir ces deux fichiers à JOUR !!!