Skip to main content
Chaque application doit avoir exactement un appel à defineApplication. Il déclare :
  • Identité — identifiant universel, nom d’affichage, description.
  • Autorisations — le rôle sous lequel s’exécutent ses fonctions logiques et ses composants front-end.
  • Variables (facultatif) — paires clé–valeur exposées à votre code en tant que variables d’environnement.
  • Hooks de pré-installation / post-installation / désinstallation (facultatif) — voir Fonctions logiques.
src/application-config.ts
Notes :
  • Les champs universalIdentifier sont des identifiants déterministes que vous contrôlez. Générez-les une fois et conservez-les stables entre les synchronisations.
  • applicationVariables deviennent des variables d’environnement pour vos fonctions et vos composants front-end. Dans les fonctions logiques (côté serveur), elles sont disponibles sous process.env.VARIABLE_NAME. Dans les composants front-end, utilisez getApplicationVariable('VARIABLE_NAME') depuis twenty-sdk/front-component. Les variables marquées avec isSecret: true sont uniquement injectées dans les fonctions logiques. Les composants front-end ne reçoivent que des variables non secrètes.
  • Le rôle par défaut est détecté automatiquement à partir du fichier de rôle marqué avec defineApplicationRole() — vous n’avez pas besoin d’y faire référence depuis defineApplication().
  • Les fonctions de pré-installation, de post-installation et de désinstallation sont détectées automatiquement lors de la construction du manifeste — vous n’avez pas besoin de les référencer dans defineApplication().
  • Le passage explicite de defaultRoleUniversalIdentifier est toujours pris en charge pour des raisons de rétrocompatibilité, mais il est obsolète au profit de defineApplicationRole().
  • serverVariables sont des configurations et des secrets au niveau de l’instance (par exemple des clés d’API). Contrairement à applicationVariables, ils ne déclarent aucune valeur dans le manifeste — l’opérateur de l’espace de travail les renseigne dans les paramètres de l’application, et ils sont injectés dans les fonctions logiques uniquement une fois définis.
  • Pour afficher une interface utilisateur de configuration personnalisée dans l’onglet Settings de l’application (à la place de la section de configuration des variables par défaut), déclarez un composant frontal avec defineSettingsFrontComponent() dans son propre fichier. Un seul est autorisé par application. Les sections gérées par le système (mise à niveau automatique, App URL, connexions) restent toujours visibles.

Types de variables

applicationVariables et serverVariables acceptent tous deux un type optionnel (et, pour SELECT / MULTI_SELECT, une liste options). Types pris en charge : TEXT (par défaut), BOOLEAN, NUMBER, NUMERIC, DATE, DATE_TIME, SELECT, MULTI_SELECT, ARRAY, RAW_JSON, RICH_TEXT.
src/application-config.ts
Le type affecte uniquement la présentation et la validation — il sélectionne le champ de saisie correspondant dans l’interface des paramètres de l’espace de travail (un bouton bascule, un champ numérique, une liste déroulante, un sélecteur de date, un éditeur JSON, …) et permet au build de valider votre configuration (par exemple, SELECT / MULTI_SELECT doivent déclarer des options non vides). Il ne change pas la façon dont la valeur atteint votre code. Les valeurs sont toujours injectées sous forme de chaînes de caractères — cela est inhérent aux variables d’environnement (process.env.* est uniquement composé de chaînes). Lorsque votre fonction logique s’exécute, l’exécuteur sérialise chaque valeur selon son type déclaré lors de la construction de process.env, de sorte que le format de chaîne soit cohérent, quelle que soit la manière dont la valeur a été définie (valeur par défaut du manifeste, interface des paramètres ou version précédente) : Analysez la chaîne pour la convertir dans le type attendu :
Il en va de même pour les composants front qui lisent les valeurs via getApplicationVariable('VARIABLE_NAME') — la valeur renvoyée est une chaîne ; analysez-la selon vos besoins.

Rôle de fonction par défaut

Le rôle déclaré avec defineApplicationRole() contrôle ce à quoi les fonctions logiques de l’application et les composants front peuvent accéder :
  • Le jeton d’exécution injecté sous TWENTY_APP_ACCESS_TOKEN est dérivé de ce rôle.
  • Le client d’API typé est limité aux autorisations accordées à ce rôle.
  • Appliquez le principe du moindre privilège : déclarez uniquement les autorisations dont vos fonctions ont besoin.
Lorsque vous générez une nouvelle application, la CLI crée un fichier de rôle par défaut à src/roles/default-role.ts. Voir Rôles et autorisations pour la référence complète.

Métadonnées de la marketplace

Si vous prévoyez de publier votre application, ces champs optionnels contrôlent la façon dont elle apparaît dans la marketplace :
logoUrl et screenshots sont des alias obsolètes de logo et galleryImages. Les URL absolues externes (http:// ou https://) ne sont pas prises en charge pour ces champs : elles sont ignorées avec un avertissement au moment de la compilation. Placez plutôt les images dans le dossier public/ de votre application.