Carnet Wiki

Compléments de doc Agenda : Evenements et Participants

Le plugin Agenda pour SPIP 3 propose l’intégration de deux tables pour enregistrer les évènements, et éventuellement les inscriptions de participants, en utilisant le plugin Calendrier Mini.

Cette article entame une documentation plus complète d’Agenda_3 et des remarques pour pouvoir faciliter l’utilisation.

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 0), 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] 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 ?)

La gestion des dates

Théoriquement les date_debut et date_fin d’EVENEMENT sont utilisables avec les critères d’ages standards (rappelés dans la doc Plugin Agenda pour SPIP 1.9 ou Gestion de dates et du calendrier.

Il faut toutefois parfois compléter la syntaxe des critères :

La boucle :
<BOUCLE_classement(ARTICLES evenements){par date_debut}>
ne marche pas.
Il faut utiliser :
<BOUCLE_classement(ARTICLES evenements){par evenements.date_debut}>


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" />
 

Les Autorisations

Les fonctions d’autorisation sont les fonctions standard pour l’objet evenement, définies dans le plugin ./agenda/agenda_autoriser.php[] et toutes surchargeables [2] :
-  Événements :

  • creer_evenement = administrateur complet (ou droit sur l’article),
  • instituer_evenement = article publié ET modifiable,
  • modifier_evenement_dist = (uniquement [91]) droits sur l’article parent, sinon rien !
  • supprimer_evenement,
  • voir_evenement
    -  creerevenementdans_article = modifier l’article ET rubrique (si>0) flagguée ’agenda’
    -  evenementcreer, evenements,

Actuellement :
y’a pas moyen d’autoriser à créer / modifier un évènement (plugin agenda) sans être obligé d’avoir les mêmes droits sur l’article parent ?
je vais déja voir avec les admins restreints pour l’accès à la création / modifications d événements...
petite question : j’ai x admins qui doivent gérer leur propre agenda (4 agendas différents sur 4 articles différents), comment, au niveau des autorisation je peux différencier l’accès des x admins à leur agenda ?

Restrictions et questions

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

Idées d’améliorations

Découper l’écran de configuration en plusieurs onglets (éliminant l’outil de conversion qui ne sert qu’une fois...)
-  corriger le droit à modification (interdit aux Admins et webmestres)
-  é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 ??) [3]

Externaliser la fonctionnalité d’inscription (qui correspond presque au doodle) dans un plugin en dépendance ?

bug modif ?

[1Cette table n’ayant pas d’alias, elle doit être appelée, dans une boucle, avec la syntaxe « physique » en minuscules avec le prefix : spip_evenements_participants. Toutefois, les liaisons automatiques de SPIP y donnent accès dès qu’on utilise conjointement à AUTEURS ou EVENEMENTS

[2La définisiotn standard est suffixée par _dist

[3Ce serait plutot « désactiver le filtrage automatique par Accès restreint » s’il existe ! ??

YannX - Mise à jour :30 janvier 2023 à 11h05min