InstallPayload ({ previousVersion?: string; newVersion: string } — previousVersion est undefined lors d’une nouvelle installation), mais ils sont déclarés avec leurs propres fonctions de définition et ne relèvent pas du modèle de déclencheur habituel (HTTP, cron, événements de base de données).
Chaque application peut définir au maximum une pré-installation et au maximum une post-installation. La génération du manifeste renvoie une erreur si plus d’une fonction de l’un ou l’autre type est détectée.
En un coup d’œil
Règle empirique : privilégiez post-install par défaut. Ne recourez à la pré-installation que lorsque la migration elle-même est destructive et que vous devez intercepter l’état précédent avant qu’il ne disparaisse.
Comportement partagé par les deux hooks
- La configuration est une configuration
defineLogicFunctionmoins les paramètres de déclencheur, plusshouldRunOnVersionUpgrade. - Quand il s’exécute : uniquement lors des nouvelles installations, par défaut. Définissez
shouldRunOnVersionUpgrade: truepour qu’il s’exécute également lors des mises à niveau. UtilisezpreviousVersion/newVersionpour bifurquer selon le chemin de mise à niveau. - L’idempotence est importante : le post-install asynchrone peut être relancé, et chaque hook est réexécuté lors des mises à niveau lorsque
shouldRunOnVersionUpgradeest activé. - L’environnement habituel des fonctions logiques (
APPLICATION_ID,APP_ACCESS_TOKEN,API_URL) est injecté, ce qui vous permet d’appeler l’API Twenty avec le jeton de votre application. - Le hook est rattaché automatiquement au manifeste de l’application au moment de la compilation (
preInstallLogicFunction/postInstallLogicFunction) — rien à référencer dansdefineApplication(). - La valeur par défaut de
timeoutSecondsest 300 pour permettre des tâches de configuration plus longues comme l’initialisation des données. - Non exécuté en mode dev :
yarn twenty devignore le flux d’installation et synchronise directement les fichiers, donc les hooks ne s’exécutent jamais dans ce cas. Déclenchez-les manuellement à la place :
definePostInstallLogicFunction
S'exécute après l'application de la migration des métadonnées de l'espace de travail
definePostInstallLogicFunction
S'exécute après l'application de la migration des métadonnées de l'espace de travail
S’exécute une fois que votre application a terminé son installation : métadonnées synchronisées, client SDK généré, nouveau schéma interrogeable. Exemple — initialiser un enregistrement par défaut lors des nouvelles installations :Le drapeau
src/logic-functions/post-install.ts
shouldRunSynchronously contrôle le modèle d’exécution :false(par défaut) — mis en file d’attente dans la file de messages (retryLimit: 3) et exécuté par un worker. La réponse d’installation est renvoyée dès que la tâche est mise en file d’attente. À utiliser pour les travaux de longue durée — initialisation de grands ensembles de données, API tierces lentes.true— exécuté en ligne pendant le flux d’installation. La requête d’installation est bloquée jusqu’à ce que le gestionnaire ait terminé ; une erreur levée apparaît commePOST_INSTALL_ERRORpour l’appelant (aucune nouvelle tentative). À utiliser pour les travaux rapides qui doivent être terminés avant la réponse. La migration a déjà été appliquée à ce stade, donc un échec n’annule pas les modifications du schéma — il ne fait que remonter l’erreur.
definePreInstallLogicFunction
S'exécute avant l'application de la migration des métadonnées de l'espace de travail
definePreInstallLogicFunction
S'exécute avant l'application de la migration des métadonnées de l'espace de travail
S’exécute avant la migration des métadonnées, sur le schéma précédent — l’endroit idéal pour sauvegarder des données qu’une migration ferait perdre, ou pour refuser une mise à niveau risquée. Avant l’exécution, le serveur effectue une « synchronisation réduite » purement additive qui enregistre uniquement la fonction de pré-installation de la nouvelle version ; tout le reste — les objets, champs et données de la version précédente — reste intact lorsque votre gestionnaire s’exécute.La pré-installation est toujours synchrone et bloque l’installation. Si le gestionnaire lève une exception, l’installation est abandonnée avant toute modification du schéma — l’espace de travail reste sur la version précédente dans un état cohérent. C’est intentionnel : la pré-installation est votre dernière chance de refuser une mise à niveau risquée.Exemple — copier les valeurs d’un champ hérité avant que la migration ne le supprime :
src/logic-functions/pre-install.ts