Mon formulaire est une demande d’adoption pour UN chat (article).
Mon formulaire est présent sur tous les articles (chats).
Lorsque je vais sur l’article d’un chat, je voudrai n’avoir que les demandes d’adoption correspondant à ce chat (réponses en rapport avec l’ID ARTICLE auquel elles sont associées. Pas toutes les demandes d’adoption pour tous les chats.) https://saraa.fr/
il vous faudra créer votre propre modèle en utilisant les boucles, balise et critères propres à formidable.
Attention toutefois une demande d’adoption ca contient potentiellement des données privées… donc pas sur que ce soit le meilleur plan d’afficher les demandes…
D’accord.
Donc un travail un peu conséquent pour un néophyte…
Mais un travail utile sur le long terme !
INFORMATIONS PRIVÉES :
Oui, attention !
Ces informations sont affichées par une boucle (CONDITION){si #SESSION{statut}|=={0minirezo}}
… Ça devrait répondre à la confidentialité.
Seconde question liée :
Ces informations n’ont même pas besoin d’être affichées…
En fait, elles serviront (toujours avec ma boucle CONDITION pour accéder au lien), à pré-remplir les champs des contrats d’adoption générés en PDF soit avec le plugin SPIPDF ou ARTICLEPDF.
Est-ce que ce modèle permettra de transférer ces informations aux squelettes de ces plugins ?
Hum, si ton besoin est de faire des contrats pdf, je suis précisement en train de créer un plugon (qui est fonctionnel d’ailleurs) permettant de génerer des pdf depuis une réponse.
Il est en prod depuis 1 semaine chez une association.
Je l’avais appelà « attestation de participation » mais on pourrait rendre cela plus generique « PDF à envoyer* ».
Oui enfin au départ je voulais surtout élargir les perspectives d’usage à des inscriptions à des evenements qui ne passeraient pas par formidable. Donc j’avais prévu un mecanisme semi generique pour cela. Mais a y reflechir, c’est plus intéressant de rester focus sur formidable
Si j’ai bien compris, il n’y a pas moyen de passer par une jointure parce que les réponses aux formulaires ne disposent pas d’une table de liens ?
Est-ce que cela aurait un intérêt (autre que pour mon cas particulier) de l’envisager dans une prochaine version ?
Je vais essayer de comprendre le principe des modèles…
Est-ce que quelqu’un en aurait un sous le coude, le plus proche possible de mon besoin, à me faire profiter comme base de départ et/ou d’étude ?
« PDF à envoyer* ».
Quel heureux hazard !
Mais je ne suis pas sûr qu’il me convienne (ou que j’en ai besoin) aujourd’hui :
la majorité des informations nécessaires sont issues des articles,
nos formulaires d’adoption ne passent pas par SPIP (le formulaire que j’envisage de créer et associer sera rempli par nos soins à la validation de chaque adoption pour l’édition des contrats),
notre hébergeur (associatif) limite les plugins,
à l’heure actuelle, les contrats sont imprimés pour une signature manuscrite et peuvent être complétés à ce moment-là. (Mais je pense à l’avenir et au suivi des adoptions !)
Comment je fais pour télécharger ton plugin ?
En tout cas merci pour ta réponse, la prochaine et ton travail.
Si j’ai bien compris, il n’y a pas moyen de passer par une jointure parce que les réponses aux formulaires ne disposent pas d’une table de liens ?
heu, pas compris la question. Lien entre quoi et les formulaires ? J’ai du mal à comprendre la question.
Le plugin peut être téléchargé en se rendant sur la page que j’ai cité, puis en haut à droite le bouton « code ». Mais il sera prochianement disponible comme un zip standard et installable via svp.
Bonjour,
Désolé, ma terminologie n’est peut-être pas la bonne…
Explication :
De nombreuses tables disposent d’une table supplémentaire « liens » : spip_adresses → spip_adresses_liens, contacts, … et même spip_formulaires → spip formulaires_liens.
Celles-ci permettent de retrouver à quels objets et lié l’objet concerné.
Il n’y a pas de table spip_formulaires_reponses_liens.
L’ID du formulaire est directement renseigné dans la table spip_formulaires_reponses.
Il pourrait également y avoir une colonne « ID_ARTICLE » comme il y a cette colonne ID_FORMULAIRE…
Mais dans les exemples évoqués, le principe d’une table « liens » évite de multiplier les colonnes (id_article, id_brève, id_nouvelobjet, id_…) dans la table initiale en renseignant le type d’objet et son ID dans cette table spip_objet_liens.
Effectivement, les réponse ne sont pas liés à des objets via une table de lien. Tout simplement parce que l’information sur la liaison a un objet se trouve dans la réponse elle même, et qu’elle est stocké dans formulaires_reponses_champs.
On pourrait imaginer evidement d’ajouter une table de liaisons, mais cela impliquerait une synchronisation entre le moment où tu édite / modifie la réponse et la table de liaison. Pas impossible à faire, mais pas franchement non plus trivial, pour un besoin la plupart du temps minime.
A mon avis, si une telle fonctionnalité devait voir le jour, ce serait plutôt dans un plugin à part qui ajouterait un traitement « lier la réponse à un objet » et permettrait de choisir le choix d’objet / l’autodetecterait.