- Galette-users - lists.mailman3.com

Troubles when installing oauth2 (Issue #16)
by Alain Castera Sept. 10, 2024

Sept. 10, 2024

Salut Johan, PArdon tout d'abord pour l'envoi via github, je n'avais pas noté que c'était toi qui assurait aussi ce plugin. Un grand merci donc. Si j'ai posé ma question, c'est parce que j'obtenais justement un très désagréable "page non trouvée" :-). J'ai un peu progressé dans la compréhension du problème, mais je n'en suis pas encore tout à fait à la solution, hélas. Tout d'abord, voici le contexte : il s'agit d'une installation yunohost, donc sous nginx et non pas apache. Mais ça ne semble pas être le problème. PAr contre, j'ai remarqué que mon accès à galette fonctionne bien avec une url de la forme mondomaine.ext/galette (qui renvoie alors sur la bonne page galette/login, galette/members, etc.), mais pas avec mondomaine.ext/galette/webroot[...] J'ai donc modifié les url à utiliser dans la config de flarum (qui me setrt pour le test), en supprimant webroot, e.g. mondomaine.ext/galette/plugins/oauth2/[authorize...etc.] Et là, ça ouvre bien une (petite) fenêtre galette (joie!), mais avec un vilain message "page non trouvée" (soupir). En regardant de plus près, le lien complet appelé par cette fenêtre pop-up est de la forme : https://mondomaine.ext/galette/webroot/plugins/oauth2/authorize?scope=&stat… (ce n'est pas la vraie url, que je peux envoyer, ainsi que celle de flarum, en mp si c'est utile). En tenant de rentrer cette url sans webroot à la main, j'obtiens bien le dialogue de login de galette, avec un titre "Se connecter à Forum Flarum"! Bon, ça se passe mal après ("Une erreur est survenue lors du chargement de la page" flarum appelée en retour) , mais c'est déjà un sacré progrès. La question est : que puis-je faire pour contourner la difficulté "webroot" ? Une idée quelqu'un-e ? Merci d'avance, Et pardon à nouveau si ce n'était pas cette liste qu'il fallait utiliser... Alain On Thu, 5 Sep 2024, Johan Cwiklinski wrote: > Everything is handled behind the scenes from the routing system, there is no need for a `webroot` directory nor any "authorize" file. > > If you enter the URL in your browser, you'll see that works (it will complains arguments are missing, but that's also normal, it's designed to be called from the requester service with required arguments. > > Please prefer mailing list for support quesitons. > > -- > Reply to this email directly or view it on GitHub: > https://github.com/galette-community/plugin-oauth2/issues/16#issuecomment-2… > You are receiving this because you authored the thread. > > Message ID: <galette-community/plugin-oauth2/issues/16/2333301680(a)github.com>

2 3

Galette
by Laurent Cobo Sept. 3, 2024

Sept. 3, 2024

Bonjour tout le monde, Il y a des élements dans Galette que je n’utilise pas. Par exemple, je n’ai pas besoin du pseudo. Est-il possible de supprimer cette info ? ou alors, de ne pas la faire apparaitre dans la liste des adhérents ? Un grand merci Laurent Cobo 06 92 60 28 15

2 1

Galette en local
by deuxnielle Sept. 3, 2024

Sept. 3, 2024

Bonjour Je parviens à installer la version 1.1.3 en local (wamp) La base de donnés est bien reconnue, tout semble bien se passer, sauf qu’à l’ouverture de galette…rien, aucun adhérent ! La base a été créée dans phpMyadmin à partir d’une sauvegarde .sql, de même qu’un utilisateur avec ts les droits… Une piste ? Cordialement DL

2 1

Réseaux sociaux
by tezorc Aug. 20, 2024

Aug. 20, 2024

Bonjour, Je remonte une anomalie que j'avais identifiée en décembre 2023 sur l'ancienne liste de discussion, car elle persiste. Johan m'avait transmis un patch qui avait bien fonctionné, mais avec les mises à jour successives, ce patch n'a pas été réappliqué à chaque fois. Le réseau social du club renseigné dans les préférences disparait systématiquement au bout de quelques jours. Le réseau social est pourtant bien enregistré dans la table "galette_socials". Cependant, cet enregistrement disparaît aussi de la base de données. Je suis le seul à avoir des droits d'administrateur sur Galette. Ce n'est pas très grave, mais je ne comprends pas pourquoi cette disparition se produit et pourquoi cela n'affecte que ce paramètre. Merci pour votre aide

3 11

Re: Avertissement automatique des membres
by Johan Cwiklinski Aug. 7, 2024

Aug. 7, 2024

Salut, Le 06/08/2024 à 17:13, IEO Provença-Aups-Còsta d'Azur a écrit : > Bonjour > J’ai testé en emulant un administrateur de groupe et là le curseur n’apparaît pas au dessus d’enregistrer. Je ne suis pas certain d'avoir tout suivi là :) Cela dit, j'ai pu constater le problème d'origine : https://bugs.galette.eu/issues/1860 Un correctif est disponible : https://github.com/galette/galette/commit/44d461848e1d172de36b50b35d70b68e8… Note : il faut vider le cache de Galette pour que la modification prenne effet. ++ -- Johan

1 0

Avertissement automatique des membres
by IEO Provença-Aups-Còsta d'Azur Aug. 6, 2024

Aug. 6, 2024

Bonjour Deux questions liées : Quand un administrateur enregistre une modification sur une fiche de membre ceux-ci sont automatiquement avisés… Mais, semble-t-il, lorsqu’il s’agit d’un responsable de groupe, non. Est-ce bien exact ? D’autre part, le fait d’avertir automatiquement les membres permet de leur communiquer (ou rappeler) leur identifiant. C’est très commode. Cela signifie que seul un administrateur (général) peut transmettre les identifiants. Mais alors comment le faire en nombre ? Je n’ai pas trouvé. Merci. Pèire Mandat de mon iFòn

2 1

Gestion des cotisations par groupe
by IEO Provença-Aups-Còsta d'Azur Aug. 3, 2024

Aug. 3, 2024

Bonjour, Je souhaite pouvoir déléguer aux responsables de groupe (pour moi les secrétaires départementaux de la fédération) l’enregistrement des contributions. Apparement, seul des membres du bureau (fédéral pour moi) ont ces droits. Si j’accorde aux responsables de groupe la gestion des contributions, je leur ouvre l’accès à l’administration de toute la fédération. Cela présente bcp de risques d’erreur. Comment accorder les droits d’administration des contributions aux responsables de groupe sur leur groupe seulement ? Qui a une idée ? 💡 Pèire Mandat de mon iFòn

2 1

Problème Recherches avancées sur les dates - Recherche libre
by Contact CID Auditeur July 22, 2024

July 22, 2024

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*

2 2

A propos des recherches
by deuxnielle July 22, 2024

July 22, 2024

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

2 1

Calcul des périodes de cotisation
by Alain Castera July 20, 2024

July 20, 2024

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 ?

1 0