Module Personnes

Gestion des utilisateurs (personnes) dans l'application. Ce module couvre l'annuaire des personnes internes et externes, la création de comptes, les arrivées/départs, et les fiches individuelles.

Concepts clés

Types de comptes (tpaccount)

Statuts d'une personne

• Active : présente et non désactivée (dtdes null, dtdel null)
• Arrivée prévue : dtar dans le futur
• Départ récent : dtdep récent
• Désactivée : dtdes renseigné, dtdel null
• Supprimée : dtdel renseigné (soft delete — invisible dans les listes)

Pages principales

Annuaire interne (/persons)

Liste les personnes de l'entité courante. Les onglets disponibles dépendent du profil de l'utilisateur connecté :

Données Clients / Partage (/persons/clients)

Réservé aux prestataires premium. Affiche les personnes des entités clientes pour lesquelles le prestataire a un accès. Permet la création de personnes chez les clients.

Personnel extérieur (/persons/ext)

Réservé aux clients (non prestataires). Affiche les personnes provenant de prestataires ayant accès à l'entité. Vue en lecture seule avec actions de gestion des droits.

Création d'une personne

La création se fait via un assistant multi-étapes (wizard) :

1. Identité — Civilité, nom, prénom, dates (naissance, arrivée), entité, adresse, téléphone, champs personnalisés
2. Email / Login — Choix du type d'email selon la config du tenant (account_type_allowed), racine email, domaine, login (généré automatiquement ou saisi), vérification d'unicité
3. Fonction — Fonction dans l'organisation, statut, responsable hiérarchique, remplacement éventuel d'un autre utilisateur
4. Groupe / Profil — Groupe, profil d'accès, limitations d'entités, droits contractuels
5. Santé (si module actif) — RPPS, MSS, nom d'exercice
6. Ticket (si module actif) — Configuration du compte pour la création de tickets SI/RH

Options d'email à la création

Le type d'email proposé dépend du paramètre tenant account_type_allowed (configurable dans les paramètres DSI) :

La valeur tpmail est enregistrée sur l'utilisateur (pro, perso ou none) en fonction du choix effectué.

L'alerte informative de l'étape Email est dynamique : elle liste uniquement les options réellement disponibles pour le tenant courant, en nombre et en contenu. Elle n'affiche jamais d'options inaccessibles selon la configuration account_type_allowed.

Trois types de création sont disponibles depuis l'annuaire interne :

• Personne nominative
• Boîte générique / partagée
• Compte administrateur

Fiche individuelle

Accessible depuis chaque ligne de l'annuaire. La fiche est organisée en onglets latéraux :

Sous-onglets Informatique

Sidebar de la fiche

La sidebar affiche :

• Photo de profil de l'utilisateur (avec fallback sur l'image par défaut)
• Boutons d'action rapide : email (si email renseigné), appel IP (si tel), SMS (si lbpor), localisation Google Maps (si idaddr)
• Nom complet de l'utilisateur
• Badge Azure AD si synchronisé (visible uniquement aux utilisateurs IT)

Panneau d'actions (CTL)

Le panneau latéral d'actions contextuelles propose, selon les droits :

• Mot de passe provisoire : affichable et copiable si le mot de passe n'a pas encore été changé
• Transformer l'utilisateur : changer le type de compte (admin local uniquement)
• Transférer l'utilisateur : déplacer vers une autre entité (admin local uniquement)
• Modifier l'email : accessible si nom + prénom renseignés (admin local uniquement) — permet de choisir entre email pro et email personnel selon account_type_allowed. Si l'adresse est déjà prise, un message explicite s'affiche sous le champ : il indique quel utilisateur la détient, et précise si c'est un utilisateur archivé qu'il faut supprimer définitivement pour libérer l'adresse (nom masqué si le compte appartient à une autre structure)
• Envoyer les codes : envoi du mot de passe provisoire par email
• Réinitialiser le mot de passe : avec alertes contextuelles si Youzer sync ou connexion o365 activée
• Historique du matériel : lien vers la page d'historique matériel
• Supprimer l'email : retrait de l'adresse email de l'utilisateur
• Désactiver / Réactiver : selon état actuel (masqué si bl_hide_activation dans DsiParam)

Compteurs statistiques

En haut de la fiche, des compteurs affichent (chacun conditionné par module et droits) :

Vue rapide (See)

Accessible via le bouton "Voir" dans les listes, la vue rapide affiche :

• Cover avec avatar, profil, type d'utilisateur, entreprise et adresse
• Coordonnées (email, téléphone fixe, portable, adresse cliquable Google Maps)
• 4 tableaux DataTable : Fonctions, Rôles Projet, Tickets, Matériels rattachés
• Addins associés : images, liens, commentaires, documents

Profils d'accès

Chaque utilisateur possède un ou plusieurs profils dans la table users_profile. Le profil favori (blfavorite = 1) est celui utilisé activement par la session.

Un profil peut être contractuel (blcontract) et associé à des adresses spécifiques (idaddrs).

Fonctions

Chaque utilisateur peut avoir plusieurs fonctions dans users_fonc. La fonction principale est marquée blmaster = 1.

Hooks de formulaire (système legacy)

Le module Personnes utilise des hooks PHP et des vues Blade pour gérer la validation, les effets de bord et les alertes du formulaire fiche individuelle (module 12000101, modèle 01).

Alertes formulaire (120001.blade.php)

En mode update + modidel = 01, des alertes contextuelles s'affichent en haut de la fiche :

• Erreur informations manquantes (rouge) : si nom, prénom ou profil d'accès absent
• Utilisateur désactivé (orange) : si dtdes est renseigné, affiche la date de désactivation

Validations pré-sauvegarde (120001.form.php)

Règles appliquées avant l'enregistrement :

• ISI-DSI (non membres 10/40) : ne peut pas modifier un utilisateur de sa propre structure autre que lui-même
• Email unique : en création, vérifie qu'aucun utilisateur ne partage déjà l'email ; en modification, vérifie l'unicité si l'email change
• Champs santé : masqués automatiquement si le secteur (tpsector) n'est pas MS ou MCO
• Suppression : bloquée si l'utilisateur connecté tente de supprimer son propre compte

Effets de bord post-sauvegarde (120001.db_after.php)

Après chaque modification (update) du modèle 01 :

• Profil 900 créé automatiquement à la création d'un utilisateur
• Photo de profil : si changée par le user connecté sur sa propre fiche, la session est mise à jour immédiatement
• Passage en compte administrateur : réinitialise idlimit à vide dans users_profile
• Propagation du nom/prénom : si modifiés, met à jour lbname_asker dans les tickets et lbname_master dans dsi_hw et project_role
• Propagation de l'email : si modifié, met à jour lbmail_asker, lbname_asker et iduser_asker dans les tickets + les mêmes champs dans dsi_hw et project_role
• Cache invalidé : clés persons_{_id}_{id} et persons_DataTable_{_id}_{id}

Contrôles pré-chargement (120001.ctlbefore.php)

Avant l'affichage du formulaire (modèle 01) :

• Accès home/print : redirige vers /persons
• Création : vérifie que l'idc soumis appartient bien au tenant (les prestataires premium peuvent aussi créer chez leurs clients)
• Type de compte à la création : si tpaccount = 'N' ou valeur invalide, force 'G'

Module Fonctions (120101)

Les hooks du sous-module fonctions (12010101) gèrent la création, modification et suppression des postes/missions associés à un utilisateur (users_fonc).

Validation pré-sauvegarde (120101.form.php)

Règles appliquées pour le modèle 01 :

• Contrôle tenant : vérifie que l'idc soumis correspond au même _id que l'utilisateur concerné
• Création : pré-remplit automatiquement tpfonc (CLI_AUTRE), tpcon (depuis tpuser), idaddr et dtbegin (depuis dtar) ; blmaster forcé à 1 si c'est la première fonction
• Libellé automatique : si lbfonc absent au POST, récupère le libellé depuis le référentiel 810079
• Promotion master : si blmaster passe à 1, retire automatiquement ce statut aux autres fonctions via updateUnactiveValues
• Démotion master : bloquée si c'est la seule fonction (alert danger)
• Modification : si une seule fonction existe sans blmaster = 1, la corrige automatiquement en base
• Suppression : bloquée si la fonction est master et qu'il en existe d'autres

Contrôles pré-chargement (120101.ctlbefore.php)

En mode suppression uniquement :

• Récupère la fonction (UserFonc) et son statut blmaster
• Redirige vers la page RH de l'utilisateur (persons.internal.rh)
• Supprime directement l'entrée users_fonc et termine l'exécution

Module Profils d'accès (120501)

Les hooks du sous-module profils (12050101) gèrent la création, modification et suppression des profils d'accès associés à un utilisateur (users_profile).

Validation pré-sauvegarde (120501.form.php)

Règles appliquées pour le modèle 01 :

• Contrôle tenant : vérifie que le _id soumis correspond au tenant courant et que l'utilisateur appartient bien au même tenant que l'entité
• Création : si l'entité est ISI-DSI (_id = 1), utilise la liste de profils spéciale 8040078 ; injecte automatiquement _id et initialise blcontract selon le profil choisi (CRUD pour 100/110/120/300, NO sinon) ; les profils 100/110/120 verrouillent le champ idlimit
• Modification POST : valide que le profil demandé existe dans la liste autorisée (étendue pour ISI-Groupe) ; bloque si profil inconnu
• Doublon bloqué : interdit deux profils identiques (_id + idprofile) pour le même utilisateur
• Profil 900 : le champ idlimit est obligatoire si c'est l'utilisateur courant qui fait la demande
• Champ blcontract : masqué sauf pour les admins ou les profils ayant le droit contractuel (blcontract IN CRUD, R)
• Profils 110/150 : ne peuvent pas modifier leurs propres profils ni attribuer le profil administrateur (100)
• Utilisateurs ISI-DSI : ne peuvent pas modifier leurs propres profils

Contrôles pré-chargement (120501.ctlbefore.php)

En mode suppression uniquement :

• Récupère le profil (UsersProfile) et vérifie si c'est le profil favori (blfavorite)
• Si c'est le profil favori, attribue le statut favori à un autre profil de l'utilisateur
• Redirige vers la page Informatique de l'utilisateur (persons.internal.it)
• Supprime directement l'entrée users_profile et termine l'exécution

Actions disponibles

Sur la liste

• Création de personne (wizard)
• Filtres multi-critères (entité, fonction, profil, email, type de compte…)
• Actions en masse : mise à jour de profils, transfert d'entité, envoi de codes d'accès, archivage

Sur une fiche individuelle

• Modification des données (identité, email, localisation)
• Désactivation avec motif et date
• Transformation de type de compte
• Gestion des profils d'accès

Gestion des droits

Les droits sur les personnes sont contrôlés par le droit 12000101 :

Des restrictions supplémentaires s'appliquent selon le profil :

• Profil 900 (idlimit) : accès limité à certaines entités seulement
• tpread: limit-entities : lecture restreinte aux entités configurées
• tpcreate: limit-entities : création restreinte aux entités configurées

Configuration DSI (paramètres tenant)

Accessible depuis la page Paramètres DSI (hook 800501, onglet 7). Ces paramètres sont répartis dans 3 sous-onglets, chacun géré par un composant Livewire dédié, et stockés dans DsiParam (colonnes JSON par tenant).

Types de mail autorisés (account_type_allowed)

Détermine les options proposées à la création de compte (étape Email du wizard) et dans le modal "Modifier l'email" de la fiche :

Étapes du wizard

Actions à la création de compte (Ticket SI / RH)

Lors de la création d'un utilisateur, une action peut être déclenchée automatiquement :

Champs conditionnels selon le mode :

• Mode 1 : sélection du sujet de ticket (référentiel 810098)
• Mode 2 : saisie d'une ou plusieurs adresses email de destination (champ à étiquettes : saisir l'adresse puis Entrée pour l'ajouter). Lors de la création, le mail est envoyé à toutes les adresses configurées (ou à l'unique si une seule).

Trame du contenu : pour les modes 1 et 2, une trame HTML (éditeur riche) peut être configurée pour pré-remplir le corps du ticket ou de l'email.

Informations utilisateur dans les tickets (ticket_userinfo_si / ticket_userinfo_rh)

Paramètre contrôlant l'intégration des informations personnelles dans les tickets de création d'utilisateur. Options issues du référentiel 8040171 (visible uniquement si le module Ticket est actif).

Alertes de départ

Envoi automatique d'un email X jours avant la date de départ (dtdep) d'un utilisateur. Configurée indépendamment pour les canaux SI et RH.

Paramètre departure_days : nombre de jours avant le départ déclenchant l'alerte (1–365). Si non renseigné, aucune alerte n'est envoyée.

Actions disponibles (par canal SI et RH) :

Champs conditionnels (mode 2) : une ou plusieurs adresses email de destination (champ à étiquettes) + trame HTML du corps du mail. L'alerte est envoyée à toutes les adresses configurées pour le canal.

Déclenchement : une commande planifiée (user:send-departure-alerts) s'exécute chaque jour à 07h00 et identifie les utilisateurs dont dtdep correspond exactement à aujourd'hui + departure_days. Les utilisateurs archivés ou désactivés sont exclus.

Multi-tenancy

Toutes les requêtes sont filtrées par le tenant courant via _id = session('user')['info']['_id']. Les personnes externes (prestataires) sont gérées via la relation extAccess avec filtre sur _idpresta.