Invitations
Une invitation attire volontairement les gens sur le portail : le personnel choisit qui le reçoit et les rôles qu’elle attribue, et chaque destinataire reçoit un lien à son endroit. Le suivi crée leur connexion sur le contact déjà existant pour lui — avec un mot de passe ou une connexion externe — ou, s’ils en ont déjà un, ajoute les rôles à celui-ci. C’est ainsi qu’un portail qui ne permet pas aux inconnus de s’inscrire attire ses utilisateurs à bord.
Comment voyage une invitation
Une invitation est écrite sous forme de brouillon, et l’envoyer ne change rien d’autre que son statut. Le processus chronométré du portail — qui s’exécute toutes les cinq minutes dans chaque instance du portail — le remarque, calcule les destinataires, et envoie à chacun un lien avec son propre code. Seul le hachage du code est stocké, donc lire le tableau ne donne à personne un lien fonctionnel.
- Draft — choisissez qui le reçoit, les rôles attribués, sa date d’expiration et l’email envoyé par message.
- Prêt à envoyer — Envoyer a été pressé ; le portail le capte en quelques minutes.
- Envoyé — les destinataires existent et leurs liens fonctionnent jusqu’à l’expiration (30 jours après l’envoi, sauf si vous fixez une date).
- Expiré ou annulé — les liens cessent de fonctionner.
Qui le reçoit
Une invitation est envoyée à un contact, à un compte — à chaque contact actif qu’il possède — ou à n’importe quel critère écrit avec le retour du constructeur de requêtes FetchXML. Les destinataires sont calculés lors de l’envoi de l’invitation, avec l’accès de la personne qui l’a envoyée, et le renvoi par la suite atteint la correspondance qui correspond à ce moment-là et qui ne l’a pas reçue, sans envoyer deux e-mails à personne. Les contacts sans adresse e-mail sont ignorés, et donc, sauf indication contraire de l’invitation, sont les contacts qui ont déjà une connexion sur le portail.
Qui le reçoit est fixé une fois envoyé
Une fois qu’une invitation quitte Draft, qui la reçoit et les rôles qu’elle accorde ne peut pas changer — les rôles sont lus quand quelqu’un accepte, donc les changer modifierait ce que reçoivent les personnes détenant déjà un lien. Sa date d’expiration peut toujours changer. Chaque destinataire peut recevoir un nouveau lien ou être révoqué de lui-même.
L’e-mail
Laissé à lui-même, le portail envoie son propre email, depuis sa localisation (app.email-templates.invitation). Pour écrire le vôtre, créez un modèle de contact ou d’email global dans Dataverse, placez {{invitation-link}} l’endroit où le lien doit aller, et choisissez-le sur l’invitation. Un modèle sans le placeholder échoue au destinataire au lieu d’envoyer un email sur lequel personne ne peut agir.
Acceptation
Le lien s’ouvre /Account/Invitation. Quelqu’un sans connexion en crée un à cet endroit — l’adresse e-mail du contact invité, avec un mot de passe ou toute connexion externe configurée — même lorsque l’inscription est désactivée. Quelqu’un ayant une connexion se connecte et accepte ; une personne connectée en tant qu’autre personne est invitée à se déconnecter. Suivre un lien envoyé à l’adresse compte comme une confirmation, donc aucun email de confirmation ne suit. Un code inconnu, utilisé, révoqué, expiré ou pour un autre portail indique tous la même chose.
Le discours public
Le processus temporisé fonctionne en dehors de toute requête, donc il lit l’adresse depuis PowerPortalsPro:PublicUrl laquelle le portail est atteint — requise, pour chaque portail. Ses liens pointent là, et c’est l’adresse pour laquelle la licence du portail est vérifiée lors de la décision des invitations qui lui appartient. Définissez-le par environnement pour que les liens de l’UAT pointent vers l’UAT ; dans Azure App Service, c’est le PowerPortalsPro__PublicUrl paramètre de l’application, marqué comme un réglage de slot de déploiement. Un portail qui tourne localhost n’envoie aucune invitation à moins PowerPortalsPro:Invitations:DevelopmentWebsiteId qu’il ne nomme l’enregistrement du site web pour agir comme ça.
{
"PowerPortalsPro": {
"PublicUrl": "https://portal.contoso.com"
}
}
Le câblage
InvitationAdmin liste les invitations, avec Envoyer et Annuler ; InvitationForm en modifie une, avec ses destinataires en dessous. Verrouillez la page dans la vérification administrateur du portail, comme les autres pages admin, et donnez au formulaire une page propre : les critères sont écrits avec le constructeur de requêtes FetchXML, qui veut la salle. Chaque modification est effectuée en tant que membre du personnel connecté, donc la sécurité Dataverse s’applique ici comme dans l’application modélisation.
// Ouvre chaque invitation sur une page à part entière
<InvitationAdmin
invitationUrl={(id) => `/InvitationAdmin/Invitation/${id ?? 'new'}`}
onNavigate={(url) => navigate(url)}
/>@attribute [Route("InvitationAdmin")]
@attribute [AuthorizeSystemAdmin]
@using PowerPortalsPro.Web.Blazor.FluentUI.Components
<SystemAdminView>
<Authorized>
<InvitationAdmin InvitationUrl="InvitationAdmin/Invitation?invitationId={0}" />
</Authorized>
</SystemAdminView>// Une invitation, dans un RecordContext avec un bouton Enregistrer
const { id } = useParams();
const isCreateMode = id === 'new';
<RecordContext table="ppp_invitation" {...(isCreateMode ? {} : { id })}>
<SaveContextButton appearance="primary" />
<InvitationForm />
</RecordContext>
InvitationAdmin
InvitationAdmin Classe
Paramètres
Nom | Type | Par défaut | Description |
|---|---|---|---|
InvitationUrl | string? | Lorsqu’une invitation est modifiée, comme une URL dont |
InvitationUrlFormulaire d’invitation
InvitationForm Classe
Propriétés
Nom | Type | Par défaut | Description |
|---|---|---|---|
Record | TableRecord? | L’invitation est en cours de modification. |
Record