# Modèles d'e-mail

La ressource `keenauth_email_template` gère le contenu publié d'un modèle d'e-mail personnalisable : une famille (par exemple `verify_email`) dans une locale. Elle nécessite le forfait Startup ou supérieur (sinon `403 plan_feature_unavailable`).

```terraform
resource "keenauth_email_template" "verify" {
  family    = "verify_email"
  locale    = "en"
  subject   = "Confirm your email"
  html      = "<p>Confirm your email address: <a href=\"{{ link }}\">Confirm</a></p>"
  text_body = "Confirm your email address: {{ link }}"
  from_name = "Acme"
}
```

| Attribut | Description |
|---|---|
| `family`, `locale` | L'emplacement. Modifier l'un ou l'autre gère un modèle différent. |
| `subject` | Liquid, texte brut, jusqu'à 200 caractères, sans saut de ligne. |
| `html` | Fragment HTML Liquid, jusqu'à 256 KiB. |
| `text_body` | Corps en texte brut Liquid (obligatoire), jusqu'à 64 KiB. |
| `from_name` | Nom d'affichage de l'expéditeur, facultatif, jusqu'à 64 caractères. Non défini, le nom de l'application ou de l'environnement est utilisé. |
| `overwrite_pending_draft` | Facultatif, valeur par défaut `false`. Voir ci-dessous. |
| `version`, `latest_version` | En lecture seule. La version publiée, et la version la plus récente de l'emplacement. |

Le serveur vérifie le contenu à l'écriture puis à nouveau à la publication : bac à sable Liquid, HTML équilibré, constructions interdites, et présence de `{{ link }}` ou `{{ code }}`, requis par la famille, dans le HTML comme dans le corps texte.

## Application d'une modification

1. `PUT` écrit le contenu comme nouvelle version brouillon. `If-Match` correspond à la version la plus récente de l'emplacement lue en dernier (`"0"` pour un emplacement sans version).
2. `POST …:publish` publie cette version. La version précédente est archivée et reste dans l'historique (les 50 versions les plus récentes et la version publiée sont conservées).

La ressource lit la version **publiée**. Une version publiée ou restaurée dans le tableau de bord apparaît comme une dérive lors du `plan` suivant.

## Brouillons en attente

Un brouillon plus récent que la version publiée (enregistré dans le tableau de bord, ou laissé par une publication échouée) n'est jamais écrasé silencieusement :

- Un brouillon au contenu identique à votre configuration est publié sans écrire une autre version. Cela relance aussi une publication échouée.
- Un brouillon différent fait échouer la modification avec `Pending email template draft`. Publiez-le ou examinez-le dans le tableau de bord, ou définissez `overwrite_pending_draft = true` pour écrire une version plus récente par-dessus. L'ancien brouillon reste dans l'historique mais ne peut plus être publié.
- `plan` affiche un avertissement tant qu'un brouillon est en attente.

Si quelqu'un écrit dans le modèle entre `plan` et `apply`, l'API répond `412` et rien ne change. Relancez `plan`.

## Création, import et destruction

- Une création reprend un modèle publié au contenu identique. Si l'emplacement contient déjà un modèle publié au contenu différent, le provider ne l'écrase pas : importez-le avec `tofu import keenauth_email_template.verify verify_email/en` et vérifiez le plan.
- La destruction retire seulement la ressource du state. L'API n'a pas de suppression : le modèle publié et son historique restent inchangés. Revenir au modèle système par défaut n'est pas disponible via l'API ; pour changer ce qui est envoyé, modifiez le modèle ou exécutez `keenauth email-templates rollback` pour une version publiée antérieure.