July 2024 - Galette-users - lists.mailman3.com

Re: Réseaux sociaux

by Frederic Tezorc

Bonjour, Suite à nos derniers échanges, j'ai vérifié les logs, voir ci-joint. J'ai trouvé trois occurrences, mais il semble que l'utilisateur ne soit pas identifié. Je ne comprends pas comment la suppression de ce paramètre a pu être faite, que ce soit de manière volontaire (ça m'étonne) ou accidentelle. Car cela devient vraiment très récurrent! Le mer. 19 juin 2024 à 23:09, Johan Cwiklinski <johan(a)x-tnd.be> a écrit : > Salut, > > Le 19/06/2024 à 09:10, tezorc a écrit : > > Est-il possible que ce patch renseigne un log pour identifié > l'utilisateur? > > Essaie avec le patch joint. > > Il est un peu plus fourni que le patch d'origine, mais (au moins dans > certains cas) une erreur qui semblait sans rapport était déclenchée - et > on avait pas l'information souhaitée... > > J'espère que ça aidera. > > ++ > -- > Johan > _______________________________________________ > Galette-users mailing list -- galette-users(a)mailman3.com > To unsubscribe send an email to galette-users-leave(a)mailman3.com >

July 31, 2024

Re: Problème Recherches avancées sur les dates - Recherche libre

by Contact CID Auditeur

Salut, Tu as aussi la possibilité de faire des requêtes SQL en base, mais il faut les écrire avec des jointures entre tables, c'est peut être mieux que sur un export. Ceci dit ce serait tellement mieux directement avec Galette, et cela marchait très bien en 0.9.x même en expérimental. une partie du code ayant été revu, cela a du introduire des incohérences, mais je pense que le soucis n'est pas hyper dégradé, bien sûr cela demande du boulot à Johan, mais cela rendrait les recherches hyper efficaces. Cordialement, GEORGES *BEYNA* Frederic Tezorc a écrit : > Hello, > > J'avais plus ou moins la même requête pour les recherches avancées et > notamment dans les recherches libres avec les dates. > Hormis le RGPD, j'ai également les renouvellements de vaccins > obligatoires (club canin) ou les certificats médicaux. > Actuellement, j'exporte tout et je filtre avec Open Office par exemple. > > Tu avais déjà posé la même question en décembre 2023 (le 24 ;)) > > Bon! je n'ai pas répondu à ta question et j'avais également fait > d'autres demandes dans le passé > La recherche libre est une fonction expérimentale : > - Anomalie #1473 <https://bugs.galette.eu/issues/1473> - recherche > champ booléen > - Souhaits #1464 <https://bugs.galette.eu/issues/1464> - recherche > avec date > ou encore Souhaits #1485 <https://bugs.galette.eu/issues/1485> - > recherche si présence fichier téléchargé > > > > Le lun. 22 juil. 2024 à 07:50, Contact CID Auditeur > <contact(a)cid-auditeur.com> a écrit : > > Bonjour à tous, > > Je relance ce sujet assez important pour l'assoc dont j'ai la > charge en tant que webmaster et dans le cadre du respect du RGPD > "Droit à l'oubli". J'ai un champs dynamique concernant la > démission de l'assoc, et au bout d'un an je dois détruire les > fiches membres concernées. Celui-ci était analysé par une requête > de recherche avancée et produisait une liste de membres à détruire. > > Cela ne concerne donc que la *recherche avancée libre sur un > champs de dates* (coeur ou dynamique). > > Au départ il propose bien : > > > Il *comprends bien que l'on travaille sur des dates*, suite à > l'entrée d'une date et lancement, le résultat est vierge. > > Requête produite au départ : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM > `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON > `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` > ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS > `status` ON `a`.`id_statut`=`status`.`id_statut` LEFT JOIN (SELECT > `df`.`item_id` AS `item_id`, `df`.`field_val` AS `val` FROM > `oitar_dynamic_fields` AS `df` WHERE `df`.`field_form` = 'adh' AND > `df`.`field_id` = '36') AS `df36` ON `a`.`id_adh` = > `df36`.`item_id` WHERE a.activite_adh=true *AND > STR_TO_DATE(df36.val, '%d/%m/%Y') < STR_TO_DATE('2023-06-01', > '%d/%m/%Y')* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 > OFFSET 0 > > Si on demande la modification des critères alors il présente cela : > > > Il a *perdu la notion de Avant - Après*. > > Dans les *versions antérieures 0.9.x cela marchait très bien*, je > l'utilisais très très souvent (et j'avais même des requêtes > enregistrées). > > *PRECISIONS *: si on fait la même chose avec le *champs du coeur > Date de naissance*, dans cette *recherche libre* : > > > Ca marche, il y a un résultat, mais il perd aussi cette notion > *Avant - Après *à la modification des critères, avec une > proposition d'analyse comme la copie d'écran N°2. > > Requête produite au départ : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM > `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON > `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` > ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS > `status` ON `a`.`id_statut`=`status`.`id_statut` WHERE > a.activite_adh=true AND *a.ddn_adh< '2023-06-01'* ORDER BY > `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 > > Requête produite si modif : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM > `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON > `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` > ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS > `status` ON `a`.`id_statut`=`status`.`id_statut` WHERE > a.activite_adh=true AND *LOWER(a.ddn_adh) = '2023-06-01'* ORDER BY > `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 > > Si vous avez des idées, c'est une fonction importante et hyper > utile sur des champs de type date. > > Cordialement, > > GEORGES *BEYNA* > > > _______________________________________________ > Galette-users mailing list -- galette-users(a)mailman3.com > To unsubscribe send an email to galette-users-leave(a)mailman3.com > > > _______________________________________________ > Galette-users mailing list --galette-users(a)mailman3.com > To unsubscribe send an email togalette-users-leave(a)mailman3.com

July 22, 2024

Re: Problème Recherches avancées sur les dates - Recherche libre

by Frederic Tezorc

Hello, J'avais plus ou moins la même requête pour les recherches avancées et notamment dans les recherches libres avec les dates. Hormis le RGPD, j'ai également les renouvellements de vaccins obligatoires (club canin) ou les certificats médicaux. Actuellement, j'exporte tout et je filtre avec Open Office par exemple. Tu avais déjà posé la même question en décembre 2023 (le 24 ;)) Bon! je n'ai pas répondu à ta question et j'avais également fait d'autres demandes dans le passé La recherche libre est une fonction expérimentale : - Anomalie #1473 <https://bugs.galette.eu/issues/1473> - recherche champ booléen - Souhaits #1464 <https://bugs.galette.eu/issues/1464> - recherche avec date ou encore Souhaits #1485 <https://bugs.galette.eu/issues/1485> - recherche si présence fichier téléchargé Le lun. 22 juil. 2024 à 07:50, Contact CID Auditeur < contact(a)cid-auditeur.com> a écrit : > Bonjour à tous, > > Je relance ce sujet assez important pour l'assoc dont j'ai la charge en > tant que webmaster et dans le cadre du respect du RGPD "Droit à l'oubli". > J'ai un champs dynamique concernant la démission de l'assoc, et au bout > d'un an je dois détruire les fiches membres concernées. Celui-ci était > analysé par une requête de recherche avancée et produisait une liste de > membres à détruire. > > Cela ne concerne donc que la *recherche avancée libre sur un champs de > dates* (coeur ou dynamique). > > Au départ il propose bien : > > > Il *comprends bien que l'on travaille sur des dates*, suite à l'entrée > d'une date et lancement, le résultat est vierge. > > Requête produite au départ : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS > `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT > JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` > INNER JOIN `oitar_statuts` AS `status` ON > `a`.`id_statut`=`status`.`id_statut` LEFT JOIN (SELECT `df`.`item_id` AS > `item_id`, `df`.`field_val` AS `val` FROM `oitar_dynamic_fields` AS `df` > WHERE `df`.`field_form` = 'adh' AND `df`.`field_id` = '36') AS `df36` ON > `a`.`id_adh` = `df36`.`item_id` WHERE a.activite_adh=true *AND > STR_TO_DATE(df36.val, '%d/%m/%Y') < STR_TO_DATE('2023-06-01', '%d/%m/%Y')* > ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 > > Si on demande la modification des critères alors il présente cela : > > > Il a *perdu la notion de Avant - Après*. > > Dans les *versions antérieures 0.9.x cela marchait très bien*, je > l'utilisais très très souvent (et j'avais même des requêtes enregistrées). > > *PRECISIONS *: si on fait la même chose avec le *champs du coeur Date de > naissance*, dans cette *recherche libre* : > > > Ca marche, il y a un résultat, mais il perd aussi cette notion *Avant - > Après *à la modification des critères, avec une proposition d'analyse > comme la copie d'écran N°2. > > Requête produite au départ : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS > `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT > JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` > INNER JOIN `oitar_statuts` AS `status` ON > `a`.`id_statut`=`status`.`id_statut` WHERE a.activite_adh=true AND *a.ddn_adh< > '2023-06-01'* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 > > Requête produite si modif : SELECT DISTINCT `a`.*, > `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS > `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT > JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` > INNER JOIN `oitar_statuts` AS `status` ON > `a`.`id_statut`=`status`.`id_statut` WHERE a.activite_adh=true AND *LOWER(a.ddn_adh) > = '2023-06-01'* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET > 0 > Si vous avez des idées, c'est une fonction importante et hyper utile sur > des champs de type date. > > Cordialement, > > GEORGES *BEYNA* > > _______________________________________________ > Galette-users mailing list -- galette-users(a)mailman3.com > To unsubscribe send an email to galette-users-leave(a)mailman3.com >

July 22, 2024

Re: A propos des recherches

by Johan Cwiklinski

Salut, Le 20/07/2024 à 13:45, deuxnielle a écrit : > *Type :* TypeError > *Code :* 0 > *Message :* Galette\Entity\Group::load(): Argument #1 ($id) must be of > type int, string given, called in > /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Filters/MembersList.php on line 230 C'est corrigé par le commit suivant : https://github.com/galette/galette/commit/f1d7c805e0513e3999d84196e33b4a4b1… ++ -- Johan

July 22, 2024

Calcul des périodes de cotisation

by Alain Castera

Bonjour, Pardon par avance si je déterre un vieux sujet, je n'ai peut-être pas sû chercher. Étant passé "brutalement" de 0.9.6 à 1.1.3 (un grand merci au passage à Yohan et à toutes celles et ceux qui permettent ces évolutions), je note un changement de paradigme en ce qui concerne le calcul des périodes de cotisations, passant d'une borne de fin exclusive à une borne de fin inclusive. Dit autrement, auparavant, lorsque vous cotisiez par exemple le 1er du mois pour 1 mois, votre cotisation courrait jusqu'au 1er du mois suivant. Lorsque vous rentriez une cotisation commençant le 1er du mois suivant, tout se passait bien. Maintenant, la cotisation court jusqu'au dernier jour du mois courant. Ça ne me dérange pas, je n'ai pas de religion en la matière. Le problème est que chaque fois que je rentre une cotisation au 1er du mois, elle rentre maintenant en conflit avec la cotisation enregistrée avec la version 0.9.6, ce qui est rapidement très pénible. J'ai envisagé de modifier les dates d'enregistrement des cotisations précédentes, il suffit pour ça de rappeler la cotisation et de la réenregistrer avec le nouveau mode de calcul. Mais comme il faut faire ça en partant de la toute première cotisation, ça fait des millers d'opérations, ingérables. Il faudrait faire ça directement dans la base de données, mais la formule à utiliser pour ne pas avoir à nouveau des milliers d'édition à faire ou des centaines de cas particuliers à traiter ne me paraît pas d'une évidence aveuglante. En attendant, je fais démarrer les cotisations au 2 du mois, mais ce n'est ni élégant ni tenable sur la durée. Alors, si vous avez une suggestion ... merci d'avance. Et merci encore pour tout. Alain P.S. dans un avenir lointain, ne serait-il pas judicieux d'enregistrer plutôt date de début et durée, ce qui éviterait ce genre de désagrément si on change à nouveau de façon de voir ?

July 20, 2024

A propos des recherches

by deuxnielle

Bonjour, Galette V 1.1.3, php 8.1 Depuis la pages adhérents, les recherches sont fonctionnelles, comme leur enregistrement. Depuis les recherches enregistrées, l’exécution de ces mêmes requêtes renvoie le résultat attendu. *MAIS *avec à la fois, deux bandeaux : un bandeau vert de bonne exécution *et *un avertissement sur bandeau rouge "une erreur SQL est survenue lors du chargement de la requête" Par contre toutes les recherches avancées renvoient le même message d'erreur, accompagné des infos suivantes. Pourtant elles sont correctement exécutées en arrière plan ! Details*Type :* TypeError *Code :* 0 *Message :* Galette\Entity\Group::load(): Argument #1 ($id) must be of type int, string given, called in /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Filters/MembersList.php on line 230 *Fichier :* /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Entity/Group.php *Ligne :* 88 Trace #0 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Filters/MembersList.php(230): Galette\Entity\Group->load() #1 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Filters/AdvancedMembersList.php(414): Galette\Filters\MembersList->__set() #2 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Controllers/Crud/MembersController.php(600): Galette\Filters\AdvancedMembersList->__set() #3 [internal function]: Galette\Controllers\Crud\MembersController->filter() #4 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/php-di/invoker/src/Invoker.php(74): call_user_func_array() #5 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/php-di/slim-bridge/src/ControllerInvoker.php(47): Invoker\Invoker->call() #6 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/Routing/Route.php(363): DI\Bridge\Slim\ControllerInvoker->__invoke() #7 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Middleware/Authenticate.php(166): Slim\Routing\Route->handle() #8 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(280): Galette\Middleware\Authenticate->__invoke() #9 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #10 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Slim\MiddlewareDispatcher->handle() #11 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/Routing/Route.php(321): Slim\MiddlewareDispatcher->handle() #12 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/Routing/RouteRunner.php(74): Slim\Routing\Route->run() #13 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/akrabat/rka-slim-session-middleware/RKA/SessionMiddleware.php(66): Slim\Routing\RouteRunner->handle() #14 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): RKA\SessionMiddleware->process() #15 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/csrf/src/Guard.php(482): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #16 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Csrf\Guard->process() #17 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Middleware/Language.php(68): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #18 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(177): Galette\Middleware\Language->__invoke() #19 /data/www/users/webmaster.abon-asso/abon.asso/galette/lib/Galette/Middleware/Telemetry.php(69): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #20 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(177): Galette\Middleware\Telemetry->__invoke() #21 /data/www/users/webmaster.abon-asso/abon.asso/galette/includes/main.inc.php(175): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #22 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(280): Closure->{closure}() #23 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php(45): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #24 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Middleware\RoutingMiddleware->process() #25 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/Middleware/ErrorMiddleware.php(77): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #26 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Middleware\ErrorMiddleware->process() #27 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/twig-view/src/TwigMiddleware.php(115): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #28 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Views\TwigMiddleware->process() #29 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Psr\Http\Server\RequestHandlerInterface@anonymous->handle() #30 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/App.php(209): Slim\MiddlewareDispatcher->handle() #31 /data/www/users/webmaster.abon-asso/abon.asso/galette/vendor/slim/slim/Slim/App.php(193): Slim\App->handle() #32 /data/www/users/webmaster.abon-asso/abon.asso/galette/includes/main.inc.php(207): Slim\App->run() #33 /data/www/users/webmaster.abon-asso/abon.asso/galette/webroot/index.php(50): require_once('...') #34 {main} Help ! Merci pour votre aide en pensant que tout ceci est très obscur pour moi 😉 ! Si la correction à apporter est simple, je pense y arriver, sinon...?😙 Cordialement, Deuxnielle

July 20, 2024

Problème Recherches avancées sur les dates - Recherche libre

by Contact CID Auditeur

Bonjour à tous, Je relance ce sujet assez important pour l'assoc dont j'ai la charge en tant que webmaster et dans le cadre du respect du RGPD "Droit à l'oubli". J'ai un champs dynamique concernant la démission de l'assoc, et au bout d'un an je dois détruire les fiches membres concernées. Celui-ci était analysé par une requête de recherche avancée et produisait une liste de membres à détruire. Cela ne concerne donc que la *recherche avancée libre sur un champs de dates* (coeur ou dynamique). Au départ il propose bien : Il *comprends bien que l'on travaille sur des dates*, suite à l'entrée d'une date et lancement, le résultat est vierge. Requête produite au départ : SELECT DISTINCT `a`.*, `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS `status` ON `a`.`id_statut`=`status`.`id_statut` LEFT JOIN (SELECT `df`.`item_id` AS `item_id`, `df`.`field_val` AS `val` FROM `oitar_dynamic_fields` AS `df` WHERE `df`.`field_form` = 'adh' AND `df`.`field_id` = '36') AS `df36` ON `a`.`id_adh` = `df36`.`item_id` WHERE a.activite_adh=true *AND STR_TO_DATE(df36.val, '%d/%m/%Y') < STR_TO_DATE('2023-06-01', '%d/%m/%Y')* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 Si on demande la modification des critères alors il présente cela : Il a *perdu la notion de Avant - Après*. Dans les *versions antérieures 0.9.x cela marchait très bien*, je l'utilisais très très souvent (et j'avais même des requêtes enregistrées). *PRECISIONS *: si on fait la même chose avec le *champs du coeur Date de naissance*, dans cette *recherche libre* : Ca marche, il y a un résultat, mais il perd aussi cette notion *Avant - Après *à la modification des critères, avec une proposition d'analyse comme la copie d'écran N°2. Requête produite au départ : SELECT DISTINCT `a`.*, `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS `status` ON `a`.`id_statut`=`status`.`id_statut` WHERE a.activite_adh=true AND *a.ddn_adh< '2023-06-01'* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 Requête produite si modif : SELECT DISTINCT `a`.*, `status`.`priorite_statut` AS `priorite_statut` FROM `oitar_adherents` AS `a` LEFT JOIN `oitar_socials` AS `so` ON `a`.`id_adh`=`so`.`id_adh` LEFT JOIN `oitar_adherents` AS `parent` ON `a`.`parent_id`=`parent`.`id_adh` INNER JOIN `oitar_statuts` AS `status` ON `a`.`id_statut`=`status`.`id_statut` WHERE a.activite_adh=true AND *LOWER(a.ddn_adh) = '2023-06-01'* ORDER BY `nom_adh` ASC, `prenom_adh` ASC LIMIT 100 OFFSET 0 Si vous avez des idées, c'est une fonction importante et hyper utile sur des champs de type date. Cordialement, GEORGES *BEYNA*

July 19, 2024

Re: Reçu annuel des cotisations

by Alain Castera

La syntaxe que j'utilise est dans un fichier config/exports.xml. Je ne connais pas yaml, il faudra peut-être ajuster. Ceci dit, l'essentiel est la requête SQL, qui elle ne varie pas :-) A. On Fri, 19 Jul 2024, fanf(a)everat.fr wrote: > aaaah j'ai trouvé ! c'est dans le fichier config/exports.yaml > > Merci ! je vais bosser là dessus ! > Bonne journée à toi ! > François > _______________________________________________ > Galette-users mailing list -- galette-users(a)mailman3.com > To unsubscribe send an email to galette-users-leave(a)mailman3.com

July 19, 2024

Re: Reçu annuel des cotisations

by fanf＠everat.fr

aaaah j'ai trouvé ! c'est dans le fichier config/exports.yaml Merci ! je vais bosser là dessus ! Bonne journée à toi ! François

July 19, 2024

Re: Reçu annuel des cotisations

by fanf＠everat.fr

Merci beaucoup Alain pour ta réactivité ! Où lances-tu ta requête ? Car dans le site dans gestion > exports. Il y a bien un export paramétré, mais je ne trouve pas comment ajouter le mien perso... A moins que tu ne le fasses directement dans phpmyadmin dans l'interface de ton hébergeur ?

July 19, 2024