Indice

🟦Pronta 🟨Bozza 🟥Da scrivere

Protezioni che cambiano nel tempo coi Workflow

Usare i Workflow per variare nel tempo le protezioni sulle Entità
Moduli: Workflow
Aggiornata il:
Stato: 🟦Pronta

Abbiamo visto che la protezione base offerta da Permessi e Ruoli è statica: i Permessi assegnati ad un Utente su una Entità non variano nel tempo, salvo che l'Utente cambi Ruolo. Ci sono però casi in cui i Permessi devono cambiare a fronte di eventi che accadono: pensiamo ad esempio ad un documento che può essere modificato dal suo autore fintanto che non viene firmato dall'autore stesso oppure validato dal suo superiore. Anche nella app "Prestiti tra vicini" troviamo diversi esempi di Permessi che variano in funzione di eventi: una Richiesta di prestito può essere modificata o eliminata dal richiedente fintanto che il proprietario dell'Oggetto richiesto non concede il prestito; a sua volta, la Concessione può essere modificata o eliminata fintanto che non è stata effettuata la prima Consegna dell'Oggetto; una Consegna può essere modificata o eliminata fintanto che non è fisicamente avvenuto il passaggio dell'Oggetto e così via. 

Per configurare Permessi che variano a fronte si possono usare i Workflow.

Cos'è un Workflow

Un Workflow è uno strumento messo a disposizione dal modulo aggiuntivo Workflow, che quindi deve essere installato ed attivato.

Con un Workflow è possibile rappresentare il "ciclo di vita" di un Tipo di Contenuto come una sequenza di "stati" attraverso cui il Contenuto passa dalla creazione all'eliminazione finale. Il passaggio da uno stato al successivo è provocato da un evento. Ogni stato definisce i Permessi di visualizzazione, modifica ed eliminazione dei diversi Ruoli e dell'Autore su quel Tipo di Contenuto e i passaggi da uno stato all'altro autorizzati per il Ruolo.  

In particolare, lo stato del Workflow può assegnare (ma non può togliere) i Permessi di visualizzazione, modifica ed eliminazione, mentre non può intervenire sul Permesso di creazione. Perché un Workflow sia efficace, occorre quindi togliere dai Permessi base (gestiti in Persone - Permessi) i Permessi di modifica e eliminazione del Ruolo sul Tipo di Contenuto, lasciando (se necessario) il Permesso di creazione e il Permesso generale di visualizzazione dei Contenuti.

L'evento che cambia lo stato può essere:

  • La modifica manuale dello stato da parte dell'Utente. Come vedremo in dettaglio tra poco, lo stato di un Contenuto è memorizzato in un Campo di tipo "workflow" del Contenuto stesso. Il modo più semplice per cambiare lo stato di un Contenuto consiste quindi nel modificare il valore di quel Campo. Poiché il Campo workflow è un Campo come gli altri, ne consegue che un Utente può cambiare lo stato di un Contenuto fintanto che ha il Permesso di modifica su quel Contenuto. Se, in seguito al cambio di stato, l'Utente perde il Permesso di modifica del Contenuto, l'Utente non potrà più neppure modificarne ulteriormente lo stato.
  • L'esecuzione di una procedura lanciata dall'Utente. Per consentire ad un Utente di cambiare lo stato su un Contenuto per il quale non ha (più) il Permesso di modifica, si può predisporre una procedura ECA ed esporre all'Utente un comando che lancia quella procedura: la procedura sarà eseguita coi privilegi di Amministratore e supererà quindi la limitazione imposta all'Utente.
  • L'esecuzione automatica di una procedura. Una procedura ECA che modifica lo stato di un Contenuto può anche essere lanciata automaticamente da Drupal come risposta ad un evento che occorre nella app. Ad esempio, nella app "Prestiti tra vicini" quando viene scritta nella app la prima Consegna di un Oggetto nell'ambito di un prestito, parte automaticamente una procedura che cambia lo stato della Concessione da "aperta" a "in corso". Analogamente, quando viene scritta la Consegna con cui l'Oggetto torna al proprietario, parte un'altra procedura che cambia lo stato della Concessione da "in corso" a "conclusa".

Solo il primo tipo di evento viene rappresentato nel disegno del Workflow, perché gli altri sono eseguiti come eccezioni rispetto ai Permessi descritti nel Workflow.

Attivazione di un Workflow

Per attivare un Workflow su un tipo di Contenuto occorre:

  • descrivere il Workflow
  • abilitare gli Utenti all'uso del Workflow
  • applicare il Workflow al tipo di Contenuto

Descrivere un Workflow

Per descrivere un Workflow, vai in Configurazione - Workflow e ne definisci gli stati, i passaggi tra gli stati e i Permessi dei diversi Ruoli in ogni stato:

Come esempio, disegniamo il Workflow delle Richieste per la app "Prestiti tra vicini". Alla creazione, una Richiesta è "aperta" ed è modificabile e eliminabile. Mentre è "aperta" può essere modificata o anche eliminata. Diventa "in corso" - e non più modificabile ed eliminabile - quando il proprietario dell'Oggetto richiesto crea la Concessione in risposta alla Richiesta. Diventa "conclusa" quando l'Oggetto è tornato al proprietario. 

Puoi vedere altri esempi di Workflow nella pagina dedicata alla app. 

Abilitare gli Utenti al workflow

Descritto un Workflow, in Persone - Permessi appare un nuovo Permesso che, se attivato su un Ruolo, autorizza gli Utenti con quel Ruolo a partecipare al Workflow. Inoltre occorre coordinare i Permessi base con quelli aggiunti dal Workflow, tipicamente togliendo da Persone - Permessi i Permessi che sono poi concessi dal Workflow, tenendo conto che:

ARRIVATO QUI 

Applicare il Workflow alle Entità

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 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.

Cambiare lo stato di una Entità

Per cambiare lo stato di una Entità, 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 dell'Entità. Per cambiare il valore del Campo Workflow, l'Utente deve avere il Permesso di modificare l'Entità. 

Se però nel nuovo stato in cui l'Utente porta l'Entità 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 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 quando vengono accettate 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.