Formulaire de départ utilisateur

Parcours unifié de départ d'un utilisateur dans le module Isi-Identité. Symétrique au wizard d'arrivée existant (App\Livewire\User\CreateUser).

À qui ça s'adresse

Tous les tenants abonnés au module Isi-Identité (tag youzer). Sans ce module, les écrans et boutons décrits ci-dessous restent invisibles.

Les actions sont accessibles aux profils ayant le droit manageAccessRights('U', $userId, 12000101) pour ouvrir le wizard et manageAccessRights('D', …, 12000101) pour la réintégration.

Pourquoi cette feature

Avant cette feature, gérer le départ d'un utilisateur était fragmenté : édition manuelle de la date de départ dans le formulaire générique, désactivation via un bouton dédié, archivage dans la sidebar, transformation en boîte partagée par une autre modale. Aucun parcours unifié.

Le formulaire de départ orchestre tout en un seul assistant, depuis la fiche utilisateur, et trace la décision dans un wizard à étapes.

États d'un utilisateur

Une personne dont la date de départ est passée disparaît immédiatement des annuaires actifs mais reste consultable dans les onglets « Départs récents » et « Tous » : son archivage n'intervient qu'au terme du délai configuré (voir ci-dessous).

Paramétrage — /param-dsi/users

Le bloc « Formulaire de départ » apparaît sous le bloc existant « Alertes programmées » (uniquement si youzer est actif). Il pilote la table dsi_param_departure (une ligne par tenant).

Section Tickets RH / SI

Pour chaque service (SI, RH) indépendamment :

• Action : Ne rien faire, Créer un ticket, Envoyer un mail seul.
• Sujet :
  • Si action = Créer un ticket → liste déroulante recherchable des sujets de ticket (même source que la config création).
  • Si action = Envoyer un mail seul → champ texte libre (l'objet du mail).
• Position du bloc info utilisateur : Aucun, En haut, En bas. Contrôle l'insertion du récap utilisateur dans le corps du ticket/mail.
• Trame : éditeur riche. Placeholders supportés : {forname}, {name}, {dtdep}, {recipient_name} (résolus à l'envoi).

Section Mail au repreneur

• Sujet du mail : champ texte libre, placeholders supportés.
• Position des informations utilisateur : Aucun / Haut / Bas — par défaut Bas à l'envoi si non précisé (les infos sont toujours incluses dans le mail repreneur).
• Corps du mail : éditeur riche avec placeholders.

Le bouton « Enregistrer le formulaire de départ » sauvegarde uniquement ce bloc. Le bloc « Alertes programmées » garde son propre bouton « Enregistrer » (cron pré-départ inchangé).

Lancer un départ

Depuis la fiche utilisateur, dans la sidebar d'actions, le bouton rouge « Formulaire de départ » ouvre une modal contenant le wizard. Le bouton est caché si l'utilisateur est déjà parti, déjà planifié, ou s'il s'agit de soi-même.

Les étapes

1. Date & motif — date de départ (obligatoire, ≥ aujourd'hui) et motif libre optionnel.
2. Tickets RH / SI — affichée uniquement si au moins une action est configurée. Toggle par service, sujet et contenu pré-remplis depuis la config, librement éditables. Le sujet d'un ticket est un select recherchable (libellé affiché), celui d'un mail est un champ texte (objet libre).
3. Transition & passation — deux options indépendantes :
   • Transformer en boîte partagée (tpaccount = 'B') — la transformation passe par UserAction::run() qui gère le vidage de cache nécessaire.
   • Notifier un repreneur par mail — choix entre l'utilisateur partant lui-même (auto-passation) ou son manager désigné. L'option manager est désactivée si l'utilisateur n'a pas de idmanager.
4. Récapitulatif — visualisation lecture seule en cards Onyx (Utilisateur, Date & motif, Tickets, Transition). Bouton « Confirmer le départ » → modal de confirmation Onyx, puis exécution.

À la validation (en une transaction) : la fiche est mise à jour, les tickets sont créés (blisi_identity = 1) ou les mails envoyés selon le paramétrage, la transformation est appliquée si demandée, le mail repreneur part. La modal se ferme et la fiche est rechargée.

Archivage différé des départs

Le départ inactive la personne ; l'archivage de sa fiche est différé.

• Délai paramétrable par tenant dans Param DSI › Gestion des personnes › Informations générales, champ « Archivage automatique des départs (jours) ».
• 365 jours par défaut (champ laissé vide). 0 rétablit le comportement historique (archivage dès le lendemain du départ).
• L'archivage est réalisé par la tâche planifiée quotidienne user:delete.
• Ce réglage s'applique à tous les tenants, y compris ceux sans le module Isi-Identité.

Pendant le délai, la personne est absente des annuaires actifs mais reste visible dans « Départs récents » (avec une colonne Archivage indiquant « Non archivée » ou la date d'archivage) et dans « Tous » : elle peut donc être prolongée ou réintégrée sans passer par la corbeille.

Traçabilité de l'archivage

La fiche d'une personne archivée affiche un encart précisant quand et par qui :

• « Fiche archivée automatiquement le JJ/MM/AAAA, la date de départ étant dépassée du délai configuré. » pour un archivage par la tâche planifiée ;
• « Fiche archivée le JJ/MM/AAAA par Prénom Nom. » pour un archivage déclenché depuis l'interface (bouton « Archiver la fiche » ou action de masse dans l'annuaire).

Les fiches archivées avant la mise en place de cette trace n'affichent que la date, tout comme celles archivées par un canal automatisé qui ne la renseigne pas (API Isi-Identité, synchro Azure, import de masse). L'archivage apparaît également dans le panneau « Activité » de la fiche. La trace est effacée en même temps que l'archivage (restauration depuis la corbeille, réintégration, prolongation).

Accès : une personne dont la date de départ est passée ne peut plus se connecter, même si sa fiche n'est pas encore archivée — et sa session en cours est fermée au prochain chargement de page.

Prolonger un départ

Quand un départ est planifié, passé ou déjà archivé, le bouton « Prolonger » ouvre une modale qui ne modifie que la date de départ — le motif et les actions déjà réalisées (tickets, mails, boîte partagée) sont conservés. C'est le geste attendu pour une prolongation de contrat ou un report de fin de mission, là où « Réintégrer » efface toutes les dates.

Si la personne était archivée et que la nouvelle date de départ est à venir, sa fiche est automatiquement désarchivée : elle réapparaît dans les annuaires actifs.

Réintégrer un utilisateur

Quand l'utilisateur est en état « départ planifié », « parti » ou « archivé », le bouton « Réintégrer » remplace celui de départ. Confirmation Onyx puis :

• dtdep, dtdel, dtdes, motifdes repassent à null, ainsi que la trace d'archivage.
• Le type de compte (tpaccount) n'est pas modifié : si l'utilisateur a été basculé en boîte partagée, repasser à « Nominatif » via la modal « Transformer l'utilisateur » existante.

Mails envoyés

Tous utilisent le layout ISI (logo + footer).

Garde dev : hors environnement prod, tous les mails (RH/SI et repreneur) partent vers SUPPORT_EMAIL (.env). Aucun courrier n'atteint les vrais utilisateurs/managers en dev/staging.

Champ « date de départ » dans le mod générique

Quand youzer est actif sur le tenant, le champ dtdep (idfield 12000035) du formulaire générique utilisateur passe en lecture seule. La modification de cette date n'est possible qu'à travers le wizard de départ, le bouton « Prolonger » ou le bouton « Réintégrer ». Sur les tenants sans youzer, le comportement reste inchangé.

Coexistence avec les autres mécanismes

Aucune des fonctionnalités existantes n'est retirée :

• « Archiver » (sidebar) — toujours fonctionnel.
• « Désactiver » (UserCtl::disableUser) — toujours fonctionnel.
• « Transformer » l'utilisateur — toujours fonctionnel.
• Cron pré-départ (Alertes programmées) — toujours actif, indépendant du formulaire.