[mlfichadh] Réponse aux Propositions de Jean

[Louis MATRINGE <matringe.louis@xxxxxxxxx>]

Bonjour,

Ci après mes réponses et contre propositions :

Proposition  de Jean :
- on sort login et password et autorisation d'édition de la table principale pour mettre dans une autre table (appelée login par exemple, à voir)
Avantages : chaque adhérent pourra modifier le reste de sa fiche (par identification avec son password). On peut bien entendu l'autoriser aussi à changer son password, mais séparément, pour qu'il ne l'efface pas par mégarde. Si toutefois il n'a pas envie de modifier, il peut très bien ne pas avoir de login.
à la création de la base, on crée un login ayant l'autorisation d'édition, mais pas forcément de fiche (on peut imaginer qu'un adh de Vernon, par exemple, gère ceux de Ste Austreberthe)

Inconvénient : 2 tables à gérer séparément (celle du login pouvant toutefois pointer sur une fiche avec le no de fiche, bien entendu). Mais celle du login est accédée à l'identification  ou demande de changement du mot de passe, la fiche adhérent pour les autres fonctions, ça ne devrait pas être trop gênant.

Critique :
Je serais assez d'accord pour gérer les login dans une table dédiée. Mais l'idée de départ était de faciliter la tâche à celui ou celle qui était  en train de faire les mises à jour des fiche sans avoir à changer de formulaire ou de page.
Quand à autoriser les membres à modifier leur fiches , c'est une autre histoire. Si la loi informatique et liberté impose qu'ils aient un droit de modification de leur données , elle n'impose pas que ce soit eux qui le fasse. J'ai en effet bien peur que l'on passe notre temps à réinitialiser des password parce qu'ils les auront oublier

Proposition de Jean :
- paramètres :
La table paramètres (à transformer) aurait la structure suivante :
nom du champ en cause (ex : cotisation)
liste des valeurs possibles (ex : normale (75) réduite (50), ... ) , ceci dans une zone de texte. Nb : si un jour on a besoin des valeurs numériques des cotisations, il suffira d'appliquer une fonction bien sentie qui sortira le nombre inclus dans la ligne de texte.
d'autres champs pourraient être ajoutés, comme par exemple intitulé du champ (à écrire dans la page d'édition de la fiche), voire fonctions à appliquer en saisie du champ ou en édition. ceci pour reprendre mon idée d'édition de fiche indépendante de la structure de la table. Ce dernier point étant pour une version future.

Critique :
Si j'ai chois la structure actuelle de la table des paramètres c'est parce qu'elle permet de déclarer n'importe quel type de paramètre a condition d'être un peu astucieux dans le nom qu'on leur donne. Par ailleurs cette table n'est utilisée que par l'application, et ar l'administrateur qui la renseigne en début d'année , et non pas par les utilisateurs. Mais je suis prêt a en discuter si on peu trouve une solution pour être encore plus souple avec une charge de développement faible.


A plus...
Louis