Mail templates – system description
Data model of the multilingual template master, binding by module and client, saving rules, the two kinds of deletion and the permission keys.
Overview
The template's module field decides whether it is a module template or a free mail template. There is no company content scope on the master; there is a client binding: company_client_id 0 is the system default. Table names carry the installation's own prefix in the database.
Data model
| Table | Main fields |
|---|---|
mail_template | name, module, event key, company_client_id, attachment flag, sort order, status (0, 1, 9) |
mail_template_description | per language subject, HTML and text body, attachment note |
Saving
- Permission:
canSave(template, id); status changecanAction(edit). - Language fields are stored entity-decoded; name required (1–128 characters), at least one language with subject and body.
- The module must be one of the allowed modules in the function catalogue (
error_module). - The name is unique per module and client (
error_name_taken). - The form shows the variable catalogue (
variableCatalogue).
Deletion
A template in use can only be moved to the bin with statusdelete, otherwise error_in_use; an unused template is deleted permanently with delete. Users with canSeeDeleted see the bin; the buttons follow uiMode.
Permissions
Keys: list, add, edit, delete, statusdelete, debug; not classified in the seeds, in practice UNMAPPED.