@esfaenza/flow-builder 20.3.57 → 20.3.58

package/README.md

@@ -533,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
@@ -592,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
@@ -604,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:
@@ -624,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