Se nella tua app i Permessi sulle informazioni cambiano nel tempo, ad esempio a fronte di nuove informazioni caricate dagli Utenti o di eventi identificati autonomamente da Drupal (es. "dopo X giorni dalla creazione di un Contenuto"), potresti usare i Workflow per gestire le variazioni dei Permessi.
Ad esempio, nella app "Vicinato" abbiamo visto che Richieste e Prestiti non devono essere eliminate dopo la prima Consegna dell'Attrezzo e Consegne e Valutazioni non devono essere modificate dopo la loro accettazione o firma.
Cos'è un Workflow
Un Workflow è un tipo di Entità, messo a disposizione dal modulo aggiuntivo Workflow, che quindi deve essere installato ed attivato per poter usare i Workflow nella tua app.
| ATTENZIONE: tra i moduli base installati con Drupal c'è un modulo di nome "Workflows" (con la "s" finale), che però ha funzionalità molto limitate. In questa Guida e nelle successive non utilizzeremo quel modulo, ma il modulo aggiuntivo quasi omonimo "Workflow" (senza la "s" finale), da deve essere installato. |
Un Workflow è uno strumento utile per rappresentare il "ciclo di vita" di un Contenuto, inteso come una sequenza di "stati" attraverso cui il Contenuto passa dalla sua creazione alla sua eliminazione. Il passaggio da uno stato al successivo è provocato da eventi, ad esempio da un comando dato da un Utente. In ogni "stato", i Permessi dei diversi Utenti sul Contenuto possono essere differenti e ciò consente di realizzare Permessi che variano nel tempo. I Workflow assegnano i Permessi RUD (Read, Update, Delete), ma non il Permesso di creazione (Create) che quindi deve essere assegnato coi Permessi base.
Quali Workflow servono
Per identificare quali Workflow servono alla tua app, occorre anzitutto identificare quali tipi di Contenuto hanno Permessi che variano nel tempo: se i Permessi su un tipo di Contenuto non variano nel tempo è molto probabile che non serva un Workflow. Probabilmente ti serve un Workflow per ogni tipo di Contenuto i cui Permessi cambiano nel tempo. Se per due tipi di Contenuto i Permessi variano nello stesso modo, verifica se puoi applicare lo stesso Workflow ad entrambi.
Nella app di esempio "Vicinato" per i Contenuti che rappresentano informazioni sostanzialmente "statiche" - Attrezzi, Categorie, Sedi, Abilitazioni e Note- sono sufficienti le protezione base offerte da Permessi e Ruoli, mentre per i Contenuti che rappresentano il prestito e che evolvono nel tempo - Richieste, Prestiti, Consegne e Valutazioni - utilizzeremo i seguenti Workflow:
- un Workflow per le Richieste, per impedirne la modifica e l'eliminazione dopo la consegna dell'Attrezzo al Richiedente
- un Workflow per i Prestiti, del tutto simile a quello delle Richieste (distinto solo per il nome assegnato agli stati)
- un Workflow per Consegne e Valutazioni, per impedirne la modifica e l'eliminazione dopo che sono state "firmate" (passaggio necessario per consentire la correzione di errori di digitazione)
Come creare e usare i Workflow
Per creare ed usare un Workflow occorrono i seguenti passaggi:
in Configurazione - Workflow disegnare il Workflow definendone gli stati, i passaggi tra gli stati ed i Permessi assegnati agli Utenti in ogni stato
In Persone - Permessi regolare i Permessi base per coordinarli coi Permessi gestiti dal Workflow ed autorizzare gli Utenti a usare i Workflow
In Struttura - Tipo di Contenuto applicare il Workflow ad uno o più tipi di Entità o Contenuto
Disegnare il Workflow
Per disegnare un Workflow, in Configurazione - Workflow dobbiamo fornire le informazioni relative agli stati, ai passaggi tra gli stati ed ai Permessi dei diversi Utenti in ogni stato:
| crea il Workflow | In Configurazione - Workflow seleziona Aggiungi Workflow e digita il nome del nuovo Workflow |
| definisci gli stati | In Stati aggiungi gli stati previsti per il Workflow. Di default c'è sempre lo stato fittizio Creation in cui si trova l'Entità mentre viene creata |
| definisci i passaggi tra gli stati | In Transizioni attiva le caselle corrispondenti al Ruolo che fa passare l'Entità dallo stato indicato nella riga allo stato indicato in colonna. |
| dai un nome ai comandi per passare da uno stato all'altro | In Transition labels digita in Etichetta i nome dei comandi che fanno transitare tra gli stati indicati. Questa configurazione non è strettamente necessaria, perché i nomi dei comandi possono essere successivamente definiti nelle Viste che utilizzano il Workflow. |
| assegna i Permessi nei diversi stati | In Accesso attiva le caselle corrispondenti ai Ruoli cui, nello stato indicato nella riga, vogliamo concedere il Permesso indicato in colonna (View, Edit, Delete). |
Come esempio, disegniamo il Workflow delle Richieste per la app "Vicinato":
| crea il Workflow | In Configurazione - Workflow seleziona Aggiungi Workflow e nominalo "Richiesta" |
| definisci gli stati | I momenti salienti nel ciclo di vita della Richiesta sono tre: la concessione del Prestito da parte del Proprietario, la prima consegna dell'Attrezzo (dal Proprietario al Richiedente o ad un Operatore) e la riconsegna finale al Proprietario (da parte del Richiedente o di un Operatore). I tre momenti definiscono quattro stati: "Emessa" (prima dell'accettazione da parte del Proprietario), "Accettata" (dopo la concessione del Prestito e prima della prima consegna), "In corso" (tra la prima consegna e la consegna finale) e "Conclusa" (dopo la consegna finale). In Stati aggiungi quindi gli stati "Emessa", "Accettata", "In corso" e "Conclusa" |
| definisci i passaggi tra gli stati | In Transizioni attiva il passaggio Creation → Aperta per il solo Autore. Non attiviamo gli altri passaggi perché non vengono eseguiti su comando degli Utenti ma vengono eseguiti da Drupal con apposite procedure, rispettivamente dopo la creazione del Prestito, l'accettazione della prima Consegna e dopo la Consegna al Proprietario (vedi sotto). Per i Gestori attiviamo invece tutti i passaggi, perché devono poter intervenire in ogni momento per risolvere situazioni anomale. |
| assegna i Permessi nei vari stati | In Accesso, attiva il Permesso View in tutti gli stati per tutti gli Utenti (ci penseranno poi le Viste a nascondere le informazioni agli Utenti non coinvolti nel prestito); attiva Update e Delete nel solo stato Aperta per l'Autore. Disattiva tutti i Permessi dei Visitatori. Attiva tutti i Permessi per i Gestori. Nota: i Permessi negli stati "Accettata", "In corso" e "Conclusa" sono i medesimi e quindi potremmo ridurre il Workflow a due soli stati; poiché però dal punto di vista dell'Utente è utile distinguere queste situazioni manteniamo i tre stati. I Workflow servono infatti non solo per regolare i Permessi, ma anche per tracciare il ciclo di vista dei Contenuti. |
Il Workflow dei Prestiti è simile, ma bastano i tre stati "Concesso", "In corso" e "Concluso".
Il Workflow delle Consegne ha come momento saliente l'accettazione dell'Attrezzo da parte dell'Utente che lo riceve. L'evento divide il ciclo di vita della Consegna in due stati: "in corso di accettazione" e "accettata". Finché non è accettata, la Consegna può essere modificata e eliminata dall'Autore. L'accettazione non è una transizione prevista nel Workflow, perché è realizzata con un comando esterno al Workflow da parte dell'Utente che riceve l'Attrezzo. I Gestori sono invece autorizzati dal Workflow a tutti i passaggi.
Il Workflow delle Valutazioni ha come momento saliente la "firma" da parte dell'Autore stesso della Valutazione, generando quindi i due stati "da firmare" e "firmata". La transizione è previsto nel Workflow come comando "Firma" dato dall'Autore.
Da questo esempio possiamo dedurre una osservazione generale sulle transizioni in un Workflow:
- se la transizione è comandata da un Utente che può modificare l'Entità, aggiungiamo al Workflow la transizione e Drupal mostrerà all'Utente il comando di cambio di stato nella pagina di modifica dell'Entità (es. il comando "firma" sulla Valutazione, che la fa passare da "bozza" a "firmata".
- se la transizione è comandata da un Utente che NON può modificare l'Entità, non aggiungiamo al Workflow la transizione e costruiamo una procedura ECA che espone all'Utente un link che, cliccato, esegue il cambio di stato (es. il comando "Accetta" sulla Consegna, che la fa passare da "in corso di accettazione" ad "accettata")
- se la transizione è comandata da un evento che accadde nella app, non aggiungiamo al Workflow la transizione e costruiamo una procedura ECA che esegue la transizione quando occorre quell'evento (es. l'evento di creazione di una Consegna fa passare la Richiesta dallo stato "aperta" allo stato "in corso".
| SUGGERIMENTO: Il modulo Workflow non prevede la possibilità di associare una immagine agli Stati, ma solo di descriverli con un testo. Per migliorare visivamente la presentazione degli Stati, è possibile inserire nel testo che li descrive un simbolo tra quelli previsti dallo standard HTML. Ad esempio, nella app Vicinato, abbiamo aggiunto simboli colorati davanti ai nomi degli stati del Workflow che protegge le Richieste, che sono così mostrati come 🟥Emessa 🟨Accettata 🟩In corso 🟦Conclusa |
Regolare i Permessi base
L'attivazione del modulo Workflow aggiunge uno strumento di controllo dei Permessi, che deve essere coordinato coi Permessi base concessi in Persone - Permessi tenendo conto che:
| I Workflow non possono assegnare i Permessi di creazione di nuovi Contenuti. | Occorre attivare i Permessi di creazione in Persone - Permessi. Nella app di esempio "Vicinato", in Persone - Permessi attiviamo il Permesso di creazione di Richieste, Prestiti e Valutazioni per i ruoli Partecipante e Gestore ed il Permesso di creazione di Consegne per i ruoli Partecipante, Operatore e Gestore. |
| I Workflow possono assegnare ma non togliere i Permessi di modifica ed eliminazione. | Occorre togliere i Permessi di modifica e eliminazione (anche sui propri Contenuti) in Persone - Permessi, per poi concederli tramite Accesso del Workflow. Nella app di esempio "Vicinato", disattiviamo in Persone - Permessi i Permessi di modifica ed eliminazione su Richieste, Prestiti, Consegne e Valutazioni per i ruoli Partecipanti ed Operatori. |
| Ai Workflow possono partecipare solo gli Utenti autorizzati ai singoli Workflow | Occorre autorizzare la partecipazione ai singoli Workflow per i diversi Ruoli in Persone - Permessi, attivando il Permesso NOMEWORKFLOW: Participate in workflow. Nella app di esempio "Vicinato", attiviamo i Permessi "Richiesta: Participate in workflow" e "Prestito: Participate in workflow" per i Ruoli Partecipante e Gestore, il Permesso "Consegna: Participate in workflow" per Partecipante, Operatore e Gestore ed il Permesso "Valutazione: Participate in workflow" per Partecipante e Gestore. |
| APPROFONDIMENTO: Il modulo Workflow è solo uno dei numerosi moduli aggiuntivi che modificano i Permessi degli Utenti sui Contenuti. Quasi tutti questi moduli lavorano come il modulo Workflow e quindi aggiungono Permessi ma non li tolgono. Se si attiva più di un modulo aggiuntivo di gestione dei Permessi, il risultato può cambiare in base all'ordine temporale con cui i diversi moduli vengono eseguiti da Drupal: se il risultato non è quello atteso, si può cambiare l'ordine di esecuzione dei diversi moduli modificando un apposito parametro numerico nella configurazione dei moduli. Per il modulo Workflow questo parametro è modificabile in Configurazione - Workflow - Access settings - Workflow Access Priority. In generale, non è consigliabile attivare più di un paio di moduli di gestione di Permessi nella stessa installazione di Drupal. |
Applicare il Workflow
Per applicare un Workflow ad un tipo di Contenuto, basta aggiungervi un Campo di tipo Workflow State, specificando il Workflow che si intende applicare.
Nella app di esempio "Vicinato", aggiungiamo al Tipo di Contenuto "Richiesta" uno Campo Workflow di nome "Stato", specificando il Workflow "Richiesta". Analogamente aggiungiamo un Campo Workflow a Prestito, Consegna e Valutazione, sempre di nome "Stato" e specificando per ognuno il Workflow corrispondente.
Dopo l'applicazione di un Workflow (e talvolta anche dopo aver cambiato la configurazione di un Workflow) può rendersi necessaria la ricostruzione dei Permessi sulle Entità: in questo caso, Drupal mostra un messaggio all'Amministratore, che contiene il link da cliccare per ricostruire i Permessi su tutti i Contenuti. In caso di dubbi, puoi sempre lanciare la ricostruzione col comando Resoconti - Resoconto sullo Stato - Rebuild permissions.
| ATTENZIONE: le protezioni del Workflow valgono per i Contenuti aggiunti successivamente all'applicazione del Workflow al loro Tipo. Per gli eventuali Contenuti preesistenti all'applicazione del Workflow occorre inizializzare lo stato: a questo scopo conviene creare una Vista di tipo VBO (riservata all'Amministratore) in cui selezionare tutte le Entità esistenti e definirne massivamente il valore iniziale del Campo Workflow. |
Cambiare lo stato di un Contenuto
Per cambiare lo stato di un Contenuto, l'Utente modifica il valore del Campo Workflow: Drupal presenta all'Utente solo gli stati per cui è prevista nel Workflow una transizione dallo stato corrente del Contenuto. Per cambiare il valore del Campo Workflow, l'Utente deve avere il Permesso di modifica del Contenuto. Se nel nuovo stato in cui l'Utente porta il Contenuto l'Utente stesso non ha più il Permesso di modifica, non potrà più neppure cambiarne lo stato. Ad esempio, nella app "Vicinato" un Partecipante può modificare una propria Valutazione fintanto che il Campo Stato vale "Bozza"; dopo che il Campo Stato è passato a "Firmata", la Valutazione diventa immodificabile anche per lui.
Lo stato di può essere modificato anche da Drupal, mediante procedure automatiche che modificano il valore del Campo Workflow. Vedremo ad esempio come costruire la procedura che cambia automaticamente lo Stato di Richieste e Prestiti quando vengono firmate le Consegne di inizio e fine prestito. Le procedure automatiche possono essere costruire in modo da superare i Permessi e quindi forzare un cambio di stato non (più) possibile agli Utenti.