@esfaenza/flow-builder 20.3.40 → 20.3.41

package/README.md

@@ -349,7 +349,11 @@ Tre cose che il modello non mostra e il form dice:
 - le regole di visibilita' si rivalutano **sui valori appena inviati**, i campi nascosti vengono
   **azzerati** e solo i visibili vengono validati;
 - `choiceReferences` accetta **solo** `Choice` e `DynamicChoiceSet`, e gli output automatici di un
-  `ComponentInstance` sono esclusivi con i suoi `outputParameters`.
+  `ComponentInstance` sono esclusivi con i suoi `outputParameters`;
+- `autoSelectSingleChoice` fa prendere al campo l'**unica** opzione risolta, quando e' una sola: e'
+  la tendina che dipende da un'altra tendina — i CAP di un comune — dove chiedere di scegliere non
+  decide niente. La spunta compare solo dove il tipo `acceptsChoices`, e altrove e'
+  `SCREEN_FIELD_CONFIGURATION_INVALID` (avviso).
 
 Il riordino e l'annidamento si fanno trascinando (`@angular/cdk/drag-drop`, senza drop list: il
 bersaglio si calcola dal DOM) oppure con i comandi «su / giu' / porta fuori».
@@ -400,7 +404,9 @@ Le tre cose che riguardano l'editor, e non il runtime:
 - **un trigger senza campo e senza `initBehavior` non scattera' mai**
   (`SCREEN_TRIGGER_WITHOUT_CAUSE`), e l'unico `initBehavior` ammesso e' `runOnLoad` — il
   `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.
+  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.
 
 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