@esfaenza/flow-builder 20.3.56 → 20.3.58

package/README.md

@@ -173,7 +173,8 @@ sono opzionali e rifiutano con `MissingService` se non sovrascritti.
 
 **Errori.** Ogni metodo, in caso di rifiuto, deve fallire con un `FlowApiError`
 categorizzato (§10). L'editor si comporta in base alla `category`, mai leggendo il
-messaggio: `NotEditable` fa comparire «Nuova versione» al posto di «Salva»,
+messaggio: `NotEditable` (la versione e' **diventata** quella attiva) rilegge l'elenco versioni,
+e da lì compare «Nuova versione» al posto di «Salva»,
 `VersionConflict` apre il banner con «ricarica» / «salva come nuova versione»,
 `ValidationFailed` apre il pannello dei problemi con il payload.
 
@@ -532,7 +533,8 @@ cose che un editor ingenuo sbaglia lasciandole comporre per poi accusarle:
   `fieldType` dentro una riga non offre la sezione ripetibile (non si annidano: il cursore e' una
   variabile sola per sezione) e la spunta degli output automatici di un `ComponentInstance` sparisce
   — si esporrebbero come `<NomeCampo>.<NomeOutput>`, cioe' **una risorsa sola per tutte le righe**.
-  Per lo stesso motivo un campo di riga non compare fra gli inneschi di una screen action;
+  Un campo di riga **compare** invece fra gli inneschi di una screen action, che allora gira per riga
+  (vedi *Screen action*, sotto);
 - **`memberName` e il riferimento sono la stessa domanda posta due volte.** `memberName: "PodId"` e
   `PuntoCorrente.PodId` sono lo stesso membro, e la classe da cui vengono e' l'`objectType` della
   variabile in `collectionReference`: il campo si sceglie da `<fb-structure-member-picker>` con
@@ -591,9 +593,9 @@ Tre cose che il form mette a posto:
   `IsEmpty` su una collection e' un operatore che il runtime valuta, mentre la stessa domanda in una
   formula chiede al motore una funzione che potrebbe non avere. `Formula` resta un `conditionLogic`
   ammesso — qui sì, a differenza di un `filterLogic` — quindi l'editor la offre lo stesso;
-- il `fieldName` facoltativo pesca dai campi della schermata **senza quelli dentro una riga**: lo
-  stesso elenco degli inneschi, e per la stessa ragione — un campo che esiste in una copia per
-  elemento non individua un controllo a cui agganciare il messaggio.
+- il `fieldName` facoltativo pesca dai campi della schermata **senza quelli dentro una riga**: un
+  campo che esiste in una copia per elemento non individua un controllo a cui agganciare il
+  messaggio. Non e' l'elenco degli inneschi, che i campi di riga li comprende.
 
 **Screen action (§5.2).** Un campo che l'utente compila puo' **innescare un'action** i cui risultati
 finiscono negli altri campi della stessa schermata: e' il caso «scrivi il codice fiscale e nome e
@@ -603,7 +605,7 @@ campi), in **due** elenchi che il contratto tiene separati — `actions` e `trig
 trigger possono invocare la stessa action. Identificazione e parametri sono quelli di un elemento
 Action, `ACTION_UNKNOWN` e `PARAMETER_UNKNOWN` compresi.
 
-Le tre cose che riguardano l'editor, e non il runtime:
+Le cose che riguardano l'editor, e non il runtime:
 
 - **il picker della destinazione e' allargato qui e solo qui.** L'`assignToReference` di un output
   accetta anche i **campi di questa schermata**, che ovunque altrove sono di sola lettura:
@@ -623,7 +625,19 @@ Le tre cose che riguardano l'editor, e non il runtime:
   `runOnRevisit` della specifica Salesforce e' `SCREEN_TRIGGER_INIT_BEHAVIOR_UNKNOWN`, e vale la
   pena saperlo perche' chi arriva da quella specifica lo scrive per abitudine. Dove il campo
   osservato ha un `defaultValue` il form dice che `runOnLoad` **non serve**: un campo precompilato
-  dal flow conta come un campo che ha preso un valore, e l'action gira comunque all'arrivo.
+  dal flow conta come un campo che ha preso un valore, e l'action gira comunque all'arrivo;
+- **un trigger puo' osservare un campo di riga**, e allora l'action gira **per ogni riga** in cui
+  quel campo e' cambiato (*Una screen action per ogni riga*). `triggerFieldName` e' l'unico posto in
+  cui il nome di un campo di riga si scrive, perche' nomina un campo e non un riferimento: condizioni,
+  input e output nominano la riga attraverso il **cursore** (`PuntoLuce.ProductId`), e i selettori lo
+  propongono per primo. Da quel momento le destinazioni dipendono da **chi** invoca l'action, e le
+  sbagliate sono `SCREEN_ACTION_ROW_TARGET_INVALID`: da un trigger di riga il cursore intero, la
+  collection delle righe, le righe di un'altra sezione e l'output automatico (che l'editor non
+  propone nemmeno); da uno di primo livello il cursore, che fuori dalla riga non porta nessuna riga.
+  Il rilievo sta sull'output e nomina il trigger, perche' con due trigger — uno di riga e uno no —
+  la stessa destinazione e' giusta per l'uno e sbagliata per l'altro. La regola e'
+  `screenActionRowTargetIssues` (`core/screen-field.util.ts`), e la applica anche il validatore
+  della demo.
 
 Le action si aprono **una alla volta**: i cataloghi delle action e dei loro parametri dipendono da
 `actionType`/`actionName`, e tenerne N in volo sarebbe N volte la corsa fra risposte che l'inspector
@@ -948,9 +962,20 @@ esegue il flow, e cambiarlo su un documento già scritto lo lascia pieno di rife
 da quel momento non esistono — senza che nessuna primitiva del backend rimedi. Un host che crea i
 flow da sé (come la demo) il tipo lo chiede lì, e lo passa a `emptyFlowDefinition`.
 
-**Versioni.** Elenco con stato, «Nuova versione» al posto di «Salva» sulle versioni chiuse,
-attivazione bloccata finche' ci sono errori, eliminazione dietro una conferma esplicita che
-spiega il rischio per le esecuzioni sospese.
+**Versioni.** Elenco con stato, «Nuova versione» al posto di «Salva» sulla versione **attiva** —
+l'unica che non si modifica (§8) — attivazione bloccata finche' ci sono errori, eliminazione dietro
+una conferma esplicita che spiega il rischio per le esecuzioni sospese.
+
+Una versione **superata** si modifica come una bozza, ma non e' la stessa cosa, e le differenze
+sono tre. Salvata **torna bozza** (lo dice lo `status` della risposta), quindi per rimetterla in
+produzione va riattivata. Si sovrascrive solo **mandandone il numero**: un salvataggio senza
+`version` non la sceglie mai — ed e' una ragione in piu' per cui l'editor il numero lo manda sempre.
+E il **primo salvataggio si conferma**: un'esecuzione sospesa nata quando quella versione era
+attiva riprende sulla definizione modificata, e se il node su cui era ferma non c'e' piu' fallisce —
+il backend non puo' saperlo al posto di chi salva. La barra della conferma offre anche «Salva come
+nuova versione», che lascia la superata com'era. `isEditable` vale per tutt'e due i casi, e non va
+letto come «e' una bozza»: per quello c'e' `status`, come `hasDraft` nell'elenco dei flow conta le
+sole bozze.
 
 **Eliminare il flow intero e' dell'ospite.** Il pannello versioni si ferma alla **versione**: il
 flow lo toglie chi integra, perche' il builder edita un flow già aperto e l'elenco da cui toglierlo