Carnet Wiki

Utiliser le plugin Agenda : Evenements et Participants

Version 10 — Décembre 2016 YannX

Le plugin Agenda propose l’intégration de deux tables pour enregistrer les évènements, et éventuellement les inscriptions de participants (genre doodle-like, pour les seuls auteurs authentifiés), en utilisant le plugin Calendrier Mini.

Cette article proposera une documentation plus complète -fondée sur Agenda_3- et des remarques pour pouvoir utiliser plus facilement ces deux tables, et configurer leurs usages...

(en cours de réflexion Octobre 2016/YannX)

Le source est consultable en-ligne.

Les tables

L’agenda est construit autour d’une table spip_evenements comportant les champs suivants :
-  la clé primaire #ID_EVENEMENT pour isoler chaque enregistrement,
-  le numéro #ID_ARTICLE de référence pour la page associée,
-  le champ #TITRE habituel à tous les objets SPIP,
-  les champs #DATE_DEBUT et #DATE_FIN contiennent des valeurs de #DATE système (ce qui permet/nécessite d’y appliquer les filtres d’affichage de date, ou la gestion des critères age_...
-  la #DATE_CREATION permet de retrouver l’origine
-  chaque évènement comporte aussi les divers champs textes de
#DESCRIPTIF, de #LIEU et d’#ADRESSE,
-  le champ #HORAIRE enregistre logique (oui/non) ....
-  si l’#INSCRIPTION est cochée (sinon à valeur ), vous pourrez trouver le nombre de #PLACES ouvertes
-  le champ #STATUT propose la gestion habituelle à SPIP
-  enfin le système enregistre la dernière modification dans un champ #MAJ

La déclaration utilisée permet aussi d’utiliser sur cette table les critères racine, meme_parent, et id_parent pour remonter à un evenement d’origine (cas des répétitions)

Une table annexe spip_evenements_participants [1] Une table annexe < code>spip_evenements_participants</code > permet d’enregistrer chaque auteur répondant à cet evenement ; elle comporte les champs suivants :
-  une clé primaire #ID_EVENEMENT_PARTICIPANT pour isoler chaque enregistrement,
-  l’identificateur #ID_EVENEMENT pour relier l’évenement ciblé ci-dessus,
-  l’identification de chaque auteur #ID_AUTEUR
(ce fonctionnement est actuellement restreint aux seuls auteurs authentifiés sous SPIP, comme administrateur, rédacteur ou visiteur connecté)
-  le #NOM
-  son #EMAIL
-  la #DATE de réponse (système / parfois aussi nommée maj dans SPIP)
-  enfin le code de #REPONSE (qui peut prendre trois valeurs possibles : oui, non ou ?)


Les outils

Outre la configuration (voir ci-dessous), deux formulaires sont proposés :
-  editer_evenement
-  participer_evenement

De nombreux pipelines :

<pipeline nom="autoriser" inclure="agenda_autoriser.php" />
	<pipeline nom="declarer_tables_interfaces" inclure="base/agenda_evenements.php" />
	<pipeline nom="declarer_tables_auxiliaires" inclure="base/agenda_evenements.php" />
	<pipeline nom="declarer_tables_objets_sql" inclure="base/agenda_evenements.php" />


<pipeline nom="affiche_milieu" inclure="agenda_pipelines.php" />
	<pipeline nom="compositions_declarer_heritage"  inclure="agenda_pipelines.php" />
	<pipeline nom="insert_head_css" inclure="agenda_pipelines.php" />
	<pipeline nom="optimiser_base_disparus" inclure="agenda_pipelines.php" />
	<pipeline nom="post_edition" inclure="agenda_pipelines.php" />
	<pipeline nom="post_edition_lien" inclure="agenda_pipelines.php" />
	<pipeline nom="quete_calendrier_prive" inclure="agenda_pipelines.php" />
	<pipeline nom="revisions_chercher_label" inclure="agenda_pipelines.php" />
 

A l’usage, des restrictions

Il n’est pas possible actuellement d’obtenir en saisie un accès direct à l’évènement sans passer par l’article auquel il est obligatoirement lié, mais il ne comporte pas d’indicateur de rubrique (utile pour la protection par Accès Restreint).
Comment contrôler la répétitivité (restreindre sur une durée, trimestre ou année..), ou étendre certaines périodicités (le 1° mardi de chaque mois....)..
L’inscription en ligne n’est pas utilisable sauf dans l’espace public, et uniquement pour l’auteur authentifié (aucune correction par un webmestre par exemple..).
Il n’est pas prévu de proposer des rôles complémentaires dans le code #REPONSE(ou pourrait proposer une liste en cfg /sachant que les choix ne devraient jamais etre modifiés/ : un autre champ à ajouter ?
Possibilité supplémentaire : pouvoir affecter un evenement à tout objet (par les deux champs : objet et id_objet, ou par une table de liens, offrant encore plus de possibilités multiples

La Configuration

Comme pour tout plugin, un écran de configuration d’un seul tenant :
-  configurer_agenda qui utilise aussi

  • migrer_agenda (un outil utiliser une fois !)
  • configurer_calendriermini /reprenant Calendrier_mini

Améliorations pratiques

Découper l’écran de configuration en plusieurs onglets (éliminant l’outil de conversion qui ne sert qu’une fois...)
-  éliminer par configuration l’obligation d’un article
-  etape intermédiaire : fixer les trois réponses dans une variable
-  ajouter le choix (optionnel /par article) d’une rubrique de rattachement
-  valider le filtrage par AccesRestreint sur #id_rubrique (automatique si existe ??)
Externaliser la fonctionnalité d’inscription (qui correspond presque au « doodle » bien connu) dans un plugin en dépendance ?