Cascade multi-projet : gérer N sujets comme un seul graphe
Vingt filiales, vingt projets OrgGen distincts, un seul graphe de navigation : un bloc rattaché à un autre projet affiche une pastille et se plonge en ligne, sans copie. Ce guide distingue rattacher / créer vide / forker — trois gestes qu'on confond facilement — et montre ce que la cascade de partage ouvre vraiment, et à qui.
Trois verbes, trois intentions — ne pas les confondre
| Outil | Le projet cible | Quand l'utiliser |
|---|---|---|
| `link_project_to_cell` | EXISTE déjà | rattacher un projet qui vit déjà séparément (droits et cycle de vie distincts) |
| `create_nested_project` | n'existe PAS encore | démarrer un sous-sujet vide sous ce bloc — l'inception : détail poussé un niveau plus bas |
| `fork_linked_project` | existe, rattaché, mais en lecture seule pour toi | en obtenir une copie MODIFIABLE, dont tu deviens propriétaire |
Le piège le plus fréquent est d'appeler `create_nested_project` en pensant rattacher un projet existant : il refuse si le bloc porte déjà un rattachement, mais si le bloc est libre, il CRÉE un schéma neuf et VIDE — pas ce qu'on voulait dire.
link_project_to_cell({
cellId: "filiale-tech",
projectId: "a1b2c3d4-e5f6-4789-a012-3456789abcde",
label: "Architecture cible AWS",
})Lire une arborescence entière sans changer de projet
`get_linked_project` lit à travers le rattachement — un aperçu (titre, compteurs, squelette des blocs), jamais le contenu détaillé. Avec `depth`, il descend la chaîne sur plusieurs crans : utile pour construire une vue d'ensemble sur une hiérarchie de sujets rattachés sans naviguer projet par projet.
get_linked_project({ cellId: "holding-groupe", depth: 3, includeBlockTitles: true })La lecture RE-RÉSOUT l'accès à chaque cran. Un droit sur le projet racine n'ouvre pas automatiquement ce qu'il rattache plus bas : chaque projet de la chaîne exige sa propre autorisation, honorée exactement comme si on l'ouvrait directement.
Ce que la cascade de partage ouvre — et à qui
Partager le projet racine avec un collaborateur ouvre-t-il aussi les projets rattachés plus bas ? Oui, mais à UNE condition précise : le lien doit avoir été posé par un GOUVERNANT (propriétaire ou gestionnaire) du projet hôte. Un simple éditeur peut poser un rattachement — il reste alors utilisable par lui seul, jamais ouvert en cascade aux autres collaborateurs de l'hôte.
| Qui pose le lien | Ce que les autres collaborateurs de l'hôte obtiennent |
|---|---|
| Propriétaire ou gestionnaire | cascade ouverte — accès automatique au projet rattaché |
| Simple éditeur | aucune cascade — le lien reste personnel à qui l'a posé |
L'édition EN LIGNE d'une scène rattachée (déplacer une carte, ouvrir son panneau, modifier son contenu) suit une règle séparée : elle s'ouvre dès que tu as un vrai droit d'écriture sur la CIBLE — rôle qui écrit, accès non borné à un seul bloc, aucun verrou d'écriture posé, lien non figé sur une ancienne version. Sinon, c'est lecture seule, et modifier exige d'ouvrir ce projet directement.
Quand la lecture seule ne suffit plus : forker
Un projet rattaché reste parfois en lecture seule malgré tout — un accès borné à un seul bloc partagé, une version figée (pin), ou un rôle qui n'écrit pas sur la cible. `fork_linked_project` en fabrique une copie INDÉPENDANTE dont tu deviens propriétaire, et repointe le bloc hôte vers cette copie.
fork_linked_project({ cellId: "filiale-tech", name: "Architecture AWS — copie éditable" })Essaie sur ton propre cas
Décris ta situation en une phrase — OrgGen construit le schéma et fait le calcul.
Essaie sur ton propre cas