Ces routes gèrent les champs personnalisés des courriers. Elles ne concernent pas les champs personnalisés des contacts. Toutes sont authentifiées, les mutations exigent admin_custom_fields et portent sur l’instance complète.
Toutes les actions exigent une authentification et portent sur le référentiel global de l’instance. La lecture n’ajoute aucun contrôle de privilège, sauf pour activer la représentation d’administration demandée par admin=true. Les créations, modifications et suppressions exigent admin_custom_fields.
Avec admin_custom_fields, conserve la définition d’administration des valeurs
resId
integer
Non
Identifiant de courrier injecté dans les valeurs SQL dynamiques
Sans le mode administrateur, les valeurs sont normalisées sous la forme {key, label}. Les clés des listes sont converties en chaînes, une valeur de type integer est convertie en entier.
En mode SQL, values contient key (colonne), label (tableau de colonnes et délimiteurs), table (table autorisée) et clause (clause sans SELECT). Les colonnes contenant password ou token sont interdites.
{"label":"Nature du courrier","type":"select","mode":"form","values":["Information","Réclamation"]}
La suppression retire aussi le champ des courriers, modèles d’indexation, actions, bannettes, configurations de recherche et modèles de recherche concernés.
L'authentification et le privilège admin_custom_fields sont obligatoires. La liste est globale à l'instance.
Les tables proviennent de config/customFieldsWhiteList.json. Pour chacune, l'api interroge les colonnes réellement présentes et exclut celles dont le nom contient password ou token, sans tenir compte de la casse.