Utilisateurs de l'app
Les comptes de ceux qui UTILISENT l'application construite — créer, activer et désactiver, agir en lot — et les rôles qui décident de ce que chacun voit et peut faire.
Il y a deux populations dans Keplin, et elles ne se mélangent jamais :
| Qui | Où il entre | Où il est géré |
|---|---|---|
| Ceux qui construisent | Sur la plateforme — ils voient la liste des apps, dessinent des écrans, modifient le modèle. | Dans Utilisateurs, dans la zone d'administration de la plateforme. |
| Ceux qui utilisent | Dans l'application construite, par son adresse. Ils ne savent même pas que Keplin existe. | Dans Paramètres de l'app → Utilisateurs de l'app. |
Cette page porte sur la seconde. L'avertissement en haut de la section ne pourrait pas être plus clair : « Ces utilisateurs appartiennent à l'app construite — ils se connectent à l'app en runtime et n'ont aucun accès à la plateforme KEPLIN. »
La liste des comptes
Ouvrez les Paramètres de l'app (l'engrenage en haut de l'arborescence) et, dans le groupe Utilisateurs, la section Utilisateurs de l'app.
Chaque ligne apporte l'Utilisateur (nom d'utilisateur, nom et e-mail), les Rôles et la Dernière connexion — « jamais connecté » quand il n'y a jamais eu de connexion. Un compte désactivé apparaît marqué Désactivé.
Au-dessus de la liste, il y a trois outils de recherche :
- la recherche « Rechercher par nom, utilisateur ou e-mail… » ;
- le filtre par rôle (Tous les rôles, ou Sans aucun rôle) ;
- le filtre par état (Tous les états).
L'avertissement qui résout la moitié des problèmes
Quand il y a des comptes sans aucun rôle, un avertissement ambre apparaît : « {n} utilisateur(s) sans aucun rôle — ils ne voient ni données ni écrans. Cliquez pour les afficher. »
Il est cliquable, et filtre aussitôt ces comptes. Il vaut la peine de le savoir par cœur : la cause numéro un du « je suis entré dans l'app et tout est vide » est un compte sans rôle. Sans rôle il n'y a pas de permissions, et sans permissions il n'y a ni données ni écrans.
Créer et modifier des comptes
Nouvel utilisateur ouvre la fiche — en page, jamais en fenêtre modale.
| Champ | Notes |
|---|---|
| Nom d'utilisateur | Obligatoire. « Lettres, chiffres, point, tiret, _ et @. » C'est ce que la personne saisit sur l'écran d'entrée. |
| Nom | Facultatif. Ce qui apparaît dans les listes et dans les attributions de tâches. |
| Facultatif, mais nécessaire pour récupérer le mot de passe et pour recevoir les rapports planifiés. | |
| Mot de passe | À la création, c'est le mot de passe initial — « l'utilisateur peut le changer dans l'app ». À la modification, « à remplir uniquement pour définir un nouveau mot de passe ». |
| Actif | Désactivé, le compte existe mais « ne peut pas se connecter à l'app ». |
| Rôles | Les rôles de ce compte. Un nouveau compte arrive avec ceux qui sont définis comme Attribué par défaut déjà cochés. |
Enregistrez avec Enregistrer. Pour modifier un compte existant, le menu ⋮ de la ligne → Modifier ; pour le supprimer, Supprimer — irréversible, et l'utilisateur ne peut plus se connecter.
Dica
Désactiver vaut presque toujours mieux que supprimer. Le compte désactivé ne se connecte pas, mais l'historique continue d'avoir du sens : les tâches qu'il a tranchées, les enregistrements qu'il a créés, les notifications qu'il a reçues.
En lot
Sélectionnez plusieurs lignes avec les cases à gauche et la barre d'actions apparaît : Attribuer un rôle, Retirer le rôle, Activer, Désactiver. Donner le même rôle à douze personnes est une opération, pas douze fiches.
Nota
Les permissions ne se modifient pas sur le compte — elles se modifient toujours sur les rôles. Une exception posée sur une personne est une exception que personne ne retrouve jamais.
Les rôles
La section Permissions définit ce que chaque rôle peut faire. « Chaque rôle dit ce qu'il est possible de faire. Les permissions s'additionnent : avec deux rôles, on garde le meilleur des deux. »
La liste montre chaque rôle avec sa description, combien d'Utilisateurs l'ont et combien de Règles il a. Les badges disent le reste : par défaut (attribué à qui s'inscrit ou vient d'être créé) et accès total.
Nouveau rôle en crée un ; le menu ⋮ d'une ligne a Modifier et Supprimer. Supprimer prévient combien de personnes s'en retrouvent privées — « et toute personne qui se retrouve sans aucun rôle cesse de voir les données ».
Un rôle s'ouvre avec cinq onglets.
Général
| Champ | Ce qu'il fait |
|---|---|
| Nom / Description | Identification. La description apparaît dans la liste et dans la fiche des utilisateurs. |
| Accès total | « Tout, sans exception — et cela reste juste quand l'app grandit. » |
| Attribué par défaut | « Attribué à toute personne qui s'inscrit ou qui vient d'être créée. » |
Sur l'Accès total : « il n'y a aucune règle à lister : une API ou un écran créés demain lui appartiennent déjà. C'est ce que l'on veut d'un administrateur — et l'inverse de ce que l'on veut partout ailleurs. »
Données — ce que chacun arrive à voir
L'onglet qui compte le plus. Une ligne par API de table, avec quatre cases — Voir, Créer, Modifier, Supprimer — et le Scope des enregistrements.
| Scope | Signifie |
|---|---|
| Tous les enregistrements | Sans restriction de lignes. |
| Seulement les miens | Seulement les enregistrements dont le « Champ qui dit à qui il appartient » est l'utilisateur connecté. |
| Avec condition… | Seulement les enregistrements qui satisfont un filtre — avec des valeurs fixes ou venues de la session de qui utilise l'app. |
Et la phrase qui décide de l'architecture de sécurité d'une app entière :
« Le scope est appliqué sur le serveur, à chaque lecture et à chaque écriture — dans les écrans, dans le code, dans les rapports et dans les workflows. Sans aucune règle, ce rôle ne voit rien de cette API. »
Autrement dit : un rapport ne perce pas les permissions, un workflow ne perce pas les permissions, un événement d'écran ne perce pas les permissions. Tous passent par le même filtre, sur le serveur.
Écrans
Pour chaque écran et chaque appareil — Web, Tablette, Téléphone — un niveau d'accès :
| Niveau | Ce qu'il fait |
|---|---|
| Masqué | « N'apparaît pas dans les menus, et la route saisie à la main est refusée. » |
| Voir (lecture seule) | « Ouvre en lecture seule — les champs et les boutons qui enregistrent sont désactivés. » |
| Modifier | « Ouvre et fonctionne. » |
Les raccourcis tout voir / tout masquer, dans l'en-tête de chaque colonne, remplissent l'appareil entier d'un coup.
Atenção
« Le « voir » est une aide visuelle ; ce qui bloque vraiment l'écriture, ce sont les permissions de Données, sur le serveur. » Un écran en lecture seule évite les erreurs ; il n'arrête personne de déterminé. La porte qui ferme vraiment est celle de Données.
Menus
Contrairement aux écrans, un menu est visible par défaut — « la porte, c'est l'écran, et elle est déjà fermée ». Ici on masque le reste : un groupe entier du menu, la cloche des notifications, une entrée précise, par appareil. Décocher un groupe emporte ses enfants avec lui.
Actions
Les actions sont « les verbes qui n'existent que dans cette app : approuver,
fermer, exporter ». Elles se déclarent une fois, dans le panneau Actions de
la liste des rôles — une Clé (aprovar-oportunidade) et un Nom
(« Aprovar oportunidade »), bouton Nouvelle action — et chaque rôle coche
celles qu'il accorde.
Elles s'utilisent à deux endroits :
- dans les propriétés de n'importe quel widget, dans le champ Accès, pour que le widget n'apparaisse qu'à qui a l'action ;
- en code TypeScript :
keplin.session.can("aprovar-oportunidade").
Une action que personne n'accorde apparaît marquée « aucun rôle ne l'accorde » — signe qu'il reste soit à l'attribuer, soit qu'elle ne sert plus à rien.
Tout s'enregistre d'un coup, avec Enregistrer.
Comment tout cela se rejoint en runtime
Quand une personne entre dans l'app publiée :
- Elle s'authentifie avec le compte de l'app (ou par le fournisseur d'identité de l'organisation, si l'app est en OAuth).
- Ses rôles s'additionnent : elle garde le meilleur de chacun.
- Les menus et les écrans sont filtrés avant que la page ne se dessine.
- Chaque lecture et chaque écriture passent par le scope des données, sur le serveur — qu'elle vienne des écrans, d'un rapport, d'un workflow ou d'un script.
Questions fréquentes
J'ai créé le compte, la personne entre, et ne voit rien. Elle n'a probablement pas de rôle. Voyez l'avertissement ambre dans la liste des utilisateurs. Si elle a un rôle, vérifiez dans l'onglet Données de ce rôle s'il y a des règles — « sans aucune règle, ce rôle ne voit rien de cette API ».
Je veux que chaque commercial ne voie que ses propres opportunités. Dans l'onglet Données, scope Seulement les miens, avec le Champ qui dit à qui il appartient pointé sur le champ du responsable. Cela fonctionne partout, y compris dans les rapports.
Un utilisateur de l'app peut-il entrer sur la plateforme ? Non. Ce sont des comptes de mondes différents, stockés séparément. Un utilisateur de l'app n'a aucun accès à la plateforme, et un compte de la plateforme n'entre pas dans l'app construite sans y avoir son propre compte.
Les comptes voyagent-ils quand j'exporte l'app ? Par défaut, non : « c'est l'application qui voyage, avec les rôles et les permissions, pas ceux qui l'utilisent ». Seul l'export avec secrets, protégé par passphrase emporte aussi les comptes. Voir Importer et exporter des apps.