Équipe, rôles et espaces de travail
Qui peut se connecter au tableau de bord organisateur, les quatre rôles d'exemple, chaque permission que l'API vérifie, les espaces de travail entre lesquels un membre bascule, et comment donner à chaque membre exactement ce dont il a besoin.
Pour le pack Full Stack
Comment fonctionne l'accès
- L'équipe se connecte au tableau de bord. Les participants ont leurs propres comptes sur le site et ne se connectent jamais au tableau de bord.
- Un membre détient un rôle, et un rôle est un ensemble de permissions nommées
<area>.<action>, commeevents.publish. Le rôle est le même dans chaque espace de travail auquel le membre appartient. - L'API vérifie une permission sur chaque route du tableau de bord, quoi que l'écran affiche. Le tableau de bord masque les éléments de la barre latérale, onglets et boutons qu'un rôle n'inclut pas, et une page ouverte par son adresse indique « This page is not part of your role ».
- Un changement du rôle d'un membre, ou des permissions d'un rôle, l'atteint pendant qu'il est connecté.
- Chaque membre arrive sur la première page que son rôle ouvre : la vue d'ensemble pour la plupart, la page de contrôle des billets pour le rôle Contrôle des billets.
Les rôles d'exemple
| Rôle | Permissions | Barre latérale |
|---|---|---|
| Propriétaire | Les 29 | Vue d'ensemble, Événements, Commandes, Contrôle des billets, Lieux, Rapports, Équipe, Assistant IA, Studio de lieux et Paramètres |
| Manager | overview.view, events.view, events.edit, events.publish, venues.view, venues.edit, orders.view, checkin.scan, reports.view, reports.export, leads.view, leads.edit, studio.use, ai_chat.use, ai_chat.view_models : événements, lieux, contrôle des billets, rapports, demandes, le studio et l'assistant, avec les commandes en lecture seule ; ni remboursements, ni équipe, ni rôles, ni paramètres | Tout sauf Équipe et Paramètres |
| Finance | overview.view, orders.view, refunds.create, tickets.manage, reports.view, reports.export | Vue d'ensemble, Commandes et Rapports |
| Contrôle des billets | checkin.scan, pour les sessions qui lui sont attribuées uniquement | Contrôle des billets |
Les données d'exemple créent un compte par rôle, une équipe de dix autres membres, et le compte participant sur le site. Elles remettent les quatre rôles exactement à ces listes à chaque exécution : un changement que vous avez fait à l'un d'eux sur la page Rôles est donc annulé par le yarn seed suivant ; les rôles que vous avez créés vous-même sont laissés tels quels, et un mot de passe existant n'est jamais réinitialisé. Changez chaque mot de passe, ou supprimez les comptes d'exemple, avant que le tableau de bord soit accessible depuis Internet. Le guide d'installation liste les identifiants de connexion.
Toutes les permissions
| Domaine | Permissions |
|---|---|
| Vue d'ensemble | overview.view |
| Événements | events.view, events.edit, events.publish |
| Lieux et plans de salle | venues.view, venues.edit |
| Commandes, remboursements et billets | orders.view, refunds.create, tickets.manage |
| Contrôle des billets | checkin.scan |
| Rapports | reports.view, reports.export |
| Demandes | leads.view, leads.edit |
| Studio de lieux | studio.use |
| Équipe | admins.view, admins.create, admins.edit, admins.delete, admins.assign_roles |
| Rôles | roles.view, roles.create, roles.edit, roles.delete, roles.assign_permissions |
| Paramètres de l'espace de travail | settings.view, settings.edit |
| Assistant IA | ai_chat.use, ai_chat.view_models |
events.publishcouvre la publication, la dépublication, l'annulation et l'archivage d'un événement ;events.editla création, la modification et la duplication.tickets.manageréémet le code QR d'un billet ou annule un billet ;refunds.createrembourse des billets via le fournisseur de paiement.admins.editattribue aussi des membres aux sessions de contrôle des billets.
La liste est définie une seule fois, dans back-end/src/database/seeders/permission.seeder.ts ; le seed ajoute les nouveaux noms et retire ceux que l'API ne vérifie plus.
Espaces de travail
Un espace de travail est un organisateur : ses événements, lieux, commandes, entrée, rapports, équipe et paramètres. Les données d'exemple en créent quatre (Northline Events, Kiln & Co., Mill Street Talks et Meadow Days), et le site liste les événements publiés de tous.
- Le menu Workspace au début de la barre du haut du tableau de bord liste les espaces de travail auxquels le membre appartient, les siens en premier. Le propriétaire d'exemple appartient aux quatre ; les autres comptes d'exemple à deux ou trois.
- En choisir un recharge chaque page pour cet espace de travail. Une page d'enregistrement (une commande, un événement, un lieu) revient à sa liste, puisque l'enregistrement appartient à l'autre espace de travail.
- Chaque requête porte le choix dans l'en-tête
X-Workspace-Id, et l'API ignore un espace de travail auquel le membre n'appartient pas, en retombant sur le sien. - Le rôle est le même dans chaque espace de travail : un rôle et ses permissions s'appliquent dans chaque espace de travail auquel ses membres appartiennent. La cloche, les demandes et les rôles ne sont pas par espace de travail : ils restent les mêmes quel que soit celui choisi.
- Un membre invité depuis le tableau de bord appartient à l'espace de travail d'où il a été invité. Ajouter un espace de travail, ou un membre existant à un autre, n'est pas un écran du tableau de bord.
- Une installation démarrée sans les données d'exemple a un seul espace de travail, créé au premier démarrage de l'API avec son propriétaire à partir de
OWNER_EMAILetOWNER_PASSWORD, comme l'explique Déployer Ticketory.
L'équipe
/en/dashboard/teamaffiche en haut les membres de l'espace de travail par rôle, puis le tableau des membres, dix par page, les plus récemment modifiés d'abord (admins.view).- Un seul champ de recherche trouve les membres par nom ou e-mail : un texte avec un
@cherche dans l'e-mail, tout autre texte dans le prénom, le nom, l'identifiant ou le nom complet. Sur l'API,GET /api/adminsprendemail,nameetphone, et chaque filtre donné restreint la liste : ils se combinent avec AND. - Invite member crée aussitôt le compte avec un prénom et un nom, un e-mail, un rôle et un mot de passe d'au moins six caractères, saisi deux fois (
admins.create). Rien n'est envoyé par e-mail : communiquez vous-même les identifiants de connexion. - La ligne de chaque membre permet de modifier ses informations (
admins.edit), changer son rôle (admins.assign_roles) ou le retirer (admins.delete). Remove retire le membre de l'espace de travail où vous êtes, avec ses sessions de contrôle des billets ; il continue de se connecter à ses autres espaces de travail, et le compte n'est supprimé que si c'était le dernier. Les commandes, remboursements et contrôles qu'il a traités restent tels quels. - Personne ne peut se retirer lui-même (« You cannot remove yourself from the team. »), et un espace de travail garde toujours un propriétaire : retirer le dernier est refusé avec « This workspace needs at least one Owner. Give the Owner role to someone else first. »
- La page d'un membre liste ce que son rôle peut faire et, pour un membre Contrôle des billets, les sessions qu'il peut scanner, cochées et enregistrées là (
admins.edit). - Chaque membre, quel que soit son rôle, modifie son propre nom, e-mail et téléphone sous Paramètres, Profil, et change son propre mot de passe sous Paramètres, Sécurité, avec l'actuel. Aucun des deux n'exige de permission.
Équipe de contrôle des billets et leurs sessions
Un membre qui détient events.edit ou events.publish peut scanner les billets de chaque session de l'espace de travail. Tout autre avec checkin.scan ne voit et ne scanne que les sessions qui lui sont attribuées ; un billet d'une autre session est refusé avec session_not_assigned. Les attributions se font sur la page du membre dans le tableau de bord, ou avec PUT /api/admin/session-staff/:code.
Rôles
/en/dashboard/roles, ouvert depuis la page Équipe, affiche ce que peut faire chaque rôle sous forme de grille de capacités, avec un point pour autorisé, certaines actions ou non autorisé. Il crée, renomme et supprime des rôles (roles.create, roles.edit, roles.delete), et accorde leurs permissions (roles.assign_permissions). Pour donner à un membre moins qu'un rôle d'exemple, créez un rôle avec seulement les permissions dont il a besoin et attribuez-le à la place.
Ce que l'assistant peut atteindre
ai_chat.use ouvre l'assistant IA et n'accorde rien d'autre. L'assistant ne lit et ne modifie que ce que les autres permissions du membre autorisent, les mêmes que vérifient les pages du tableau de bord : sans orders.view il ne peut pas lire une commande, et sans leads.edit il ne peut pas modifier une demande. Il vérifie de nouveau avant chaque action, si bien qu'une permission retirée pendant une conversation s'applique à la suivante.
Comment un changement atteint un membre connecté
Inclus avec votre achat. Connectez-vous pour le lire, ou ouvrez-le dans votre téléchargement.
La connexion en direct qui transmet un changement de rôle à un membre connecté.