Utiliser les tags comme conditions
Les tags utilisés comme conditions déterminent qui peut réserver une offre dans le processus public de réservation. Ils permettent de représenter clairement les séries de cours, renouvellements de certification, offres membres, exclusions et inscriptions uniques.
Une condition de tag ne constitue toutefois pas une autorisation générale d’utilisateur. Elle agit dans les contrôles prévus de réservation, de promotion ou de visibilité. Les réservations manuelles par les administrateurs doivent donc être contrôlées séparément.
Tags normaux, conditions positives et négatives
| Type | Signification | Effet |
|---|---|---|
| Tag normal | Caractéristique de l’offre ou de la personne | Peut devenir un tag effectif d’une personne par l’intermédiaire d’une réservation. |
| Condition positive (+) | Le tag doit être présent | La réservation n’est possible que si toutes les conditions positives sont remplies. |
| Condition négative (-) | Le tag ne doit pas être présent | Une seule condition négative correspondante suffit à bloquer la réservation. |
Plusieurs conditions positives sont reliées par ET. Pour une alternative, les deux parcours doivent donc fournir les mêmes tags nécessaires. Exemple : une offre combinée reçoit les tags des parties 1 et 2 pour satisfaire le même prérequis que deux cours réservés séparément.
Quels tags d’une personne sont pris en compte
Pour le contrôle, edoobox constitue une liste de tags effectifs. Elle comprend les tags normaux de réservations qui ne sont pas en liste d’attente, les tags attribués directement dans le profil utilisateur et ceux d’une attribution SSO/SAML.
Les tags d’offres antérieures ou archivées peuvent toujours faire partie de l’historique de réservation.
Une réservation uniquement en liste d’attente ne fournit pas de tag effectif d’offre.
Dans les modèles,
UserTagscontient les noms des tags effectifs, et non leurs valeurs.OfferTagspeut aussi contenir les noms des conditions positives et négatives de l’offre ; le résultat ne constitue donc pas une liste de seuls tags normaux d’offre. Ne traitez pas automatiquement cette liste comme le statut de la réservation actuelle.
Si une condition avec valeur est choisie, le nom et la valeur doivent correspondre. Une condition sans valeur accepte tout tag effectif portant le même nom. D’autres détails figurent dans Utiliser les tags avec valeurs.
Prérequis positifs et ordre temporel
Si le tag nécessaire provient d’une réservation antérieure, il ne suffit pas à lui seul : la date de fin de l’offre qui l’a fourni doit précéder ou coïncider exactement avec le début de la nouvelle offre. edoobox empêche ainsi qu’un cours de base encore en cours soit déjà considéré comme prérequis terminé.
Les tags attribués directement à une personne ou via SSO/SAML n’ont pas de date de fin d’offre et satisfont immédiatement la condition positive. Utilisez donc les tags personnels directs pour des états tels que « Membre » ou « Certificat vérifié à l’extérieur », et non pour remplacer un cours encore en cours.
Conditions négatives et doubles réservations
Pour une condition négative, tout tag effectif correspondant bloque la réservation. Les tags d’offres ne font alors l’objet d’aucun contrôle supplémentaire de date de fin. Une offre peut donc se marquer elle-même avec un tag normal et exiger négativement ce même tag pour empêcher une seconde réservation de la même personne identifiée.
Vérifier correctement les inscriptions groupées
Lors d’une inscription groupée, le contact principal et chaque participant groupé sont contrôlés s’ils peuvent être identifiés. Définissez les champs d’identification pour qu’edoobox attribue les personnes existantes sans ambiguïté. Sinon, un prérequis peut sembler non rempli malgré un historique existant.
Vérifiez aussi si une inscription groupée sans participant principal est utilisée. Le prérequis ne doit alors pas être rattaché accidentellement au seul contact qui réserve.
Tags comme conditions des codes promotionnels
Une campagne promotionnelle peut aussi vérifier des conditions de tags positives et négatives. Dès qu’une promotion comporte de telles conditions, la personne doit être connectée et associée à un compte utilisateur existant. Toutes les conditions positives doivent être remplies et aucun tag négatif ne doit correspondre.
Pour les conditions de promotion, la liste des tags effectifs est vérifiée sans contrôle supplémentaire de la date de fin d’une offre antérieure. Si une réduction ne doit s’appliquer qu’après un cours réellement terminé, un tag personnel géré précisément tel que « Ancien participant confirmé » est plus fiable.
Afficher les widgets selon les tags de la personne connectée
Dans le Design Manager, la visibilité d’un widget peut être définie sur Condition. Ce paramètre vérifie les tags effectifs de la personne connectée, et non les tags de l’offre actuellement ouverte. Sans connexion, un tel widget reste masqué.
Tous les tags positifs de visibilité doivent être présents et aucun tag négatif de visibilité ne doit l’être. Les membres peuvent ainsi voir un téléchargement supplémentaire, par exemple, tandis que les personnes portant le tag « Documents déjà envoyés » ne reçoivent plus d’indication.
Limites et points de contrôle
Les réservations administratives manuelles peuvent contourner les conditions de tags, la logique de capacité et d’autres règles du formulaire public. Vérifiez vous-même les prérequis avant l’ajout.
Avec le libre choix des dates, le prérequis temporel repose sur le début et la fin de l’offre, et non sur une date individuelle choisie.
Nommez les tags de manière compréhensible sur le fond et dans la durée. Un changement ultérieur de nom peut toucher les conditions, filtres, modèles et procédures documentées.
Testez séparément les personnes avec conditions positives, négatives et inconnues. Un test réussi avec un administrateur connecté ne prouve pas le parcours public.
Exemples d'application
Exemple d’utilisation : cours de perfectionnement après un cours de base terminé
Le cours de base reçoit le tag normal Englisch A1. Le cours de perfectionnement exige + Englisch A1. Une réservation antérieure ne donne accès que si la date de fin du cours de base est au plus tard égale au début du cours de perfectionnement. Pour des connaissances vérifiées à l’extérieur, un administrateur peut aussi attribuer directement le même tag à la personne.
Exemple d’utilisation : inscription unique
L’offre « Assemblée annuelle 2026 » reçoit le tag normal GV2026 et simultanément la condition négative - GV2026. Après la première réservation normale, la personne identifiée possède le tag et une seconde réservation publique est bloquée. Les réservations administratives continuent d’être contrôlées manuellement.
Exemple d’utilisation : réduction membre et téléchargement exclusif
Les membres confirmés reçoivent directement le tag personnel Mitglied. Une promotion exige positivement ce tag. Un widget du Design Manager affiche en plus un téléchargement uniquement aux personnes connectées possédant Mitglied. La réduction et le contenu supplémentaire utilisent ainsi le même groupe cible géré sur le fond.
Configurer et contrôler les conditions dans l’offre
- Ouvrez l’offre et son édition des tags.
- Ajoutez les tags nécessaires dans les conditions positives et les exclusions dans les conditions négatives. Utilisez les tags existants ; pour une valeur précise, choisissez exactement la combinaison du nom et de la valeur.
- Appliquez l’attribution et ouvrez l’aperçu public.
- Vérifiez une personne reconnue remplissant le prérequis, une autre avec un tag manquant et une autre avec une exclusion. Pour les tags de réservation, contrôlez aussi l’ordre temporel des offres.
Si un tag doit provenir directement de la personne, ouvrez le profil utilisateur et Modifier les tags. Un tag personnel direct n’a pas de date de fin d’offre. Pour un abonnement achetable avec validité ou utilisations de pass, utilisez le gestionnaire d’abonnements ; pour les droits tarifaires, lisez Catégories de prix.