Import en lot

bundle:import installe en une commande les Tables et les workflows préparés pour un client. Elle lit un lot JSON sur son entrée standard et s’exécute dans le conteneur de l’instance, avec sa configuration et sa base. Ni navigateur, ni session.

docker exec -i <conteneur> node dist/cli.js bundle:import \
  --owner-email admin@client.example --dry-run < lot.json

Les options

Option	Effet
--owner-email ADRESSE	Le membre propriétaire des workflows importés. Membre actif ; créer des Tables exige un administrateur.
--team-staff ID [--team-name NOM]	Le membre technique d’un compte staff du back-office, créé comme lorsque le staff ouvre l’instance.
--dry-run	Valide tout le lot et affiche le rapport. Rien n’est écrit.
--prune	Supprime les workflows importés du propriétaire (ceux qui portent une clé de lot) que le lot ne contient plus. Un workflow déjà publié, ou qui a des exécutions, est gardé et signalé. Les workflows créés autrement, les Tables, modèles et fichiers ne sont jamais supprimés. Avec --dry-run, les suppressions sont seulement annoncées.

Une option de propriétaire, et une seule, est obligatoire.

Le lot

{
  "version": 1,
  "tables": [
    {
      "slug": "zones",
      "name": "Zones",
      "description": "Département → consultant",
      "columns": [
        { "key": "departement", "label": "Département", "isKey": true },
        { "key": "consultant", "label": "Consultant", "type": "email" }
      ],
      "rows": [{ "departement": "74", "consultant": "jp@client.example" }]
    }
  ],
  "documentTemplates": [
    { "key": "attestation", "name": "Attestation de visite", "description": "Signée par l’agence.",
      "fileName": "attestation.docx", "contentBase64": "UEsDBBQ…" }
  ],
  "files": [
    { "key": "questionnaire", "name": "Questionnaire propriétaire", "fileName": "questionnaire.pdf",
      "mime": "application/pdf", "contentBase64": "JVBERi0…" }
  ],
  "workflows": [
    {
      "key": "routage",
      "name": "Router les demandes",
      "description": "Affichée en post-it au-dessus du graphe.",
      "minutesSavedPerRun": 6,
      "dsl": {
        "nodes": [
          { "id": "trigger", "type": "trigger.email", "name": "Mail reçu", "params": {} },
          { "id": "zone", "type": "table.find", "name": "Consultant",
            "params": { "table": { "mode": "id", "value": "zones" },
                        "key": [{ "column": "departement", "value": "74" }] } }
        ],
        "edges": ["trigger>zone"]
      }
    }
  ]
}

• Les Tables ont les types de colonnes de l’interface (text, number, boolean, date, datetime, select, email). Les lignes sont converties comme toute écriture de Table.
• Un workflow s’écrit en dsl (nœuds, et arêtes de>vers ou de:port>vers ; positions calculées) ou en graph, un document de workflow complet tel que le produit l’exporte.
• Les modèles de documents sont des fichiers Word (.docx, en base64, 10 Mo au plus) ajoutés à la bibliothèque de l’instance (Templates › Modèles de documents). Ils exigent un service de documents. Un nœud document.generate désigne un modèle du lot par sa clé dans son paramètre template ({ "mode": "id", "value": "attestation" }) : elle est remplacée par l’identifiant du modèle importé. Chaque modèle est vérifié par le même analyseur qu’un téléversement.
• Les fichiers vont dans la bibliothèque de l’instance (Templates › Fichiers) et sont joints en fixe par « Envoyer » : un nœud mail.send désigne un fichier du lot par sa clé dans files ([{ "file": { "mode": "id", "value": "questionnaire" } }]). 10 Mo par fichier.
• Un nœud désigne une Table par son slug. Un nœud workflow.call désigne un autre workflow du lot par sa clé : elle est remplacée par l’identifiant du workflow importé.

Ce que la commande garantit

• Tout est validé avant d’écrire. Le format, chaque cellule, chaque clé, les plafonds de l’instance et chaque graphe, avec le validateur de la publication. Une seule erreur, et rien n’est écrit.
• Des brouillons, jamais publiés. Les workflows sont créés ou mis à jour en brouillon. Un workflow déjà publié par le client garde sa version publiée : l’import enregistre un nouveau brouillon à côté.
• Un rejeu sans doublon. Une Table est retrouvée par son slug, une ligne par sa clé, un modèle de documents, un fichier et un workflow par leur clé dans le lot. Relancer le même lot met à jour ce que le premier passage a créé. Une mise à jour fusionne : une colonne absente du lot garde sa valeur.
• Une connexion manquante n’est pas une erreur. Une connexion ou une ressource requise laissée vide (Microsoft 365, la boîte d’envoi d’un workflow planifié, une organisation MyNotary) est listée en pending dans le rapport : le workflow reste un brouillon à compléter quand le client branche ses comptes. Les nœuds IA sans fournisseur branché utilisent le modèle par défaut de l’instance.

Le rapport

La commande écrit une ligne JSON :

Champ	Contenu
ok, dryRun, owner	Le résultat, le mode, le membre propriétaire
tables[]	slug, action (create ou update), addedColumns, rows (planned, inserted, updated, skippedNoKey)
documentTemplates[]	key, action, id, fields (le nombre de champs trouvés dans le modèle)
files[]	key, action, id
pruned[]	key, id, outcome (deleted, would_delete, kept_published, kept_has_executions)
workflows[]	key, action, id, pending[] (nœud et paramètre à compléter), warnings[]
errors[]	where (bundle, table:<slug>, documentTemplate:<clé>, workflow:<clé>), code, message

Codes de sortie : 0 fait (ou validé), 2 erreur d’usage, 3 refusé (lot ou JSON invalide, membre inconnu), 1 erreur inattendue.

Les limites

• Sans --prune, rien n’est supprimé. Avec, seuls les workflows importés jamais publiés le sont.
• L’import ne convertit jamais le type d’une colonne : changez-le d’abord dans l’interface.
• Le lot est lu sur l’entrée standard, 32 Mo au plus.