Rôles et permissions
Chaque organisation construit ses propres rôles à partir d'un catalogue de permissions granulaires, et peut restreindre un agent unique à des produits ou des collections spécifiques, dynamiquement, sans jamais accorder plus que prévu.
Chacun restreint ce qu'une personne peut faire ou voir, sans jamais restreindre ce que la plateforme elle-même peut faire.
Utilisateurs, produits, tarification, disponibilité, taxes, réservations, billets, rapports, leads, support et clés d'API ont chacun leur propre permission dédiée, si bien qu'un rôle se construit exactement à partir des éléments dont il a besoin.
Au-delà de la permission elle-même, un agent donné peut être limité à des produits ou des collections spécifiques, pour une équipe régionale, un seul lieu, ou une marque au sein d'une opération plus large.
Restreindre quelqu'un à une collection, plutôt qu'à une liste individuelle de produits, signifie qu'un produit ajouté à cette collection plus tard lui devient visible immédiatement, sans que personne n'ait à revenir mettre à jour l'assignation.
leads.view et support.view sont deux permissions différentes, si bien qu'une personne peut gérer des opportunités commerciales sans jamais voir de tickets de support technique, ou l'inverse.
Cinq étapes, depuis la définition d'un rôle jusqu'à l'autorisation ou le blocage d'un simple clic.
Une organisation crée ses propres rôles et leur assigne exactement les permissions dont chacun a besoin, à partir d'une liste fixe et versionnée, jamais d'un champ de texte libre.
Au-delà des permissions du rôle, un utilisateur peut en plus être restreint à des produits ou des collections spécifiques, resserrant ce qu'il peut voir et sur quoi il peut agir, à l'intérieur de ce que son rôle autorise déjà.
Listes, tableau de bord et requêtes opérationnelles filtrent tous à la fois par la permission et par le périmètre produit, jamais par un seul des deux.
Mettre à jour l'accès produit de quelqu'un revérifie chaque identifiant par rapport à ce que l'organisation, et l'accès propre de l'administrateur qui agit, autorisent réellement, fermant la porte à une requête falsifiée cherchant à accorder plus que prévu.
Les actions sensibles revérifient les permissions en temps réel dans la même session active, si bien que retirer l'accès à quelqu'un en pleine session prend effet immédiatement, pas seulement à sa prochaine connexion.
Un utilisateur, une liste d'identifiants de produits, une liste d'identifiants de collections. Envoyer les deux listes vides supprime entièrement la restriction, ce n'est pas un moyen d'exclure quelqu'un.
{
"user_id": 482,
"product_ids": [
118,
119,
204
],
"collection_ids": [
7
],
"scope": "restricted"
}N'envoyer aucun identifiant de produit ni de collection n'exclut pas un utilisateur de tout : cela efface entièrement la restriction et lui redonne accès à tous les produits de l'organisation, comme n'importe quel autre coéquipier sans restriction. Restreindre quelqu'un à zéro produit n'est volontairement pas un état que le système cherche à représenter en tant que tel, pour éviter un état séparé, facile à mal utiliser, qui signifierait silencieusement « ne rien voir ».
Oui, en l'assignant à une collection plutôt qu'à des produits individuels. Un produit ajouté à cette collection par la suite lui devient visible automatiquement, sans avoir à revenir mettre quoi que ce soit à jour.
Oui, pour les actions sensibles. Les permissions sont revérifiées en temps réel sur la même session active, si bien qu'une permission révoquée cesse de fonctionner immédiatement, pas à la prochaine connexion.
Oui. leads.view et support.view sont deux permissions entièrement séparées, si bien qu'un rôle peut recevoir l'une sans l'autre, gardant les boîtes des deux équipes séparées même si les deux passent par le même système.
Chaque identifiant de produit ou de collection dans un changement de périmètre est revalidé par rapport à ce que l'organisation possède réellement, et par rapport aux produits accessibles à l'administrateur qui agit, avant que quoi que ce soit ne soit enregistré. Une charge falsifiée avec un identifiant qui ne vérifie pas est simplement rejetée.
Vingt-huit, couvrant tout, de la gestion des utilisateurs et de la rotation des clés d'API jusqu'à la validation d'un seul billet à l'entrée, chacune pouvant être accordée entièrement à part.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.