Evolution #140
ferméChamps supplémentaires sur fiche usager
100%
Description
Quelques modifications à apporter sur les fiches usagers :
- rendre l'identifiant de l'usager modifiable (par les animateurs et par les usagers)
- ajout d'un champs pour stocker une référence externe (utile en cas de synchronisation de comptes avec un système tiers)
- ajout d'un champs permettant aux animateurs de laisser des commentaires sur les usagers (non visibles pour les usagers)
- permettre un choix multiple de réponses pour les pièces justificatives demandées
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
- Assigné à mis à Grégory MARIGOT - TEICEE
Ajout d'un champs texte pour stocker une référence externe (r609) :¶
Champs nécessaire pour des opérations d'import/export ou synchronisation avec des applications/bases externes.
En dehors de cela, l'application n'a aucun usage interne de la valeur de ce champs.
ALTER TABLE `sf_guard_user_profile` ADD `xreference` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL; ALTER TABLE `sf_guard_user_profile` ADD INDEX (`xreference`);
Ajout d'un champs texte permettant des notes internes (r612) :¶
Ce champs n'apparait que dans la partie gestion des usagers, dont l'accès est normalement réservé aux animateurs.
Il n'est pas présent sur la fiche personnelle ("Mon profil") donc non visible par les usagers.
ALTER TABLE `sf_guard_user_profile` ADD `comments` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL;
Modification du champs pour enregistrer plusieurs choix de documents fournis (r614) :¶
Il est possible que plusieurs justificatifs soient demandés, les cases à cocher remplacent les boutons radio.
ALTER TABLE `sf_guard_user_profile` CHANGE `document_given_id` `document_given_id` VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL;
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
Nouveau champs catégorie remplaçant profil internet (r617,r618) :¶
Le champs profil internet n'avait aucune utilité au sein de ProxyEPN, sa présence était uniquement au besoin de saisie d'une information utilisée par un outils tiers. Sa présence pouvait donc être non souhaitée (d'où l'ajout d'une option pour le masquer, cf #135). De plus il était utilisé avec certaines listes dans des fichiers ini qui n'avait pas de rapport particulier avec ce projet.
Dorénavant ce champs se nomme catégorie : même s'il n'a pas vraiment plus d'utilité dans l'application pour le moment, son sens est générique et sa présence n'est plus choquante. Ce n'est qu'un champs d'information facultatif que chacun sera libre d'exploiter ou non selon ses besoins.
Les valeurs possibles sont toujours limitées à une liste prédéfinie, mais celle-ci n'est plus en dur dans un fichier : elle est transférer dans le système de listes administrables en BdD. L'admin peut donc facilement alimenter/modifier les valeurs possible pour ce champs via l'interface web (paramètres / listes administrables / user_category).
Toutefois l'option permettant de ne pas utiliser ce champs a été conservée dans app.yml :
all:
options:
use_user_category: true
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
Identifiant de connexion modifiable (r622) :¶
L'application elle-même n'avait aucune contrainte concernant des modifications des identifiants des usagers. Les soucis pouvaient par contre provenir d'applications externes qui exploitent les informations de ProxyEPN s'ils se basent sur l'identifiant comme référence de l'usager (donc nécessité d'être unique ET fixe dans le temps).
Cependant l'application met en place un champs reference pour chaque usager, qui est justement fait pour assurer cette fonction de clé pivot, unique et fixe. A partir du moment les outils externes se basent sur la reference (voire la xreference pour un fonctionnement dans l'autre sens), rien n'empêche la modification des identifiants.
Le contrôle d'unicité en ajax est également présent sur l'édition d'une fiche, en prenant soin de ne pas tenir compte de sa propre existence avant de signaler si l'identifiant est disponible ou non.
Néanmoins si dans le cadre d'un déploiement de ProxyEPN cette possibilité n'est pas souhaitable (contraintes externes ou choix politiques visant à conserver un identifiant immuable), l'édition des identifiants est désactivable via une option globale de l'application (dans app.yml) :
all:
options:
allow_login_change: false
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
- Statut changé de In Progress à Résolu
- % réalisé changé de 0 à 100
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
- Statut changé de Résolu à Fermé