Exploitation d’Associaspip 2 par les webmestres

Attention ! Ceci n’est pas une documentation pour installer ou utiliser le plugin, mais un « memento » à l’usage des webmestres et intégrateurs qui souhaitent écrire des squelettes/noisettes exploitant Associaspip2.

Au menu :

À table !

Associaspip2 utilisant l’API [SQL] de SPIP2, outre ce qui est prévu en privé, on peut en faire des choses imprévues en public. Le plugin étant conséquent, on peut dire qu’il y à boire et à manger. Sans plus attendre, mettons le couvert.

Les _(BOUCLE)s et #BALISEs/{criteres} disponibles

Le passage en 2.2 fut l’occasion d’harmoniser le nommage des champs. C’est pourquoi les balises sont présentées en tableau mettant en regard les anciennes avec les nouvelles.

Voici la liste des tables/boucles rajoutées/disponibles : asso_activites, asso_categories, asso_comptes, asso_destination, asso_destination_op, asso_dons, asso_exercices, asso_fonctions, asso_groupes, asso_membres, asso_plan, asso_prets, asso_ressources, asso_ventes.
Elles sont réparties en deux catégories/tableaux. Les tableaux sont ordonnés par boucles, puis par balises nouvelles (première colonne) suivi des anciennes (seconde colonne) supprimée.

La première catégorie a un #ID_TRUC qui lui est propre (table "spip_asso_truc(s)" excepté pour les destinations et codes comptables) et sert de « clé primaire ».

unique ID propre
v2.2v2.1remarques
 
(ASSO_CATEGORIES)
#COMMENTAIRE #COMMENTAIRES
#DUREE
#ID_CATEGORIE
#LIBELLE
#MAJ
#PRIX_COTISATION #COTISATION
#VALEUR
(ASSO_COMPTES)
#DATE_OPERATION #DATE
#DEPENSE
#ID_COMPTE
#ID_JOURNAL C’est l’ID correspondant à l’objet/entité de la boucle qui utilise exclusivement ce code d’imputation
#IMPUTATION (ASSO_PLAN){code}
#JOURNAL Est un (ASSO_PLAN){code}
#JUSTIFICATION
#MAJ
#RECETTE
#VU Vaut : 0 (éditable) ou 1 (véroullé)
(ASSO_DESTINATION)
#ID_DESTINATION
#INTITULE
#COMMENTAIRE
#MAJ
(ASSO_DONS)
#ARGENT
#COLIS
#COMMENTAIRE
#CONTREPARTIE
#DATE_DON
#ID_AUTEUR #ID_ADHERENT (ASSO_MEMBRES){id_auteur} ou...
#ID_DON
#MAJ
#NOM #BIENFAITEUR
#VALEUR
(ASSO_EXERCICES)
#COMMENTAIRE
#DATE_DEBUT
#DATE_FIN
#ID_EXERCICE
#INTITULE
(ASSO_GROUPES)
#AFFICHAGE
#COMMENTAIRE
#ID_GROUPE
#MAJ
#NOM
(ASSO_MEMBRES)
#COMMENTAIRE
#DATE_VALIDITE #VALIDITE
#ID_CATEGORIE #CATEGORIE (ASSO_CATEGORIES){id_categorie}
#ID_ASSO
#ID_AUTEUR ...(AUTEURS){id_auteur}
#MAJ
#NOM_FAMILLE
#PRENOM
#SEXE
#STATUT_INTERNE Vaut : prospect (futur membre potentiel) ou ok (membre actif en règle) ou echu (membre actif dont l’adhésion est arrivé à échéance mais n’a pas été relancé) ou relance (membre actif dont l’adhésion est arrivé à échéance et qui a été relancé) ou sorti (membre exclu ou désactivé)
#FONCTION À partir de la 2.2 les fonctions sont gérés par la liaison aux groupes, permettant de spécifier plus finement des multiples rôles d’un membre.
#ADRESSE À partir de la 2.2 l’interface avec le plugin Coordonnés permet de gérer ces autres informations de façon plus fine.
#CODE_POSTAL
#EMAIL
#MOBILE
#TELEPHONE
#VILLE
(ASSO_PLAN)
#ACTIVE Vaut : 0 (compte inactif) ou 1 (compte actif)
#CLASSE
#CODE Référence du plan comptable utilisé dans le livre des comptes.
#COMMENTAIRE
#DATE_ANTERIEURE
#ID_PLAN
#INTITULE
#MAJ
#SOLDE_ANTERIEUR
#TYPE_OP Vaut : credit ou debit ou multi. S’appelait #DIRECTION
(ASSO_RESSOURCES)
#CODE
#COMMENTAIRE
#DATE_ACQUISITION
#ID_RESSOURCE
#INTITULE
#MAJ
#PRIX_ACQUISITION
#PRIX_CAUTION
#PU
#UD Vaut : Y (un an) ou M (un mois) ou W (une semaine) ou D (un jour) ou H(une heure)
#STATUT À partir de la version 2.2 c’est le nombre (entier) d’exemplaires présents : 0 quand il n’y a plus d’exemplaire disponible (tous réservés), positif s’il y a des exemplaires disponibles, mais négatif s’il y a des exemplaires mais que la réservation est suspendue. Avant (un seul exemplaire) cela valait : ok (disponible) ou reserve ou suspendu ou sorti (supprimé)
(ASSO_VENTES)
#ARTICLE
#CODE
#COMMENTAIRE
#DATE_ENVOI
#DATE_VENTE
#FRAIS_ENVOI
#ID_AUTEUR #ID_ACHETEUR (ASSO_MEMBRES){id_auteur} ou...
#ID_VENTE
#MAJ
#NOM #ACHTEUR
#PRIX_UNITAIRE #PRIX_VENTE
#QUANTITE

La seconde catégorie relie toujours deux tables/objets et pour plusieurs occurences de part et d’autre (ainsi, la table des membres qui lie un auteur a une seule catégorie est essentiellement une extension de la table des auteurs.) Sa « clé primaire » est formée par la concaténation des deux « clés étrangères » nécessaires à la liaison.

double ID de liaisons
v2.2v2.1 liaison et notes
 
(ASSO_ACTIVITES)
#COMMENTAIRE
#DATE_INSCRIPTION #DATE
#DATE_PAIEMENT
#ID_AUTEUR #ID_ADHERENT (ASSO_MEMBRES){id_auteur} ou...
#ID_EVENEMENT (EVENEMENTS){id_evenement}
#MAJ
#NOM
#PRIX_UNITAIRE #MONTANT
#QUANTITE #INSCRITS À partir de la 2.2 il s’agit du « nombre total de places/tarifs réservées/achetés ». Avant c’était le « nombre d’invités »
#ADRESSE À partir de la 2.2 ces champs sont retiré car ces informations sont attachées au membre (via Champs Extras 2 ou Coordonnées qui sont gérés).
#EMAIL
#TELEPHONE
#ID_ACTIVITE À partir de la 2.2 ces champs sont retirés car non essentiels (mais si on en a besoin on peut les restituer avec Champs Extras 2 qui est géré).
#MEMBRES
#NON_MEMBRES
#STATUT
(ASSO_DESTINATION_OP)
#DEPENSE
#ID_COMPTE (ASSO_COMPTES){id_compte}
#ID_DEST_OP
#ID_DESTINATION (ASSO_DESTINATION){id_destination}
#RECETTE
(ASSO_FONCIONS)
#ID_GROUPE (ASSO_GROUPES){id_groupe}
#ID_AUTEUR (ASSO_MEMBRES){id_auteur}
#FONCTION
#MAJ
(ASSO_PRETS)
#COMMENTAIRE_RETOUR
#COMMENTAIRE_SORTIE
#DATE_CAUTION1 Dépôt de la caution
#DATE_CAUTION0 Restitution de la caution
#DATE_RESERVATION non encore utilisé
#DATE_RETOUR
#DATE_SORTIE
#ID_AUTEUR #ID_EMPRUNTEUR (ASSO_MEMBRES){id_auteur} ou...
#ID_PRET Bien que dans cette seconde catégorie (liaison entre auteurs et ressources mais non discriminante), ce champ est conservé pour faciliter le code interne.
#ID_RESSOURCE (ASSO_RESSOURCES){id_ressource}
#DUREE Nombre de #UD facturé.
#MAJ
#NOM
#PRIX_CAUTION #PRIX_CAUTION applicable au moment de la location.
#PRIX_UNITAIRE #PU appliquable au moment de la location.
#STATUT Probablement utilisé pour savoir l’état de la réservation ? La version 2.2 vérifie simplement qu’une date de retour est renseignée pour savoir que le bien est restitué ; la date de restitution prévue s’obtenant elle en ajoutant la durée de réservation à la date de sortie du bien.

Attention cependant lors de la réalisation de vos squelettes : dans l’espace privé, des contrôles d’accès assez pointus sont realisés par Associaspip ; mais c’est au webmestre de s’en préoccuper pour ne pas exposer les données à n’importe quel public...
À ce propos, on peut avoir recours à #AUTORISER, dont (si on veut utiliser les autorisations d’accès du privé) :

  • le second argument (« ou » au sens ici de « quel plugin » et non « dans/pour quel objet ») est toujours association (car c’est le préfixe du plugin) ;
  • le premier argument (« action » au sens de « faire_quoi ») se décompose toujours comme suit :
    • "faire" (graduellement si les outorisations ne sont pas surchargées) : voir (lire seulement les champs affichés dans la fiche ou la liste), exporter (lire tous les champs disponibles et générer le PDF ou autre fichier d’exportation), editer (modifier tous les champs ou supprimer des enregistrements), gerer (aussi bien éditer que configurer)
    • « quoi » (alphabétiquement) : activites (inscriptions/participations aux activités), compta (livres de compte), dons (donations manuels), groupes (groupes d’utilisateurs), membres, prets (de ressources), profil (de l’association), ressources, ventes (associatives), pour l’instant.

Les autres balises...

Depuis la version 2.0 les nombreux paramètres de configuration/fonctionnement sont stockés dans une table particulière (sur laquelle on ne peut pas boucler...) : spip_association_metas. Pour accéder à la valeur du paramètre truc, il faut utiliser #META{/association/truc}. Les différents paramètres qui ont été conservés d’une version à une autre sont :

  • Pour le profil de l’association (valeur texte)
    • nom : son nom,
    • rue : la voie de l’adresse postale,
    • cp : le code postal,
    • ville : la localité postale,
    • email : l’adresse de courriel de contact,
    • telephone : le numéro de téléphone de contact,
    • declaration : la date ou le numéro d’officialisation,
    • prefet : autorité ayant officialisé,
  • Pour les onglets actifs (valeur booléenne : contien "on" si actif, et vide sinon)
    • comptes : La comptabilité,
    • ventes : les ventes de l’association,
    • dons : les dons manuels,
    • activites : les activités associatives,
    • prets : les ressources et leurs prêts,
  • Les principaux paramètres de la configuration comptable associée (valeur numérique normalement)
    • classe_banques : la classe des comptes financiers,
    • pc_activites : le compte d’imputation des recettes des participations aux activités,
    • pc_cotisations : le compte d’imputation des cotisations,
    • pc_dons : le compte d’imputation des dons en argent,
    • pc_prets : le compte d’imputation des rectettes de locations,
    • pc_ventes : le compte d’imputation des recettes de ventes associatives,
  • Autres paramètres comptables (numériques sauf premier) à partir de la 2.1
    • destinations : activation ("on") ou non (vide) de l’utilisation des destinations comptables
    • dc_cotisation : la destination comptable par défaut pour les cotisations,
    • dc_dons : la destination comptable par défaut pour les dons,
    • dc_ventes : la destination comptable par défaut pour les ventes,
    • pc_frais_envoi : le compte d’imputation des frais d’envoi,
  • Concernant les membres (booléens sauf dernier) à partir de la 2.1
    • civilite : utiliser la civilité,
    • prenom : utiliser le prénom,
    • id_asso : utiliser la référence interne,
    • import_nom_auteur : indique comment traiter la signature des auteurs SPIP lors de l’importation ; il vaut « » (nom de famille et prénom), "prenom_nom« (prénom et nom de famille), »nom" (nom de famille seul)

La balise #META va de pair avec #CONFIGURER_METAS, dont vous n’aurez pas usage et qui est appelée a disparaitre dans le futur (déja la version 2.2 ne l’utilise presque pas et tout le mécanisme nécessaire est intégré dans SPIP 3.0.)

Avec SPIP 3.0 justement, il est possible d’utiliser la balise #CONFIG de la meme facon que la #META !

Avec l’arrivée des destinations comptables est apparue la balise #EDITEUR_DESTINATIONS qui prend respectivement : le tableau des destinations affectées, le tableau des montants respectifs, et la destination par defaut... En fait cette balise dynamique s’appelle sans arguments et les prend dans le contexte créé par le chargement du formulaire.

Des noisettes à #INCLURE au festin

La version 2.2 a été ré-écrite dans l’optique de permettre une personnalisation facile par simple surcharge.
Attention : il ne faut pas oublier en appliquant cela que l’on modifie aussi l’affichage (et/ou le comportement) dans l’espace privé !

Outre la surcharge, des briques de construction du privé peuvent s’utiliser dans vos squelettes avec le mecanisme d’inclusion général ou des balises magiques pour ceux de certains répertoires précis.

Les #FORMULAIREs

Comme pour les versions précédentes, il y a toujours des formulaires calculées dynamiquement et qui ne sont pas surchargeables. Ce sont surtout les formulaires sur le côté pour générer un PDF ou autre format d’exportation, ainsi que ceux des filtres pour affiner l’affichage des listes principales.

Les principaux formulaires d’édition (modification ou ajout) d’un objet du plugin, qui apparaissent dans la zone/colonne principale/centrale d’une page d’édition de l’espace privé utilisent dorénavant le mécanisme HTML/CVT ! Un découpage en quatre pour quatre avantages :

On distingue tout d’abord les formulaires pour ajouter ou modifier un enregistrement (editer_asso_truc) ou plusieurs (editer_asso_trucs) dans une table (spip_asso_trucs). Pour les tables de liaisons, c’est la liaison dans un seul sens qui est retenu...

formulaires d’édition CVT
formulairetableparamètres (champs-clés) dans l’ordreprécisions
#FORMULAIRE_EDITER_ASSO_ACTIVITE asso_activites id_activite temporairement... ici il s’agit d’enregistrer et/ou valider la participation (paiement des frais) d’un membre à un événement...
#FORMULAIRE_INSCRIPTION_EVENEMENT id_evenement, id_auteur (pris dans la session) ici il s’agira juste pour un membre (auteur de la session) de s’enregistrer pour un événement... (ce formulaire surcharge celui de Agenda 2)
#FORMULAIRE_EDITER_ASSO_CATEGORIE asso_categories id_categorie  
#FORMULAIRE_EDITER_ASSO_COMPTE asso_comptes id_compte  
asso_destination_op Les destinations sont en fait éditées dans divers formulaires nécessitant un paiement par l’utilisation de #EDITEUR_DESTINATIONS...
#FORMULAIRE_EDITER_ASSO_DESTINATION asso_destination id_destination  
#FORMULAIRE_EDITER_ASSO_DON asso_dons id_don  
#FORMULAIRE_EDITER_ASSO_EXERCICE asso_exercices id_exercice  
#FORMULAIRE_EDITER_MEMBRES_GROUPE asso_fonctions id_groupe ici (nom temporaire) on édite les fonctions des membres d’un groupe
#FORMULAIRE_EDITER_MEMBRE_GROUPES id_auteur ici (nom temporaire) on éditera les fonctions d’un membre dans différents groupes
#FORMULAIRE_EDITER_ASSO_GROUPE asso_groupes id_groupe  
#FORMULAIRE_EDITER_ASSO_MEMBRE asso_membres id_auteur  
#FORMULAIRE_EDITER_ASSO_PLAN asso_plan id_plan  
#FORMULAIRE_EDITER_ASSO_PRET asso_prets id_pret  
#FORMULAIRE_RESERVER_RESSOURCE id_ressource, id_auteur (pris dans la session) ici il s’agira de se mettre en liste d’attente...
#FORMULAIRE_EDITER_ASSO_RESSOURCE asso_ressources id_ressource  
#FORMULAIRE_EDITER_ASSO_VENTE asso_ventes id_vente  
#FORMULAIRE_COMMANDER_ARTICLE article, id_auteur (pris dans la session) sert à passer commande...
#FORMULAIRE_EDITER_ASSO_META_UTILISATEUR association_metas nom_meta_ut Pour gérer des constantes propres au profil de l’association
#FORMULAIRE_CONFIGURER_ASSOCIATION Pour gérer les informations de base de l’association et les options de fonctionnement du plugin

On a aussi des formulaires pour seulement ajouter un enregistrement (editer_asso_truc) ou plusieurs (editer_asso_trucs) dans une table (spip_asso_trucs). Pour les tables de liaisons, c’est aussi la liaison dans un seul sens (toujours le même) qui est retenu...

formulaires d’ajout CVT
formulairetablesparamètres (champs-clés) dans l’ordreédition
#FORMULAIRE_AJOUTER_COTISATION asso_membres (date de validite), asso_comptes (montant, date, justificatif, etc.) et asso_destination_op (s’il faut gérer les destinations comptables) id_auteur (le cotisant), nom_prenom (inséré dans le justificatif), id_categorie (montant de base et allongement de la durée de validité), validite (date de validité antérieure), editable. En fait on pourrait n’utiliser que id_auteur et id_categorie ...mais on garde tous ces arguments par rétro-compatibilité ! #FORMULAiRE_EDITER_ASSO_COMPTE
#FORMULAIRE_AJOUTER_MEMBRES_GROUPE asso_fonctions id_groupe #FORMULAIRE_EDITER_MEMBRES_GROUPE

On a aussi des formulaires de « synchronisation » (entre une table Associaspip et une table n’appartenant pas au plugin) et qui pour l’instant ne fonctionne que dans le sens de l’importation...

formulaires de synchronisation CVT
formulaire table interne (Associaspip) table externe (plugin)
FORMULAIRE_SYNCHRONISER_ASSO_MEMBRES asso_membres auteurs (natif)
#FORMULAIRE_SYNCHRONISER_ASSO_ACTIVITES asso_activites evenements_inscriptions (Agenda 2)

On a enfin des inclassables qui, pour l’instant, n’ont pas besoin de paramètres.

formulaires CVT divers
formulairetableparamètres et remarques
#FORMULAIRE_PARAMETRER_ETIQUETTES assotiation_metas
#FORMULAIRE_MAILING_MEMBRES

Comme déjà dit (pour les données des tables), en exposant les formulaires en public il faut penser a gérer la sécurité soi-même : en plus d’être visibles, elles sont de plus modifiables...
Le même souci se pose avec les données en lecture (balises hors formulaires) mais crayonnables par les utilisateurs authentifiés... Bien que Crayons s’en sorte bien en gênêral, on perd quand même le benefice des acces finement configures car Associaspip ne lui prevoit pas de controleurs.

Les #MODELEs

Certains blocs de l’espace privé utilisent dorénavant le mécanisme des modèles pour offrir les trois avantages suivants :

  • On peut les insérer directement dans un squelette en appelant la balise [(#MODELE{truc(s)}{NomParam1=ValeurParam1}{NomParam2=ValParam2}{...}{NomParamN=ValParamN})] Mais surtout on peut les utiliser comme raccourcis : <truc(s)|NomParam1=ValParam1|NomParam2=ValParam2|...|NomParamN=ValParamN> ! Le pied pour les rédacteurs qui savent...
  • Pour adapter le code HTML d’un modele (réordonner les informations par exemple), il suffit de déposer dans votre squelettes/modeles le fichier homonyme.html modifié qui surchargera celui du plugin.
  • Pour seulement le « styler », il faut plutôt se tourner vers squelettes/perso.css ; ce sont les classes microformat et ceux de SPIP (notamment pour les liens et les tableaux) qui sont utilisées.

Pour ses tables (spip_asso_trucs) à boucles, la convention de nommage adoptée est similaire a celle des formulaires, et la mise en page convenue :

  • Pour un enregistrement (asso_truc) le(s) paramètre(s) requis sera toujours la « clé primaire»i;. La fiche y présentera les autres données (la clé primaire est donc exclue) sous forme de liste de définitions avec les noms de champs traduits (intitulés) et les clés etrangeres remplacées par le titre/libellé correspondant.
  • Pour plusieurs enregistrements (asso_trucs —exemple : asso_ressources) on utilisera tous les critères demandés (test d’egalité !). Le résultat (listing) sera presenté sous forme tabulaire simple. Deux paramètres supplémentaires sont utilisés lorsque disponibles : tri pour le(s) champ(s) par le(s)quel(s) les enregistrements sont classés chronologiquement ; pagination pour le pas de pagination (i.e. nombre de résultats affichés à la fois).
  • Pour plusieurs enregistrements d’une table de liaison, on convient de suffixer par la partie de la liaison sur laquelle on se base (asso_trucs_sens2liaison —exemple : asso_fonctions_groupe) et on utilisera cette seule clé primaire ! Le résultat (listing) sera presenté sous forme tabulaire.

En dehors de ces modèles (présents ou à venir —donc nomenclature réservée) liés aux boucles, on trouvera :

  • Pour Associaspip
    • asso_profil qui s’utilise sans argument et qui affiche la présentation de l’association telle que renseignée dans la configuration, ainsi que les métas utilisateurs définis.
  • Pour Coordonnées
    • coordonnees_adresse pour la présentation des adresses postales issues du plugin. Les paramètres sont les principaux champs de la tables adresses (voie, complement, boite_postale, code_postal, ville, region) ainsi que : nom_pays pour le nom complet du pays ; _nl pour les caractères de saut de ligne ; _ht pour les caractères d’espacement horizontal.
    • coordonnees_telephone pour la présentation des numeros de telephone issus du plugin. Les paramètres sont les principaux champs de la table telephones (numero).

Discussion

4 discussions

  • 4
    afestorg

    Boucle historique membre

    Bonjour,

    Sur Associaspip 2.2.

    J’arrive sans difficulté à rassembler sur une même fiche d’adhérent les informations relatives aux coordonnées et aux inscriptions aux activités.

    Par contre je n’arrive pas à avoir aussi, pour chaque membre, l’historique des cotisations et dons, que ce soit par exercice ou depuis le début de l’adhésion. (J’ai des exercices personnalisés aussi bien par trimestre que par année).

    En effet, je ne vois pas la ou les liaisons entre les tables ASSO_COMPTES, ASSO_MEMBRES (voire ASSO_DESTINATION_OP) à faire pour cet affichage.

    A moins de savoir extraire une partie des données du champ justification ?

    D’autant que, dans l’espace privé, je ne vois pas non plus de moyen d’avoir toutes ces informations (l’historique total ou partiel) sur une même page.

    Merci de votre aide

    P.S. Et je suis un peu « coincé » car au départ j’ai, par erreur installé la version 2.2 au lieu de la 2.1 et cela fait plusieurs mois que mon association travaille avec. Et un retour "en arrière est in-envisageable. Donc j’espère que vous pourrez me donner une piste ?

    • Bonjour.

      Pour les liaisons avec la comptabilité, il faut que je complète la documentation :

      • chaque module utilise la référence référence comptable configurée et l’inscrit dans asso_comptes.journal
      • chaque opération d’un module a un numéro interne (par défaut asso_dons.id_don pour les dons, asso_membres.id_auteur pour les cotisations, etc.) et l’inscrit dans asso_comptes.id_journal
      • il n’y a pas de table de liaison car cette paire (normalement unique) constitue une clé étrangère qui permet d’avoir l’historique
      • dans le justificatif, on essaye de mettre (en début) quelque chose comme donX etc. mais je ne sais pas si ça peut permettre de faire une extraction en se basant sur cette information (mais un tel squelette ne sera pas portable car les termes seront traduits)
      • pour limiter aux exercices, il faut ensuite filtrer sur comptes.date_operation

      Normalement, sur chaque page de membre, on a son historique partiel (limité à l’exercice/année choisie). Ça fonctionne plus ? Si c’est pas le cas, c’est qu’il y a un bug récent : faut que je vérifie ça.

    • P.S1 : Le principe est le même en 2.2 et 2.1 (sauf que avant on ne gérait pas les exercices personnalisés)

      P.S2 : Les historiques sont affichés dans l’espace privé grâce aux squelettes prive/logasso_?.html (de mémoire le 1 pour les cotisations et le 2 pour les dons...)

    • afestorg

      Merci pour ces précisions.

      J’ai vu en effet les squelettes prive/logasso_X.html (1 cotisations, 2 dons, 3 achats, 4 activités, 5 prêts) qui sur mon site n’affichent qu’une page vide.

      J’ai peut-être une version un peu (trop) ancienne. Je n’ai pas systématiquement mis à jour les versions quand j’ai tardivement réalisé que j’étais sur une version en développement, craignant en cas de problème de ne pas pouvoir revenir en arrière. Je vais quand même m’y risquer.

    • Bonjour.

      Concernant les squelettes prive/logasso_?.html elles sont appelées avec des paramètres obligatoires (fournis par la page de l’espace privé) : periode_au, periode_du, id_auteur... Sinon effectivement le résultat renvoyé sera vide !
      Je citais ces squelette juste comme exemple car répondant à la question des boucles pour l’historique, mais ils ne fonctionnent pas magiquement sans paramètres.
      Je confirme bien que ça fonctionne dans l’espace privé (page d’un membre) et il y a un sélecteur qui permet d’indiquer l’exercice pour lequel on veut afficher l’historique.

      Concernant les mises à jour, c’est la bonne démarche pour un site en production... Pour les autres, il faut mettre à jour régulièrement et remonter les régressions et nouveaux bogues afin que ce soit corrigé rapidement.

    Répondre à ce message

  • 2

    Aide sur restriction des résultats d’une boucle à un exercice donné

    Bonjour,

    Je cherche à afficher les résultats d’une boucle uniquement sur un exercice donné.
    Je ne sais pas où placer mes critères date_debut et/ou date_fin pour que cela marche. Divers essais me donnent soit une page blanche soit des résultats hors exercice.

    Pouvez-vous me conseiller ?

    Merci

    Ma boucle :

    <BOUCLE_exercice (ASSO_EXERCICES) {id_exercice=3}>
    <BOUCLE_activite (ASSO_ACTIVITES) {par id_auteur}{prix_unitaire>50}>
    <BOUCLE_nom (ASSO_MEMBRES){id_auteur}{doublons}>
    [(#SEXE)]&nbsp; [(#NOM_FAMILLE)]&nbsp; [(#PRENOM)] <br />
    [(#ADRESSE_MEMBRE)]
    </BOUCLE_nom>
    <BOUCLE_evenement (EVENEMENTS) {id_evenement}>
    <li>  [(#TITRE)] 
    </BOUCLE_evenement>	inscription le [(#DATE_INSCRIPTION|affdate)] -  Montant : [(#PRIX_UNITAIRE)]
    </li> 
    <br />
    </BOUCLE_activite>
    </BOUCLE_exercice> 
    • Salut afestorg

      Je suppose que la boucle qu’on veut afficher en fonction de l’exercice est _activite ; donc oui, en le mettant à l’intérieur de la boucle _exercice on devrait arriver à quelque chose. Le problème ici est que la table spip_asso_activites (et donc la boucle sur (ASSO_ACTIVITES) ici) est une table de liaison : les informations sur les « activités » sont dans spip_asso_evenements (les activités sont juste des événements de Agenda —bon, normalement ceux qui font sens comme tel pour l’association mais c’est là une autre histoire) et donc

      • pour avoir les activités qui ont débuté dans cette période/exercice, il faut que la date_debut de l’événement soit comprise entre les date_debut et date_fin de l’exercice.
        Soit : <BOUCLE_activite (ASSO_ACTIVITES EVENEMENTS) {par id_auteur}{prix_unitaire>50} {date_debut>#_exercice:DATE_FIN} {date_debut<#_exercice:DATE_DEBUT} >
        (c’est ce qui est fait dans le fichier prive/logasso_4.html du plugin  ;-))
      • pour avoir les activités qui se sont terminées dans cette période/exercice, il faut que la date_fin de l’événement soit comprise entre les date_debut et date_fin de l’exercice.
        Soit : <BOUCLE_activite (ASSO_ACTIVITES EVENEMENTS) {par id_auteur}{prix_unitaire>50} {date_fin>#_exercice:DATE_DEBUT} {date_fin<#_exercice:DATE_FIN} >
      • pour avoir les inscriptions aux activités dans cette période/exercice, il faut que la date_inscription de l’activité (au niveau de la liaison cette fois-ci) soit comprise entre les date_debut et date_fin de l’exercice.
        Soit : <BOUCLE_activite (ASSO_ACTIVITES EVENEMENTS) {par id_auteur}{prix_unitaire>50} {date_inscription>#_exercice:DATE_DEBUT} {date_inscription<#_exercice:DATE_FIN} >
        dans ce dernier cas, il n’est pas nécessaire d’établir une « jointure » avec les événements (donc <BOUCLE_activite (ASSO_ACTIVITES) {par id_auteur}{prix_unitaire>50} {date_inscription>#_exercice:DATE_DEBUT} {date_inscription<#_exercice:DATE_FIN} > tout simplement) mais par contre c’est utile si on doit exploiter ensuite les éléments de l’événement (donc la boucle _evenement plus loin juste pour avoir le titre n’est plus nécessaire, et ceci est valable pour les cas précédant aussi !)
    • PS1 : La notation #_exercice:DATE_FIN permet de s’assurer que l’on utiliser bien la balise de la boucle <code_exercice (donc adapter selon le nom de la boucle...) C’est expliqué à l’adresse http://www.spip.net/fr_article899.h...

      PS2 : La syntaxe (ASSO_ACTIVITES EVENEMENTS) est celle des jointures (à manier avec délicatesse...) C’est expliqué à l’adresse http://www.spip.net/fr_article4254.html

      PS0 : J’ai juste exposé le principe dans ma réponse ; je n’ai pas testé les codes que j’ai donné (mais je pense que ça devrait marcher sans grand souci)

    Répondre à ce message

  • 4

    Merci pour cette excellente documentation.

    • spipfactory

      ouafffffffffffff quel taf , vivement la sortie spip 3

    • Bon outil que cet article. Je proposerai quelques modèles pour l’accompagner. Il doit déjà y en avoir un pour les emprunts à l’association. Il doit être possible de le compléter avec les dates de restitution pour exemple.

    • Bonjour à tous.

      Cette documentation a vu le jour parce-que la question s’est posée sur le forum : il y en a qui veulent exploiter les boucles (espace public) mais ne savent pas quelles sont les balises (il faut pour cela trouver le bon fichier dans le code source et le comprendre) et quand on a trouvé, on ne sait pas forcément quelles sont leur(s) usage(s) sauf à parcourir le code (ou deviner et faire quelques essais).

      Cette documentation est incomplète : je prévois en effet de parler des modèles natifs du plugin, mais aussi des constantes et des noisettes... Mais comme pour les boucles, j’attends que ce soit stabilisé (et de trouver le temps aussi...)

    • C’est fait ; il y a les modèles (décrits de façon générale car ils fonctionneront de la même façon —et il faut que je corrige ceux existants) et les formulaires. Mais il y aura encore probablement quelques petites corrections/adaptations à faire dans le code pour que la doc soit bonne.

    Répondre à ce message

  • 3
    Horetol

    Bonsoir,

    Peut-être un peu hors-sujet.
    Pour l’espace public, j’ai créé un tableau reprenant les inscriptions aux divers événements (Activités).
    Je n’arrive pas à calculer le total des participants et des encaissements , même avec Spip-Bonux activé et avec #SOMME.

    Donc je regarde le code du cartouche de gauche de inscrits_activite.php pour voir comment c’est calculé, mais ces 3_ à 41 lignes ne me donnent pas de solution pour une BOUCLE_n Spip.

    Avez-vous une piste à me suggérer ?

    • Les pages exec/*.php du plugin sont en PHP et font directement appel au SQL en utilisant la dbAPI de SPIP ; du coup le code de la cartouche ne sera pas très utile pour écrire une boucle...

      Là, tout de suite, ce qui me vient à l’esprit (sachant que je ne connais pas la balise #SOMME de Bonux et que peut-être qu’on peut faire plus simple avec) c’est :

      1. définir, en dehors de la boucle, une variable pour accueillir chaque total : #SET{total_participants,0} et #SET{total_encaissements,0}
      2. Ensuite boucler selon les critères qu’on veut (au moins le id_evenement de l’événement qui nous intéresse) : <B_n> ...(1)... <BOUCLE_n(ASSO_ACTIVITES){id_evenement}> ...(2)... </BOUCLE_n> ...(3)... </B_n>
      3. Maintenant, dans la boucle, on va incrémenter nos variables précédemment définis : (2) : [(#SET{total_participants,[(#GET{total_participants}|plus{#QUANTITE})]})] ;  [(#SET{total_encaissements,[(#GET{total_encaissements}|plus{[(#QUANTITE|mult{#PRIX_UNITAIRE})]})]})] ; etc.
      4. À la sortie de la boucle, y a plus qu’à afficher ce résultat : en (1) ou en (3) : #TOTAL_BOUCLES inscriptions ; #GET{total_participants} places payées pour un total de #GET{total_encaissements} &euro; ; etc.
    • Bon, je viens de trouver (ce n’est pas documenté, donc sauf à lire et comprendre le code ou avoir l’information par ailleurs...) : il faut le critère pour pouvoir utiliser la balise et inversement.
      Par exemple : <BOUCLE_n(ASSO_ACTIVITES){id_evenement}{somme quantite}> ... #SOMME{quantite} ... </BOUCLE_n> (bon, j’ai pas essayé mais c’est ce que j’ai cru comprendre)

      N’oubliez pas de nous tenir au courant : d’une part ça peut servir à d’autres qui ont Bonux, mais peut-être aussi plus tard pour le plugin (il est prévu dans les prochaines versions de tout ré-écrire en squelettes)

    • Horetol

      Bonsoir,
      Merci.
      Je confirme que cela fonctionne :-))

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom