CHARTA

Descrizione

Charta è un’applicazione web per la gestione di documenti digitali.

Sarà utilizzata sia da Galileo che da aziende clienti che la richiedono come servizio di archiviazione.

Deve essere utilizzata da operatori, che caricano i documenti e li taggano, e da utenti visualizzatori, che leggono e scaricano i documenti.

Il caricamento di un documento avviene tramite queste fasi:

Scan

Tag

Control

Publish

Queste fasi sono effettuate in ordine da diversi operatori in diversi momenti.

Dopo ogni fase il documento cambia stato e resta in attesa di essere gestito da un operatore nella fase successiva

1. Fase di scan

Un operatore scannerizza i vari file che compongono un documento digitale (che viene creato in questo momento), sceglie il nome del documento, il realm di appartenenza e la classe del documento.

Il realm è il dominio al quale appartiene il documento. In genere ogni azienda cliente corrisponde a un realm.

La classe del documento è la tipologia, ad esempio contratto, cedolino, fattura ecc.

2. Fase di tag

Un operatore tagga il documento, compilando dei campi predisposti che variano a seconda della classe del documento.

Se ad esempio il documento è un cedolino dell'azienda X, l'interfaccia fornirà all'operatore l'insieme di campi da compilare previsti per i cedolini dell'azienda X.

I valori che l'operatore dovrà inserire all'interno di questi campi sono informazioni già contenute all'interno dei file scansionati, e questa fase serve a renderli digitali per permettere agli utenti finali di fare ricerche filtrando sulla base del valore dei tag.

Bisogna inoltre implementare un sistema di OCR o comunque un intelligenza artificiale che assista l'operatore compilando i campi in modo automatico leggendo i file scansionati.

In questa fase l'operatore deve avere da un lato la preview del documento, con pagina scorribile, e dall'altro lato i campi dei tag dentro cui inserire i valori.

3. Fase di control

Un operatore controlla i tag di un documento e verifica se combaciano con i valori del vero documento, che l'operatore può vedere tramite una preview.

L'operatore deve poter segnalare i tag che non sono stati compilati correttamente e rimandare il documento alla fase precedente, oppure correggere personalmente i tag sbagliati e mandare il documento alla fase successiva.

4. Fase di publish

Un operatore decide di approvare la pubblicazione di un documento o di mandarla alla fase precedente.

Decide anche chi potrà visualizzare il documento una volta pubblicato.

Visualizzazione

Gli utenti possono visualizzare e scaricare i documenti all'interno di una pagina che mostra i documenti aperti recentemente e un sistema di ricerca, in grado di filtrare i documenti per classe e valore dei tag.

Gli utenti possono vedere solo i documenti su cui hanno accesso di lettura. Se l'utente è l'owner del documento, può sempre vederlo, altrimenti deve essere membro di una acl che è stata collegata al documento da parte di un operatore al momento della pubblicazione.

Ruoli

Ogni operatore appartiene a dei gruppi che stabiliscono i ruoli che l'operatore avrà sui diversi realm e sulle loro classi.

Un operatore quindi potrebbe avere un ruolo in un realm e un ruolo diverso in un altro realm.

Ad esempio: un operatore può scannerizzare e taggare documenti per l'azienda X e può pubblicare documenti per l'azienda Y.

Deve quindi essere possibile fare login, selezionare un realm e poi eventualmente fare lo switch a un differente realm, senza dovere fare login nuovamente.

Analisi dei permessi e dei gruppi

PROBLEMA: Esistono due tipi di permessi

Permessi di tipo operativo, che vogliamo associare a cose generali come i realm e le classi dei documenti

Permessi di visibilità sui singoli documenti

Soluzione 1 (SCARTATA)

Un utente appartiene a più gruppi

Un gruppo ha certi permessi di tipo operativo (es. può scannerizzare i file all'interno di un certo realm) e certi permessi di visibilità sui singoli file (es. un operatore vuole che un documento sia visibile da tutti i dipendenti dell'area marketing)

Problema: In base a cosa vengono creati i gruppi?

In base ai permessi operativi? La maggior parte degli utenti non ha permessi operativi.

In base ai permessi di visibilità? I permessi di visibilità in genere si danno ai gruppi di lavoro, ad esempio i dipendenti di un settore, o il gruppo dei manager ecc.

Ma queste divisioni non c'entrano con i permessi operativi e ci troveremo con utenti con gli stessi permessi operativi all'interno di gruppi di lavoro diversi.

Soluzione 2

Un utente appartiene a più ACL e più GROUP

Definizione di ACL e GROUP:

La ACL fornisce ai propri membri l'accesso di lettura sui singoli documenti ad esso associati

Il GROUP fornisce ai propri membri un ruolo su tutti i documenti appartenenti ai realm e alle classi ad esso associate

Il ruolo può essere scan, tag, correct, publish, read, all (comprende tutti i precedenti ruoli)

Differenza:

Le ACL vengono associate ai singoli documenti

I group vengono associati ai realm e alle classi

Con i group, oltre ai ruoli di scan, tag, ecc, esiste il ruolo read, che può dare ad alcuni utenti speciali (non solo agli operatori interni) i permessi di lettura a tutti i documenti di un certo realm, o di una certa classe all'interno di un realm

Con le ACL, un operatore che carica un documento può scegliere i permessi di lettura che avrà il singolo documento una volta pubblicato, associandolo a delle liste che non hanno niente a che vedere con le suddivisioni operative o gli utenti speciali

Esempi di permessi

Un documento è leggibile da:

Utente owner del documento

Utenti membri di un group con accesso al documento

Utenti membri di un supergroup con ruolo “read” sul realm e sulla classe del documento

Un documento è scannerizzabile da:

Utenti membri di un supergroup con ruolo “scan” sul realm nel quale si vuole salvare il documento scannerizzato

Esempi della tabella dei role

Superg Ruolo Realm Classe
s1 SCAN 2 ALL
s2 TAG 2 cedolini
s2 CORRECT 3 fatture
s3 ALL ALL ALL
s4 READ 2 ALL

nell'implementazione pratica, per questa tabella si può associare “ALL” al valore nullo all'interno del database

Schema del db proposto

Spiegazione:

Un documento è un oggetto composto da:

Un certo numero di file

Un insieme di tag a cui vengono attribuiti dei valori

Una class (tipologia, ad es. cedolino, contratto, ecc.)

Ogni class di documento ha diversi tag da riempire (es. cedolino chiede il numero fiscale, contratto chiede data di scadenza), essi acquisiranno dei valori solo quando verranno associati a un documento

>Ogni classe appartiene a un realm, poiché diversi realm possono avere diverse definizioni della struttura di un cedolino o di un contratto

Gli utenti (user) appartengono a:

acl, che ne determinano i permessi di accesso in lettura sui singoli documenti

group, che ne determinano il ruolo sopra ai realm e sulle class all'interno dei realm

I ruoli (role) possono essere:

SCAN, o UPLOAD: l'utente può creare nuovi documenti, decidendone realm, class (e owner?)

TAG: l'utente può aggiungere tag al documento

CORRECT: l'utente può correggere i tag o segnalare gli errori

PUBLISH: l'utente può rendere pubblico il documento decidendo i gruppi che ne hanno accesso

READ: l'utente può leggere i documenti pubblicati

Utilizzo dell'applicazione

Di seguito verrano descritte le varie fasi nei dettagli concentrandosi sull'utilizzo da parte degli utenti.

NOTA IMPORTANTE: Le interfacce utente vanno disegnate tenendo conto delle abilità degli utenti. Per esempio, le fasi di TAG che avvengono all'interno di Galileo saranno probabilmente svolte da operatori con disabilità, occorre quindi semplificare le operazioni, in particolare l'input (bottoni molto grandi ecc.)

Fase di scan

Accesso

L'operatore fa login, entra nella sezione “Scan” dal menù laterale, poi seleziona il realm nel quale vuole creare il nuovo documento da una selection list di tutti i realm sul quale l'operatore ha ruolo di scan.

Scannerizzazione e upload

All'operatore si presenterà una schermata interattiva in cui può decidere se:

trascinare un file all'interno di un'area

premere il tasto “Scansiona” per far partire uno scanner connesso alla macchina client

La scansione deve bypassare il sistema operativo ed essere più intuitiva possibile e un unico click dovrebbe scansionare e fare l'upload del file.

Potrebbero essere aggiunte anche alcune impostazioni di scannerizzazione da selezionare che vengono salvate.

Possibile implementazione: un documento “draft” viene creato in questo momento, e i file caricati si legano al documento draft. Se l'utente abbandona l'applicazione e ritorna, deve essere caricata l'ultima draft creata, da cui l'operatore può riprendere

Gestione delle pagine

Dopo ogni scansione la pagina scansionata appare come piccola preview in un'area che contiene tutte le pagine scansionate. Queste pagine devono poter essere cancellate, riordinate e rinominate singolarmente. Ogni pagina deve poter essere aperta individualmente con una preview più grande per essere ispezionata.

Attenzione

In genere ogni file scansionato rappresenta una pagina di un documento. L'operatore però può trascinare i file anche manualmente, ma in questo caso potrebbe trascinare un file composto da più pagine, che va gestito in modo diverso da come gestiamo un file scansionato di una singola pagina. Si potrebbe ad esempio dividere (lato server) il file composto da più pagine in più file di una singola pagina.

Creazione del documento

Vicino all'area con la preview delle pagine ci devono essere tre campi compilabili dall'operatore:

Nome del documento: è un nome generico che è slegato dal nome delle singole pagine. Si può decidere se far si che sia univoco o no (il documento viene comunque identificato dall'id)

Realm: selezionabile da una select list che mostra tutti i realm su cui l'operatore ha ruolo di scan (decidere se mettere il campo qui o prima della fase di scan)

Class del documento: rappresenta la tipologia del documento tra quelle previste all'interno del realm. È importante che siano selezionabili solo le class su cui l'operatore ha ruolo di scan. (questi controlli vanno implementati sia lato client che lato server)

Dato che ogni documento avrà un owner e delle ACL, va deciso in quale fase queste informazioni vanno inserite.

L'owner ad esempio potrebbe essere un campo riempibile nella fase di scan, ma facoltativo, mentre le ACL potrebbero essere decise nella fase di publish.

Visualizzazione

Ogni documento deve poter essere visibile dal proprio owner, dagli utenti appartenenti alle ACL collegate al documento, e dagli utenti appartenenti ai groups con READ role sul realm e sulla class a cui appartiene il documento

Quando un utente va nella schermata di visualizzazione, vedrà i documenti inseriti di recente nel sistema e potrà effettuare ricerche per trovare i documenti.

I documenti devono avere una thumbnail, un nome, un'indicazione del size