Re: [Galette-devel] Quelques retours sur la 0.63Re: [Galette-devel] Quelques retours sur la 0.63John Perr a écrit :
Eric Boniface a écrit :Hello, nous venons de faire quelques tests suite à la migration de notre env de test, voici quelques retours (peut-être redondants avec d'autres points déjà vus). - pb sur les préférences (voir mon msg précédent)Si j'ai 5mn je regarderai vu que personne d'autre n'a répondu et que je dois être le dernier a avoir touché à la page étiquette et ce qui y est associé :-/
Comme je le dis dans mon message, je n'ai pas ce problème avec le dernier SVN. Peut être s'agit-il d'un souci dans le script de mise à jour de la base ?
- j'ai du rajouter les traductions des statuts et des cotisations dans le fichier lang.french.php, idem pour la configuration des fiches.Ca marche ? Parce que c'est toujours un pb ouvert du fait de la difficulté de traduire les textes inclus dans la BD. Voir https://gna.org/bugs/?7015
Oui ça marche. Le souci est que les nouvelles chaines ne sont pas incluses, ce n'est ni fiable, ni pratique de tout se gaufrer 'à la main' :/
- est-il possible de désactiver la possibilité d'inscription ? Seul notre trésorier - ou son adjoint - est habilité à créer les nouveaux membres.Ce n'est pas une grosse modif, c'est une préférence à ajouter. En attendant, le plus simple est de remplacer la page self_adherent.php par une copie de index.php ou un lien vers ce même fichier.
+1
Cela rejoint une préoccupation plus générale qui a été traitée en partie dans galette sport: celle des différents droits d'accès à l'application. Pour essayer de satisfaire les différents besoins exprimés jusqu'ici sur le sujet, je vous soumets l'idée suivante qui est une sorte de compilation des besoins de galette-sport et de la todo list. Globalement il existe le besoin d'avoir des "groupes" constitués avec des admins restreints.
Je ne connais pas trop la version sport... Ceci dit, si nous pouvions avoir une seule et même version de galette, au moins dans les plus grandes lignes, ça me plairait beaucoup. En effet, les efforts de développement sont divisés entre ces deux versions, alors que des fonctionnalités communes sont ajoutées de part et d'autre. Il faut ensuite les basculer d'une version à une autre, ce qui n'est pas toujours évident, et nous donne un surcroit de travail (le passage à PHP5 et à Pear::MDB2 risque d'être plutôt coton sur deux versions parallèles...). Qu'en pense(nt) le(s) développeur(s) de la version sport ? Est-ce utopique d'envisager la réunification des deux branches ? Ayant pris moi même le train en marche, je ne sais pas trop pourquoi il avait été décidé de faire une nouvelle branche plutôt que d'intégrer les fonctionnalités dans le trunk.
Je propose donc de coder un truc dans ce genre: -Un admin général (une sorte de root ou sysadmin) qui peut tout faire, c'est le seul niveau qui existe actuellement dans galette et qu'on a besoin de conserver pour gérer l'application. -Des groupes auxquels les adhérents peuvent appartenir sans limitation sur le nombre. Cela peut être des classes d'ages pour des club sportifs ou des groupes dédiés à des tâches quelconques, y compris le bureau ou/et le CA. -Un adhérent aura ou non les droits suivants sur un groupe: + Consulter, Modifier ou Administrer les membres du groupe + Consulter, Modifier ou Administrer les contributions des membres du groupe Administrer sous entend créer, supprimer et gérer les droits, je ne vois pas le besoin de dissocier les 3. -Un adhérent aura toujours le droit de modifier ses coordonnées mais pas ses contributions qu'il pourra par contre consulter. En notation style unix ça donne: CMA-CMA : GID UID ^ ^ | |__ Droits de UID sur les contributions de GID |__ Droits de UID sur les membres de GID Ces droits seront donc affectés au couple (adhérent=UID,groupe=GID) ce qui permettra à un adhérent X d'être admin d'un groupe et trésorier de l'asso. Ainsi on peut déjà imaginer qu'on aura au moins par défaut: -un groupe asso (par exemple) auquel tout le monde appartient mais avec aucun droit par défaut -un sysadmin qui a tous les droits sur le groupe asso (CMA-CMA) -Des membres du bureau qui peuvent consulter tout les membres et leurs cotisations, donc avec des droits (C__-C__) sur le groupe asso -un secrétaire ou responsable des adhésions qui peut modifier tous les membres du groupe asso (CMA-C__). -un trésorier qui peut modifier toutes les contributions des membres du groupe asso (C__-CMA) Bien sûr cela représente des modifications de la structure de la base (ajout de tables) et du code. valider l'ensemble prendra aussi un peu de temps. C'est pourquoi je vous soumets dès à présent l'idée afin d'en débattre, il est probable que cela ne sera pas intégré dans la prochaine version stable.
s/probablement/certainement :p L'implémentation d'ACL risque d'être une tâche ardue, et relativement longue. N'existe-t'il pas un système duquel nous pourrions nous inspirer, dans une autre application libre codée en PHP (5 de préférence puisque nous allons devoir y arriver) ? "Pomper" un système existant et déjà éprouvé pourra peut être nous éviter pas mal de prises d'aspirine :-D
Salutations ---8<---
Sur ce, bonne soirée, Johan
Attachment:
signature.asc
Description: OpenPGP digital signature