Description des attendus de fonctionnement dans les écrans familles et personnes

L'écran doit respecter :

• le fonctionnement générique des écrans (bandeau haut, utilisation de la grille générique, export …)
• les champs obligatoires, non obligatoire et nominatif doivent être taggé avec la bonne couleur RGPD (pour mémoire tous les champs du “fichier” sont de fait nominatif. Se référer aux descriptif des tables dans la carto (champ required dans TableFormat)
• La gestion des personnes via les écrans “fichier” est couvert par la fonctionnalité 79 : Fichier : Accès à l'écran Famille/Personne pour avoir plus d'information se référer à la cartographie fonctionnelle univers fonctionnalité
• Voir aussi la gestion des droits et le respect des accès (CRUD)
• Mais aussi par rapport à l'accès au fichier dans les bases sectorisés
• le look doit être au plus prêt de la version client, même si quelques fonctionnements évolue
• tant que l'utilisateur n'a pas appuyer sur “Valider” il doit pouvoir “Annuler” ces modifications au delà non.

Une personne a un don en cours si le filtrage de la table HistoriqueDon sur (Adherent=SonID) et (Fixe=false ou 0)

La création du nouvel objet la classe DOIT se faire via un new create afin d'y injecter depuis le modèle les valeurs par défaut

ATTENTION : La liste des familles sur lesquelles on peut ajouter une personne ne comporte que celle non archivé

Dans la cas ou l'utilisateur laisse la famille vide (ou détache la personne de la famille en effacent le lien), l'adresse doit être modifiable (même si la case liaison avec la famille est coché) Des que l'utilisateur choisie une famille on coche la case adresse famille et on y recopie l'adresse de la famille Si l'utilisateur la décoche on ne vide pas l'adresse

Il conviens de vérifier avant de lancer la validation :

• que les champs formatés sont corrects, on pensera notamment aux dates, courriel … ⇒ bloquant
• que les champs obligatoires ont bien une valeur (Cf plus haut carto & TableFormat) ⇒ bloquant
• qu'il n'existe pas déjà une fiche ayant même nom, même prénom (vérification non bloquante)
• que l'on n'a pas modifier par erreur la fiche courante (nom, prénom modifier) (vérification non bloquante)

Les étapes du processus de validation sont :

1. Le champ “famille” est vide ou null on donc a faire à un personne sans famille dans ce cas
   1. on propose un intitulé “titre” “prenom” “nom”
   2. on demande à l'utilisateur de le modifier / Valider
   3. on créer la famille en reprenant
      • libelle : saisie
      • classersous : nom
      • adresse : adresse de la personne
   4. on enregistre la famille sur le serveur et on récupère son ID que l'on injecte dans personne.Famille
2. on enregistre la personne et on récupère le nouvel ID
3. on place l'utilisateur sur la nouvelle fiche “personne”

On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour la modification/création de la personne (voir de la famille)

Avant de lancer un suppression il faut vérifier que la personne n'est pas lié à un don sur l'exercice (ou sur un exercice non clos)

La suppression est une opération définitive, il conviens donc de bien l'indiquer à l'utilisateur

Dans le cas ou la personne est seul dans la famille il faut proposer (pas imposer) la suppression de la famille)
Dans le cas ou la personne n'est pas seul dans la famille il faut proposer (pas imposer) la suppression de la famille et des autres membres (attention au fait qu'il peuvent être non effacable (don sur exercice ou non clos)

On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour toutes les suppressions réalisées

Avant de lancer un archivage il faut vérifier que la personne n'est pas lié à un don sur l'exercice (ou sur un exercice non clos)

Dans le cas ou la personne est seul dans la famille il faut proposer (pas imposer) l'archivage de la famille) Dans le cas ou la personne n'est pas seul dans la famille il faut proposer (pas imposer) l'archivage de la famille et des autres membres

On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour toutes les archivages réalisées

Si on désarchive une personne il faut vérifier au préalable que la famille est désarchivé

La création du nouvel objet la classe DOIT se faire via un new create afin d'y injecter depuis le modèle les valeurs par défaut

Il conviens de vérifier avant de lancer la validation :

• que les champs formatés sont corrects, on pensera notamment aux dates, courriel …
• que les champs obligatoires ont bien une valeur (Cf plus haut carto & TableFormat)

On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour la modification/création de la famille

Avant de supprimer il faut vérifier que tous les membres sont effaçable (Cf effacement des personnes)
La suppression est une opération définitive, il conviens donc de bien l'indiquer à l'utilisateur, ainsi que les personnes qui vont être effacées
On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour toutes les suppressions réalisées

Avant d'archiver il faut vérifier que tous les membres sont archivable (Cf archivage des personnes)
La suppression est une opération définitive, il conviens donc de bien l'indiquer à l'utilisateur, ainsi que les personnes qui vont être effacées
On se doit de vérifier que dans la piste d'audit à bien été ajouté une entrée pour toutes les suppressions réalisées

Si on désarchive une famille il faut vérifier au préalable que la famille est désarchivé