Aller au contenu principal

Décider des enregistrements qu’un visiteur voit

Objectif​

Dire une seule fois que les enregistrements d’une table appartiennent au client qu’ils désignent, afin que chaque visiteur connecté au portail voie les siens et ceux de personne d’autre — à travers chaque API personnalisée qu’utilise votre portail, et chaque API que quelqu’un ajoutera plus tard.

Le problème que cela résout​

Votre portail lit par l’intermédiaire d’API personnalisées, et un script peut déjà demander qui l’appelle :

var mine = runQuery({
  entity: 'par_ticket',
  filter: { connector: 'And', conditions: [
    { field: 'par_customer', operator: 'Equals', value: portalCustomerId() }
  ]}
});

Cela fonctionne. Cela fonctionne depuis que les visiteurs peuvent se connecter. Le problème est qu’il faut l’écrire de nouveau dans chaque script, et que son absence est invisible : une API sans ce filtre ressemble exactement à une API qui l’a, renvoie des lignes sans broncher, et montre à un client les tickets d’un autre client.

Une règle de relation de portail sort cette phrase des scripts pour la placer sur la table.

Avant de commencer​

  • Votre portail est réglé sur Personnes qui se connectent — voir Demander aux visiteurs de se connecter. Une table dotée d’une règle de relation ne peut pas être lue par un portail que tout le monde peut ouvrir, car ses enregistrements n’appartiendraient à personne.
  • Votre table possède un champ qui contient le client — une recherche vers Account est la forme habituelle, car c’est ce qu’est l’entreprise d’un visiteur.
  • Vos visiteurs sont membres d’un client. Quelqu’un qui s’est inscrit et n’a encore rejoint aucune entreprise ne correspond à rien du tout, ce qui est la réponse sûre — mais probablement pas celle que vous voulez lui montrer.

Étapes​

  1. Ouvrez votre solution et choisissez Stratégies de données.

  2. Appuyez sur Nouveau et donnez-lui un nom — Les tickets appartiennent à leur client.

  3. Définissez Type sur Quels enregistrements (portail).

  4. Choisissez la table.

  5. Écrivez la condition :

    Record.par_customer == Portal.CustomerId

    C’est l’éditeur de code de la plateforme : un nom qu’il ne connaît pas, comme Portal.CustomrId, est souligné pendant la saisie au lieu d’être refusé à l’enregistrement.

  6. Laissez En vigueur coché, puis appuyez sur Enregistrer.

C’est toute la fonctionnalité. Rien d’autre n’a besoin d’être accordé, référencé ni activé.

À quoi comparer​

Cinq éléments concernant le visiteur connecté, et la condition doit en mentionner au moins un — sinon, elle ne dit pas à qui appartiennent ces enregistrements.

Ce que c’est
Portal.CustomerIdL’entreprise à laquelle il appartient. Celui que vous utiliserez presque à chaque fois
Portal.ContactIdSon propre enregistrement de contact, s’il en a un
Portal.UserIdL’utilisateur du portail lui-même
Portal.EmailSon adresse e-mail
Portal.Role"Owner", "Billing" ou "Member" dans son entreprise

Vous pouvez combiner des conditions avec && et ||, et comparer aussi les champs propres à la table :

Record.par_customer == Portal.CustomerId && Record.par_status != "Draft"
CurrentUser n’est pas le visiteur

Sur un portail, l’« utilisateur connecté » est le serveur du portail lui-même — une identité unique partagée par tous ceux qui l’utilisent. C’est pourquoi une règle de relation ne peut pas lire CurrentUser, et pourquoi une stratégie de données ordinaire ne peut pas lire Portal. L’écran refuse l’un et l’autre à l’enregistrement.

Ce qu’elle fait, exactement​

  • Chaque lecture est restreinte, quelle que soit l’API personnalisée qui la demande. Vous pouvez supprimer le filtre des scripts qui en ont un ; vous n’y êtes pas obligé.
  • Une création qui stockerait un enregistrement au nom d’un autre client est refusée, par rapport à l’enregistrement tel qu’il sera réellement enregistré. Il en va de même d’une modification qui en déplacerait un.
  • Un visiteur qui n’appartient à aucune entreprise ne voit rien — pas même les enregistrements dont le client est vide.
  • Une seule règle par table. Si vous devez en remplacer une, écrivez la nouvelle avec En vigueur décoché, puis intervertissez-les.

Ce qu’elle ne fait pas​

Elle ne rend pas la table privée. Vos propres collaborateurs, connectés à la plateforme, voient ce que leur rôle de sécurité leur permet de voir, exactement comme avant. La règle concerne les visiteurs du portail ; elle ne remplace pas le fait d’accorder à un rôle l’accès aux enregistrements.

Elle n’est pas accordée à un rôle, et l’écran vous refusera si vous essayez. Elle appartient à la table. C’est tout l’intérêt — une règle qu’il faut penser à accorder est une règle qu’on peut oublier d’accorder.

Dépannage​

« A portal relationship rule has to say which records belong to the visitor. » Votre condition ne mentionne jamais Portal. Telle qu’elle est écrite, c’est un filtre ordinaire, ce qui est autre chose.

« …is already the portal relationship rule for… » Une seule règle décide à qui appartiennent les enregistrements d’une table. Désactivez l’autre, ou modifiez-la au lieu d’en ajouter une seconde.

Un visiteur ne voit rien du tout. Vérifiez qu’il est membre d’un client, et que le champ de votre condition est bien celui qui contient le client — une condition qui compare le mauvais champ ne correspond à rien plutôt qu’à tout, délibérément.

Le portail refuse d’enregistrer avec la table dans sa liste. Le portail est réglé sur Tout le monde. Une table dont les enregistrements appartiennent à un visiteur connecté exige un portail qui en a un.

Voir aussi​