106 lines
5.6 KiB
Markdown
106 lines
5.6 KiB
Markdown
# Signatures CABM
|
|
|
|
Gestion centralisée des signatures email des agents de la CA Béziers Méditerranée :
|
|
un **add-in Outlook** insère automatiquement la signature (OWA, nouvel Outlook, Outlook mobile),
|
|
un **back-office Laravel** gère templates, affectations par groupes AD, campagnes et portail agent.
|
|
|
|
Architecture et lotissement : document « Signatures email CABM — Architecture et lotissement ».
|
|
|
|
## Structure
|
|
|
|
```
|
|
AddinOutlook/
|
|
├── addin/ Add-in Outlook (TypeScript, manifeste XML, NAA)
|
|
│ ├── manifest.xml Modèle ; la version finale est générée dans dist/ au build
|
|
│ └── src/
|
|
│ ├── launchevent/ Gestionnaires OnNewMessageCompose / OnNewAppointmentOrganizer / OnMessageFromChanged
|
|
│ ├── taskpane/ Volet « Ma signature » (aperçu, réinsertion, lien portail)
|
|
│ └── shared/ Authentification NAA, appel API, cache roamingSettings
|
|
├── backend/ Fichiers du back-office, à fusionner avec un Laravel neuf (install-backend.ps1)
|
|
│ ├── app/Signature/ Rendu des templates, choix du template, calcul de la signature
|
|
│ ├── app/Services/ Client Graph, synchro annuaire, validation des jetons Entra
|
|
│ ├── database/ Migration du modèle de données, seeders, templates d'exemple
|
|
│ └── tests/ Tests unitaires et fonctionnels (php artisan test)
|
|
├── docker/ Image PHP-FPM, Nginx (certificat wildcard), entrypoint
|
|
├── docker-compose.yml app + scheduler + nginx + mariadb
|
|
├── docs/
|
|
│ ├── 01-entra-app-registrations.md Inscriptions Entra, groupes AD, déploiement Integrated Apps
|
|
│ └── 02-deploiement.md VM DMZ, flux Stormshield, exploitation
|
|
└── install-backend.ps1 Installation du back-office sur le poste de dev (Laragon)
|
|
```
|
|
|
|
## Démarrage sur le poste de dev (Laragon)
|
|
|
|
1. Créer les deux inscriptions Entra et les groupes AD : `docs/01-entra-app-registrations.md`.
|
|
2. Back-office, dans le terminal Laragon :
|
|
```powershell
|
|
cd C:\laragon\www\AddinOutlook
|
|
powershell -ExecutionPolicy Bypass -File .\install-backend.ps1
|
|
```
|
|
Le script crée un Laravel neuf, y ajoute nos fichiers, installe `firebase/php-jwt`,
|
|
`laravel/socialite`, `socialiteproviders/microsoft-azure`, prépare `.env` et lance les tests.
|
|
3. Compléter `backend\.env` (base MySQL Laragon, identifiants Entra), puis :
|
|
```powershell
|
|
cd backend
|
|
php artisan migrate --seed
|
|
php artisan signature:sync --full
|
|
php artisan serve
|
|
```
|
|
Pour un hôte virtuel Laragon, faire pointer la racine web sur `backend\public`.
|
|
4. Add-in :
|
|
```powershell
|
|
cd ..\addin
|
|
copy .env.example .env # compléter
|
|
npm install
|
|
npm run build # produit dist\ (dont dist\manifest.xml)
|
|
npm run validate # validation du manifeste par le service Microsoft
|
|
```
|
|
|
|
L'add-in doit être servi en HTTPS avec un certificat de confiance : les tests se font sur la VM DMZ
|
|
(`docs/02-deploiement.md`) avec un chargement manuel du manifeste dans Outlook web.
|
|
|
|
## API
|
|
|
|
`GET /api/v1/signature?context=new|reply|forward|appointment&mailbox=<adresse>`
|
|
En-tête `Authorization: Bearer <jeton Entra NAA>` → `{ html, variant, template, generated_at }`.
|
|
|
|
- Template : groupe `signature_mail_*` de plus haute priorité, sinon template par défaut.
|
|
- Réponse / transfert : variante choisie par l'agent (courte, complète, aucune), défaut `short`.
|
|
- Boîte partagée déclarée : son template, avec ou sans le nom de l'agent selon le réglage de la boîte.
|
|
- Bannière : une seule par signature, insérée par `{{{banniere}}}` dans la variante complète uniquement.
|
|
Parmi les campagnes actives et en cours qui ciblent l'agent (tous, ou un de ses groupes), la priorité la plus
|
|
haute l'emporte ; à égalité, la plus ancienne.
|
|
|
|
## Campagnes (bannières)
|
|
|
|
Écran `/admin/campagnes` : image (choisie dans la bibliothèque ou envoyée depuis le formulaire), texte alternatif
|
|
obligatoire, lien facultatif, période en heure de Paris, priorité, groupes AD ciblés (aucun = tous les agents).
|
|
|
|
- L'éditeur prépare les campagnes : elles restent inactives. L'administrateur active, modifie une campagne
|
|
active et supprime.
|
|
- La liste indique le nombre d'agents qui reçoivent réellement chaque campagne en cours (0 = masquée par une
|
|
campagne plus prioritaire) et signale les templates publiés sans `{{{banniere}}}`.
|
|
- Aucun cache à purger : l'add-in interroge l'API à chaque nouveau message, la bannière apparaît et disparaît
|
|
donc à l'heure. Les messages déjà envoyés la conservent tant que l'image reste dans la bibliothèque.
|
|
|
|
## Syntaxe des templates
|
|
|
|
| Syntaxe | Effet |
|
|
| --- | --- |
|
|
| `{{prenom}}` | Valeur échappée |
|
|
| `{{#if mobile}}Mob. {{mobile}}<br>{{/if}}` | Ligne masquée si le champ est vide |
|
|
| `{{#unless x}}…{{/unless}}` | Bloc affiché si le champ est vide |
|
|
| `{{{banniere}}}` | Bannière de campagne (HTML généré par le serveur) |
|
|
|
|
Variables : `prenom`, `nom`, `nom_complet`, `fonction`, `service`, `organisation`, `bureau`, `telephone`,
|
|
`mobile`, `email`, `adresse`, `code_postal`, `ville`, `site_url`, `banniere`, et pour une boîte partagée
|
|
`boite_nom`, `boite_email`.
|
|
|
|
## Contenu du lot 0 et suite
|
|
|
|
Livré : socle complet (modèle de données, synchro Graph delta toutes les 15 min, API signature,
|
|
validation des jetons, add-in avec cache de secours, SSO, rôles par groupes AD, tableau de bord, portail en aperçu).
|
|
|
|
Lots suivants : écrans d'édition des templates (HTML + éditeur visuel), affectations et priorités,
|
|
boîtes partagées, campagnes, champs modifiables par l'agent et préférence de réponse, journal d'audit consultable.
|