Apercu des statuts
Chaque inscription dans tikento passe par une chaine de statuts. Les etapes exactes dependent des parametres de l'evenement : la verification de l'email est-elle activee, la moderation est-elle requise, l'evenement est-il payant.
Tous les statuts possibles
| Statut | Nom systeme | Description |
|---|---|---|
| En attente de confirmation | pending_verification | Le participant a soumis sa demande mais n'a pas encore confirme son email |
| En moderation | pending_moderation | Email confirme, la demande attend la decision de l'organisateur |
| En attente de paiement | pending_payment | Demande approuvee, paiement non recu |
| Inscrit | registered | Toutes les etapes franchies, le participant est inscrit |
| Annule | cancelled | Inscription annulee par le participant ou l'organisateur |
| Refuse | rejected | L'organisateur a refuse la demande lors de la moderation |
Chaines de transitions
L'ordre des etapes est fixe : verification de l'email (si activee) -> moderation (si activee) -> paiement (si l'evenement est payant) -> inscrit. Les etapes non applicables a un evenement donne sont ignorees.
Evenement gratuit sans moderation
Le cas le plus simple. Si la verification de l'email est activee :
pending_verification -> registered
Si la verification de l'email est desactivee, le participant obtient le statut registered immediatement apres l'envoi du formulaire.
Evenement gratuit avec moderation
pending_verification -> pending_moderation -> registered
Apres la confirmation de l'email, la demande entre dans la file de moderation. L'organisateur approuve -- le statut passe a registered. L'organisateur refuse -- le statut passe a rejected.
Evenement payant sans moderation
pending_verification -> pending_payment -> registered
Apres la confirmation de l'email, le systeme attend le paiement. Des que la passerelle de paiement confirme la transaction (via webhook), le statut passe automatiquement a registered.
Evenement payant avec moderation
La chaine la plus longue :
pending_verification -> pending_moderation -> pending_payment -> registered
L'organisateur decide d'abord s'il accepte le participant, et ce n'est qu'apres l'approbation que la possibilite de payer s'ouvre.
Qui initie les transitions
| Transition | Initiateur |
|---|---|
pending_verification -> statut suivant | Systeme (le participant a clique sur le lien ou saisi le code dans l'email) |
pending_moderation -> pending_payment ou registered | Organisateur (approbation) |
pending_moderation -> rejected | Organisateur (refus) |
pending_payment -> registered | Systeme (webhook de la passerelle de paiement) |
Tout statut -> cancelled | Participant ou organisateur |
| Changement manuel de statut | Organisateur (via la fiche du participant) |
Transitions automatiques
Le systeme effectue des transitions sans intervention de l'organisateur dans deux cas :
- Verification de l'email. Lorsque le participant confirme son email, le systeme determine automatiquement le statut suivant : si la moderation est activee --
pending_moderation, sinon et si l'evenement est payant --pending_payment, si gratuit --registered. - Reception du paiement. Lorsque la passerelle de paiement envoie un webhook de succes, le statut passe a
registered.
Transitions manuelles
L'organisateur peut :
- Approuver ou refuser une demande en moderation
- Confirmer un paiement manuellement (especes, virement bancaire)
- Annuler une inscription
- Forcer le passage a
registereden contournant les etapes intermediaires
Ou les statuts sont visibles
Le statut de chaque participant est affiche a plusieurs endroits :
- Liste des participants -- badge colore a cote du nom. Le filtre par statut permet de trouver rapidement, par exemple, toutes les demandes en moderation.
- Fiche du participant -- historique complet des transitions avec les dates et l'initiateur de chaque modification.
- Tableau de bord de l'evenement -- compteurs par statut dans le resume.
Statuts terminaux
Les statuts registered, cancelled et rejected sont terminaux -- aucune transition automatique ne s'en suit. L'organisateur peut ramener un participant de cancelled ou rejected a un statut actif manuellement via la fiche du participant.