@esfaenza/flow-builder 20.3.54 → 20.3.56

package/README.md

@@ -141,7 +141,7 @@ sono opzionali e rifiutano con `MissingService` se non sovrascritti.
 | `createVersion(flowName, request?)` | astratto |
 | `activateVersion(flowName, version)` | astratto |
 | `deactivateFlow(flowName)` | astratto |
-| `cloneFlow`, `deleteVersion`, `deleteFlow` | opzionali — senza `cloneFlow` «Duplica» resta disponibile e ripiega su `createFlow` |
+| `cloneFlow`, `deleteVersion`, `deleteFlow` | opzionali — senza `cloneFlow` «Duplica» resta disponibile e ripiega su `createFlow`; `deleteVersion` e' il comando del pannello versioni, mentre **`deleteFlow` non la chiama nessun componente**: eliminare un flow e' dell'ospite (vedi «Versioni») |
 
 | §6.3 Validazione | |
 |---|---|
@@ -664,6 +664,17 @@ ripulitura e' un comando («Togli»), non un effetto dell'apertura del form: can
 un flow scritto altrove farebbe sparire l'unico indizio di cosa doveva selezionare. Il rilievo si
 vede in **tutti e due** i posti, elenco e form, come gli altri controlli locali.
 
+*Da dove vengono i due campi su una collection.* Su `collectionReference` non c'e' nessun `object` a cui
+chiedere i campi: i nomi citabili sono quelli del **tipo degli elementi**, che il form legge da
+`getReferences` (`dataType` + `objectType` della collection scelta, output automatici compresi) — un
+`Object` propone i campi dell'entita', una `Structure` i membri della classe, la stessa strada del
+campo da sommare di un Transform. Su questa sorgente **nessuno dei due e' obbligatorio** (su una
+collection di scalari vanno lasciati vuoti) e la validazione **non li verifica**: un nome sbagliato
+ricade in silenzio sull'elemento intero. Per questo l'elenco si propone davvero, e un nome fuori
+elenco si dice come **avviso senza codice** (`unverified` dello structure member picker): accusarlo
+con `STRUCTURE_MEMBER_UNKNOWN` prometterebbe un rilievo che il backend lì non emette. `object` resta
+vuoto: valorizzarlo per far funzionare il picker sarebbe `CHOICE_SET_SOURCE_AMBIGUOUS`.
+
 *La logica dei filtri.* `filterLogic` **esiste anche sui choice set**, con le stesse forme degli
 elementi che interrogano il database: `AND` (o assente), `OR`, oppure l'espressione sugli indici
 1-based dei filtri (`1 AND (2 OR 3)`), che l'editor verifica mentre si scrive e **riscrive** quando
@@ -941,6 +952,19 @@ flow da sé (come la demo) il tipo lo chiede lì, e lo passa a `emptyFlowDefinit
 attivazione bloccata finche' ci sono errori, eliminazione dietro una conferma esplicita che
 spiega il rischio per le esecuzioni sospese.
 
+**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
+e' suo. La primitiva e' `deleteFlow` (§6.2, opzionale) e la sequenza e' la parte che leggendo
+l'interfaccia non si indovina: `DELETE /flows/{name}` e' **rifiutata finche' esiste una versione
+attiva**, quindi dove c'e' si chiama prima `deactivateFlow`. Sono due chiamate e non una
+transazione — se la seconda fallisce il flow resta lì, **disattivato**, e l'elenco va ricaricato
+anche sull'errore, altrimenti mostra uno stato che sul backend non esiste piu'. Disattivare ed
+eliminare cancellano anche la presa in carico presso l'infrastruttura (§8), quindi di qui tornano gli
+stessi due errori dell'attivazione: con `MissingService` il comando si spegne — e' così che degrada
+una primitiva concreta — con `RegistrationFailed` il flow c'e' ancora e «riprova» ha senso.
+L'esempio, con la conferma in due passi, sta nella demo
+([`app.component.ts`](../flow-builder-example/src/app/app.component.ts)).
+
 **Duplica.** Il flow salvato sotto un altro nome, alla versione 1 (§6.2): il comando chiede nome
 tecnico e nome visibile della copia, e l'editor **continua sulla copia** — restare sull'originale
 farebbe finire il salvataggio successivo nel flow sbagliato. Due strade, e la differenza conta: