---
title: "Module Personnes"
module: identity
type: functional
status: active
updated: 2026-07-21
---

# 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`)

| Valeur | Libellé | Usage |
|--------|---------|-------|
| `N` | Nominatif | Compte personnel nominatif |
| `G` | Générique | Boîte générique (service, rôle) |
| `B` | Boîte partagée | Compte partagé entre plusieurs personnes |
| `A` | Administrateur | Compte administrateur local |

### 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é :

| Onglet | Visible par | Contenu |
|--------|-------------|---------|
| Personnes actives | Tous | Comptes actifs de type N |
| Arrivées prévues | Tous | Arrivées futures |
| Départs récents | Tous | 20 derniers départs |
| Boîtes partagées/Génériques | Tous | Comptes G et B |
| Tous | Tous | Ensemble des personnes |
| Désactivés | Admin local | Comptes désactivés |
| Administrateurs | Admin local | Comptes de type A |

### 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) :

| Valeur | Options proposées |
|--------|-------------------|
| `mailpro_only` | Email pro uniquement |
| `mailpro_nothing` | Email pro ou sans email |
| `mailpro_mailperso` | Email pro ou email personnel externe |
| `mailpro_all` | Email pro, sans email, ou email personnel externe |

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 :

| Onglet | Contenu | Condition |
|--------|---------|-----------|
| Fiche | Données identité, contact, fonction | Toujours visible |
| Informatique | Profils d'accès, rôles projet, matériels | Toujours visible |
| RH | Données RH | Module RH activé |
| Tickets | Tickets associés | Module Ticket + utilisateur gestionnaire |
| Droits | Droits d'accès détaillés | Toujours visible |

### Sous-onglets Informatique

| Onglet | Condition |
|--------|-----------|
| Profils d'accès | Toujours visible |
| Rôles projet | Module Projet activé + profil gestionnaire |
| Matériels | Module IT activé + droits matériels |

### 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) :

| Compteur | Condition |
|----------|-----------|
| Documentations | Module Wiki actif + droit ANNU sur 14170101 |
| Tickets | Module Ticket actif + utilisateur gestionnaire |
| Matériels | Module IT actif + droit R sur 80000101 |
| Projets | Module Projet actif + profil gestionnaire |
| Profils d'accès | Toujours visible (en rouge si 0 profil) |
| Postes / missions | Module RH actif (`dsiparam.blrh = 1`) |

### 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.

| Profil | Rôle |
|--------|------|
| `100` | Administrateur — assignable uniquement par un admin |
| `110` / `150` | Gestionnaires — peuvent modifier les profils |
| `900` | Limité — accès restreint aux entités définies dans `idlimit` |

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`.

| Champ | Description |
|-------|-------------|
| `lbfonc` | Libellé du poste |
| `tpfonc` | Type de fonction (référentiel 810079) |
| `tpcon` | Type de contrat (référentiel 810035) |
| `idc` | Entité de rattachement de la fonction |
| `blmaster` | Fonction principale active |
| `dtbegin` / `dtend` | Période de validité |

---

## 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` :

| Action | Code |
|--------|------|
| Voir l'annuaire | `ANNU` |
| Lire une fiche | `R` |
| Créer | `C` |
| Modifier | `U` |
| Supprimer/Désactiver | `D` |

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 :

| Valeur | Options proposées |
|--------|-------------------|
| `mailpro_only` | Email professionnel uniquement |
| `mailpro_nothing` | Email professionnel ou sans email |
| `mailpro_mailperso` | Email professionnel ou email personnel |
| `mailpro_all` | Email professionnel, personnel ou sans email |

### Étapes du wizard

| Paramètre | Description |
|-----------|-------------|
| `user-enable-group-step` | Active ou non l'étape "Groupe / Profil" |
| `user-enable-sante-step` | Active ou non l'étape "Santé" *(si module Santé activé)* |

### 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 :

| Valeur | Comportement |
|--------|-------------|
| `0` | Ne rien faire |
| `1` | Créer un ticket (SI ou RH) avec un sujet prédéfini |
| `2` | Envoyer un email à une adresse configurée |

**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) :**

| Valeur | Comportement |
|--------|-------------|
| `0` | Ne rien faire |
| `2` | Envoyer un email à une adresse configurée |

**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`.