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 :
- les boucles et leurs balises, les balises hors boucles,
- les formulaires, les modèles,
- divers trucs et astuces tout au long.
À 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 ».
v2.2 | v2.1 | remarques |
---|---|---|
(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.
v2.2 | v2.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.
- "faire" (graduellement si les outorisations ne sont pas surchargées) :
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 :
- Pour changer la présentation d’un formulaire, il suffit de déposer dans votre
squelettes/formulaires
un fichier homonyme.html
qui redispose les champs a votre convenance. - Pour seulement le « styler », il faut plutôt se tourner vers
squelettes/perso.css
: le plugin respecte la structure classique des formulaires SPIP, organisés de façon visiblement logique, et avec explications et autres... - Pour modifier le comportement, il suffit de surcharger dans votre
squelettes/formulaires
le fichier homonyme.php
avec les fonctions PHPformulaires_
homonyme_charger()
,formulaires_
homonyme_verifier()
etformulaires_
homonyme_traiter()
- Pour insérer un de ces formulaires dans un squelette, il suffit de faire appel à la balise
#FORMULAIRE_
action_truc(s){
ValParam1,
ValParam2,
...,
ValParamN}
(exactement comme les formulaires natifs !) ; et on peut aussi les appeler dans un article en utilisant le raccourci<formulaire|
action_truc(s)|
NomParam1=
ValParam1|
NomParam2=
ValParam2|
...|
NomParamN=
valParamN>
(il s’agit en fait d’un modele natif de SPIP 2.1 !) Que du bonheur...
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...
formulaire | table | paramètres (champs-clés) dans l’ordre | pré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...
formulaire | tables | paramè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...
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.
formulaire | table | paramè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 tablesadresses
(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 tabletelephones
(numero
).
-
Discussions par date d’activité
4 discussions
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 :
asso_comptes.journal
asso_dons.id_don
pour les dons,asso_membres.id_auteur
pour les cotisations, etc.) et l’inscrit dansasso_comptes.id_journal
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)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 le1
pour les cotisations et le2
pour les dons...)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
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 :
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 tablespip_asso_activites
(et donc la boucle sur(ASSO_ACTIVITES)
ici) est une table de liaison : les informations sur les « activités » sont dansspip_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 doncdate_debut
de l’événement soit comprise entre lesdate_debut
etdate_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 ;-))
date_fin
de l’événement soit comprise entre lesdate_debut
etdate_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} >
date_inscription
de l’activité (au niveau de la liaison cette fois-ci) soit comprise entre lesdate_debut
etdate_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.htmlPS0 : 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
Merci pour cette excellente documentation.
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
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 :#SET{total_participants,0}
et#SET{total_encaissements,0}
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>
(2) : [(#SET{total_participants,[(#GET{total_participants}|plus{#QUANTITE})]})] ; [(#SET{total_encaissements,[(#GET{total_encaissements}|plus{[(#QUANTITE|mult{#PRIX_UNITAIRE})]})]})] ; etc.
en (1) ou en (3) : #TOTAL_BOUCLES inscriptions ; #GET{total_participants} places payées pour un total de #GET{total_encaissements} € ; 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)
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 :
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.
Suivre les commentaires : |