# Administration fonctionnelle

Ce guide présente les fonctions qui nécessitent une attention particulière dans les paramètres ou lors de l’exploitation quotidienne.

## 1. Utilisateurs et habilitations

Les habilitations sont appliquées côté backend et pas uniquement dans l’interface.

Pour chaque utilisateur, l’administrateur peut définir :

- lecture et écriture par module ;
- tous les établissements ou une sélection ;
- tous les secteurs ou une sélection ;
- toutes les catégories professionnelles ou une sélection ;
- tous les types de contrat ou une sélection.

L’écriture implique automatiquement la lecture. Les comptes `super_admin` disposent d’un accès total protégé.

Après modification, tester avec le compte concerné :

1. la visibilité des salariés ;
2. l’accès aux onglets ;
3. les listes proposées lors de la création d’un contrat ;
4. le refus API d’une action non autorisée.

## 2. Signatures e-mail

Une signature peut être configurée depuis **Paramètres → Utilisateurs et habilitations**.

Elle contient notamment :

- le nom affiché ;
- la fonction ;
- le téléphone ;
- la société et l’adresse ;
- le site web ;
- le logo Envie sélectionné.

Lorsqu’elle est activée, la signature du compte connecté est ajoutée automatiquement aux e-mails envoyés depuis RH Connect.

Un avertissement de non-réponse est ajouté côté serveur et ne peut pas être supprimé depuis le formulaire. Le nom d’expéditeur peut être présenté comme une adresse de non-réponse, mais l’adresse technique reste celle autorisée par Microsoft Graph tant qu’aucun alias n’a été configuré par la DSI.

## 3. Fiches de paie

### Organisation attendue

Les paies sont lues depuis `PAYSLIP_ROOT_PATH`, généralement `/data/paies` dans Docker.

Exemple :

```text
Paies/
└── LESQUIN/
    └── 2026/
        └── 2026_01-Paies ENVIE 2E.pdf
```

Le nom attendu suit la convention :

```text
<ANNEE>_<MOIS>-Paies <ETABLISSEMENT>.pdf
```

Le PDF mensuel peut contenir plusieurs salariés. Une fiche commence à la page contenant le libellé `Matricule` et se termine avant le matricule suivant. L’association avec RH Connect est effectuée exclusivement grâce au matricule enregistré pour le salarié.

### Changement d’emplacement

Si le partage ou le dossier change :

1. modifier `PAYSLIP_HOST_PATH` dans `.env` ;
2. conserver `PAYSLIP_ROOT_PATH=/data/paies`, sauf changement volontaire du point de montage interne ;
3. recréer le backend :

   ```powershell
   docker compose up -d --force-recreate backend
   ```

4. vérifier le montage en lecture seule depuis le conteneur.

Ce chemin n’est pas modifiable depuis l’interface : il relève de la configuration d’infrastructure.

## 4. Modèles de documents

### Format accepté

- utiliser un fichier `.docx` sans macro ;
- ne pas importer de `.docm` ;
- écrire les champs remplaçables sous la forme `{nomChamp}` ;
- éviter de couper un champ entre plusieurs styles ou zones Word.

Lors de l’import, RH Connect détecte les champs et les rend modifiables dans le formulaire de génération.

### Cycle de vie

1. importer un nouveau modèle ou une archive depuis **Paramètres → Modèles de documents** ;
2. choisir le libellé, le code technique, la catégorie et éventuellement l’établissement ;
3. contrôler les champs détectés ;
4. ouvrir l’aperçu ;
5. activer la version validée ;
6. générer un test PDF et Word avec plusieurs salariés.

Remplacer un fichier crée une nouvelle version. L’ancienne version active reste utilisable tant que la nouvelle n’est pas activée.

Les fichiers importés sont persistés dans le volume `document_templates_data`. La base conserve les métadonnées et l’historique des versions.

### Catégories fonctionnelles

Les catégories actuellement utilisées couvrent notamment : attestations, contrats, avenants, sorties, démarches administratives, mutuelle et protection sociale, sanctions et avertissements, santé et sécurité, visites médicales.

De nouvelles catégories et de nouveaux modèles peuvent être ajoutés sans modifier le moteur de génération, à condition d’utiliser des champs compatibles.

## 5. Demandes de procédure

Le module **Autres → Demande de procédure** permet :

- d’enregistrer une demande en base ;
- de conserver son historique ;
- de télécharger un PDF ;
- d’ajouter une suite de procédure lorsque le type le permet.

La suite de procédure est activée uniquement pour :

- `Convocation entretien préalable à une sanction` ;
- `Convocation entretien préalable à un licenciement ou rupture anticipée du contrat`.

Les autres types produisent une demande simple sans page de suite.

## 6. E-mails aux salariés

Depuis **Autres → Envoyer un e-mail**, l’utilisateur peut :

- sélectionner l’adresse du salarié ;
- saisir l’objet et le contenu ;
- joindre éventuellement le PDF d’une procédure ;
- envoyer avec sa signature configurée ;
- consulter l’historique et le statut des envois.

Les e-mails sont envoyés par Microsoft Graph. Une réponse `502` indique généralement un problème de configuration, d’autorisation Graph ou de connectivité, pas une erreur de saisie du salarié.

L’envoi de SMS reste volontairement non implémenté en raison des contraintes de fournisseur, de consentement, de coût et de sécurité.

## 7. Alertes automatiques

Le planificateur est un service Docker séparé. Il appelle une route interne protégée par `ALERT_MAIL_CRON_SECRET`.

Avant activation :

1. vérifier les e-mails par secteur ;
2. utiliser l’aperçu et l’envoi de test ;
3. limiter les destinataires de test dans `.env` ;
4. contrôler l’adresse d’expédition Graph ;
5. valider l’heure et les groupes ;
6. seulement ensuite modifier `ALERT_MAIL_SCHEDULE_MODE`.

Les jalons d’une alerte ne doivent être envoyés qu’une fois. L’historique enregistré en base permet d’éviter les doublons et d’auditer les erreurs.

## 8. Swagger

Swagger UI est disponible sur `/api-docs` lorsqu’il est activé.

Les routes restent protégées par le backend. Si l’utilisateur est déjà connecté par Microsoft, Swagger transmet automatiquement son cookie SSO. Le bouton **Authorize** sert principalement à fournir manuellement un JWT Bearer.

Pour tester réellement l’absence d’authentification :

```powershell
curl.exe -i http://localhost:8000/api/employes
```

Sans cookie ni en-tête Bearer, la réponse attendue est `401 Unauthorized`.
