Chronologie

Le Timeline composant affiche des lignes de plusieurs tableaux en une seule liste, la plus récente en premier : par défaut les notes d’un enregistrement, les communications par portail et d’autres activités. Mettez-le dans un RecordContext et il liste les lignes concernant cet enregistrement : qui a écrit chaque enregistrement et quand, son corps en texte enrichi réduit à quelques lignes jusqu’à Afficher plus, et sa pièce jointe à télécharger. Il lit page par page, avec Charger plus pour le reste et Rafraîchir pour la relire. La recherche fonctionne comme une grille : le texte correspond au début d’un sujet ou d’un texte, ou n’importe où après un début *, et un jour ou une année, avec >, <, >= ou <= avant, trouve les lignes de ces jours. Avec plus d’un tableau, un menu à côté de la recherche choisit lequel afficher.

Quelles notes et activités sont affichées

Une note n’arrive au portail que lorsque son texte commence par *WEB*, afin que le personnel puisse conserver des notes internes sur les dossiers que les clients voient. Les appels téléphoniques, tâches et autres activités suivent la même règle dans leur description, sauf les types non filtrés — communications par portail, par défaut. Le serveur applique cela à toutes les requêtes, grilles et jointures incluses, donc aucune règle d’accès à la table ne peut l’élargir. Le portail n’affiche jamais le préfixe, et l’ajoute à une note ou activité créée via le portail. Une note dont le titre nomme son auteur est Note created on … by Name [contact:id] affichée comme écrite par ce contact. Configuré SecurityOptions.PortalVisibility.Prefix pour utiliser un autre préfixe, ou pour null afficher chaque note et activité, et ajouter un tableau pour UnfilteredActivities afficher chaque activité. Le personnel connecté au portail en tant que lui-même fait exception : ils voient chaque note et activité que leurs rôles de sécurité leur permettent de lire, comme dans Dynamics, avec son texte tel que stocké, ils ajoutent donc eux-mêmes le préfixe à une note destinée au portail.

Les emails ne peuvent pas être marqués avec le préfixe. Le corps d’un email est écrit par le client mail qui l’a envoyé, comme un document HTML complet, donc le préfixe n’est jamais son premier texte, et aucun email n’atteint le portail par son préfixe. Ajouter email à UnfilteredActivities est la seule façon d’afficher les emails, et il affiche chaque email que l’utilisateur peut lire sur un enregistrement — y compris les internes.

Communications par portail

Une communication par portail (ppp_portalcommunication) est une activité dans la solution Power Portals Pro pour les messages entre un utilisateur du portail et son personnel. Elle est destinée au portail, elle n’a donc pas besoin de préfixe. Son message indique qui l’a écrite : le contact de l’utilisateur du portail, ou le membre du personnel qui a répondu, avec le contact dans To. Le message est en texte enrichi et peut contenir une pièce jointe.

Accès

La chronologie ne liste que ce que l’utilisateur peut lire : chaque type d’élément doit être lu sur sa table, et un utilisateur qui ne peut lire aucun ne voit aucune ligne du temps. Une note pointe vers son enregistrement via objectid et une communication par portail via regardingobjectid, donc la règle habituelle permet à un utilisateur de lire les éléments concernant les enregistrements qu’il peut atteindre, avec RowsViaParent. Garde cette recherche parmi les colonnes qu’il peut lire : la chronologie demande les éléments concernant son enregistrement via celle-ci, et une condition sur une colonne qu’un utilisateur ne peut pas lire est supprimée, ce qui listerait les éléments de chaque enregistrement atteint.

L’utilisateur de l’application du portail doit également lire les deux tables dans Dataverse. Les notes doivent être lues sur la table de notes. Dataverse accorde à chaque type d’activité un seul ensemble de privilèges, de sorte que les communications par portail sont couvertes par les activités de lecture que le rôle d’utilisateur d’application Power Portals Pro détient déjà. Pour que les utilisateurs modifient ou suppriment des notes et des messages, il faut aussi Écrire et supprimer sur la table de notes et Supprimer sur les activités, ce qui ne tient pas.

Rédiger des messages

Un utilisateur qui peut créer des communications par portail reçoit Nouveau message : un sujet, un message enrichi et une pièce jointe, concernant l’enregistrement sur lequel se trouve la timeline, et celui qui peut créer des notes reçoit une nouvelle note. CreatableTables Nomme les tables sur lesquelles une nouvelle ligne peut être écrite, notes et communications par portail par défaut ; une note ou un message est écrit en place, la ligne d’une autre table dans un panneau latéral. C’est une forme à part, sauvegardée séparément de la page autour. Le serveur envoie le message de l’utilisateur, quoi que soit la demande, donc un utilisateur ne peut pas écrire comme un autre. Accordez-lui un accès à table : OwnedBy("from") envoie un nouveau message de son auteur, et RowsForWriting permet RowsOwnedByContact("from") aux utilisateurs de ne modifier ou supprimer que ce qu’ils ont envoyé. En omettant Écrire et Supprimer, un message reste tel qu’il a été envoyé. La timeline propose Modifier et Supprimer à chaque ligne où l’accès de l’utilisateur lui permet de modifier ou de supprimer, et le serveur juge chaque changement à nouveau lorsqu’il arrive. FormLocation (Réagir : formLocation) indique où s’ouvre la forme d’une autre table : un panneau latéral à droite, comme par défaut, ou à gauche, un dialogue au centre, ou Inline — en place dans la timeline, au fur et à mesure que les notes et messages sont écrits.

Le personnel entend parler d’un nouveau message via PortalCommunicationOptions. Par défaut, il est adressé au propriétaire de l’enregistrement concerné, lorsque ce propriétaire est un utilisateur. Il peut aller dans une file d’attente, à laquelle l’utilisateur de l’application du portail doit accéder pour ajouter des éléments, ou à personne, ne laissant que le message sur la timeline de l’enregistrement.

Tableaux

Les notes et chaque table d’activités sont enregistrées sur le serveur pour les chronologies et calendriers, chacune datée selon ce que ses formulaires demandent : un rendez-vous au début, une tâche ou un appel téléphonique à la date d’échéance, un e-mail ou un message à la date de sa rédaction. Une chronologie liste toutes les tables enregistrées que l’utilisateur peut lire ; nommer celles qu’elle affiche dans Tables. Sur un enregistrement, elle liste les lignes à son sujet, ainsi que les activités auxquelles l’enregistrement participe en tant qu’expéditeur, destinataire ou participant. Le serveur affiche uniquement les notes et activités destinées au portail : celles dont le texte commence par *WEB*, ou chacune d’un type dans UnfilteredActivities. Les e-mails ne peuvent pas porter le préfixe, ils apparaissent donc uniquement lorsqu’ils email sont dans cette liste.

Enregistrez votre propre tableau avec AddMultiTableSource: un titre, et ce qui est d’autre affiché, comme le texte, son propriétaire et ses destinataires, et la recherche vers l’enregistrement dont correspond une ligne. Ensuite, nommez chaque contrôle auquel il est destiné, avec les colonnes dont le contrôle a besoin : ForTimelines la date d’ordre de ses lignes, ForCalendars son début et, s’il les a, sa colonne de fin et de la journée entière, ForSearch, ainsi ForMaps que sa latitude et sa longitude. Ces colonnes sont toujours lues, quels que soient les noms de la requête d’une vue. Une inscription qui nomme une colonne que la table n’a pas, ou une de mauvais type, arrête le portail au démarrage et indique ce qui ne va pas. Enregistrer une table de notes ou d’activité ne change à nouveau que les noms de l’enregistrement. Une inscription n’accorde aucun accès : chaque table a toujours besoin d’un accès en lecture comme n’importe quelle table.

Rangées à venir

Une chronologie liste ses lignes les plus récentes en premier, puis à partir de maintenant. Upcoming (Réagir : upcoming) la commence aussi loin d’avance, donc ce qui apparaît apparaît d’abord sous son propre titre, et Ascending (Réagir : ascending) liste les lignes à partir de maintenant, le plus tôt : voir Éléments à venir. Pour dessiner les lignes d’une table à votre façon, ou les écrire sous vos propres formes, voir Rendu personnalisé.

Vues

Donnez le choix aux vues de la timeline, car une grille possède : celles propres à Dataverse dans ViewIds, comme Mes appels téléphoniques ou Toutes les activités, des vues de plusieurs tables dans MultiTableViewIds, et des vues de vos propres vues dans CustomViewDefinitions, en DefaultViewId nommant celle affichée en premier. Avec deux vues ou plus, un sélecteur de vues remplace le titre. Une vue Dataverse liste activitypointer chaque table d’activité enregistrée, et sur un enregistrement, une vue liste les lignes concernant l’enregistrement qu’elle laisse passer. Avec (Réagir : allowSavedViews), un utilisateur connecté peut enregistrer les tables que la timeline affiche comme une vue propre, proposée à côté de AllowSavedViews la vôtre, et choisir sa vue par défaut et masquer celles qu’il n’utilise pas, depuis le menu Filtrage : voir Vues sauvegardées.

Une vue de vos propres liste les lignes d’une ou plusieurs tables. Donnez une requête FetchXML à une table, et ses filtres et jointures déterminent quelles lignes s’affichent, afin qu’une vue puisse accéder aux lignes déposées par rapport à d’autres enregistrements, comme les appels téléphoniques avec les contacts d’un compte ; réglée FilterByRecord sur false pour que les requêtes de la vue décident d’elles-mêmes. La timeline lit ses propres colonnes dans son propre ordre, donc les colonnes et ordres d’une requête n’ont pas d’importance. L’utilisateur doit pouvoir lire chaque colonne qu’un filtre teste : une condition sur une colonne que l’utilisateur ne peut pas lire est supprimée.