Chi vede cosa, reparto per reparto
I permessi per cartella entrano in FlowSharp. Tra documenti condivisi, test su Windows e costi delle build, diventano più espliciti confini e limiti.
In un’azienda con reparti diversi non tutti devono vedere tutto. Fin qui siamo d’accordo.
FlowSharp, però, ragionava soprattutto per ruoli generali: amministratore, progettista, operatore, sola lettura. Un operatore vedeva i flussi pubblicati dell’organizzazione. Quando il prodotto deve tenere insieme aree diverse, quel criterio è troppo largo.
Martedì 15 settembre, con la v0.88.0, sono arrivati i permessi per cartella: lettura, scrittura e gestione, con regole ereditate lungo l’albero.
La ricerca è una porta, come l’elenco
L’editor dei permessi è stata la parte più immediata.
Il lavoro vero era seguire tutte le strade da cui si può incontrare un flusso: ricerca, analisi, mappe, esportazioni, integrazioni e assistenti AI. Nasconderlo nell’elenco non basta se poi riappare da un’altra parte.
Ho centralizzato la regola di accesso, invece di mantenere molti controlli soltanto simili. So che troveremo altri percorsi da verificare: il triage dei tester aveva già tredici rilievi confermati. Preferisco tenerli visibili che considerare il capitolo chiuso perché l’editor funziona.
Dichiarare una limitazione
Nella Libreria documenti ora si può leggere e correggere il testo estratto. Se una tabella di un PDF è stata interpretata male, almeno posso vedere che cosa riceverà l’assistente e sistemarlo.
Sono arrivati anche i link di download a scadenza. C’è una limitazione importante: non si possono revocare prima del termine scelto. L’interfaccia lo dice, e la durata va valutata con attenzione.
Non vorrei rendere rassicurante una funzione togliendo dalla spiegazione proprio il dettaglio che serve per usarla bene.
Anche gli automatismi hanno un costo
È diventata operativa la seconda postazione di sviluppo, su Windows. La suite completa gira in sedici minuti e trentatré secondi, in linea con il Mac.
Nel frattempo ho riguardato le verifiche su GitHub. La suite completa viene già eseguita prima delle versioni in locale; ripeterla e costruire immagini a ogni passaggio sta consumando minuti e attenzione.
Sto pensando di distinguere meglio le versioni interne dagli aggiornamenti che arrivano davvero alla demo.
Trecentoquarantaquattro commit e sei rilasci. Ci sono stati anche giorni quasi fermi, passati a riprodurre difetti segnalati dai tester. Mi è servito ricordare che capire cosa correggere è lavoro, anche quando il repository non lo rende particolarmente visibile.