At line 1 added 93 lines |
%%(display:none) |
{{{ |
WikiUp |
}}} |
/% |
[{TableOfContents }]\\ |
\\ |
!! Definizione\\ |
Con autorizzazione si intende la capacità che viene conferita a un utente o a un gruppo di utenti di esercitare una certa attività o di visualizzare un'informazione. Smu.UP garantisce infatti di limitare le azioni di un utente relativamente a un menù, a un anagrafico o di una azione di modifica di un dato.\\ |
Al tema autorizzazioni è stato dedicato un intero modulo, all'interno del quale è possibile trovare gli strumenti che servono a impostare, gestire o semplicemente controllare le autorizzazioni attive per un utente su un particolare oggetto (applicazione, modulo, o anche enti, articoli, etc). Questo modulo, denominato B£AUTO e consultabile solo se lo *USERLEVEL del proprio utente è alemno 01, si trova all'interno dell'area applicativa __Architettura e servizi di base__, nell'applicazione B£.\\ |
\\ |
Per chiarire subito il concetto di *USERLEVEL. riportiamo di seguito una sua breve definizione, poichè una spiegazione più approfondita verrà demanadata a un documento specifico.\\ |
Con *USERLEVEL si intende quella classe di autorizzazione che definisce il livello di utilizzo si MSe.UP da parte dell'utente. A oggi vengono gestiti quattro diversi livelli di utilizzo:\\ |
\\ |
* __00 - Operativo__: destinato agli utilizzatori finali di SMe.UP, a chi cioè utilizza il SW solo dal punto di vista applicativo.\\ |
* __01 - Gestore EDP__: per quegli utenti che, oltre a una visione applicativa, hanno abitualmente a che fare con azioni di gestione del sistema, dal punto di vista del suo funzionamento a livello di impostazioni generali.\\ |
* __02 - Implementatore__: da attribuire agli installatori Sme.UP nelle installazioni dai clienti. Questo livello conferisce il massimo grado di utilizzo di Sme.UP.\\ |
* __03 - Sviluppatore (test)__: con questo livello si attivano funzioni che sono ancora in fase di test. Questo livello è riservato a chi si occupa di sviluppare Sme.UP in laboratorio.\\ |
\\ |
__Rimandiamo al documento B£AUTO_02 per amggiori dettagli sullo *USERLEVEL.__\\ |
\\ |
!! Lo scopo delle autorizzazioni\\ |
A seconda di chi implementa o subisce gli effetti delle autorizzazioni, queste perseguono scopi e finalità ben differenti.\\ |
__Per l'utente finale__:\\ |
* accedere solo alle funzioni che sono di suo interesse\\ |
* visualizzare su un record anagrafico solo i campi di sua competenza\\ |
* inibire l'accesso alle tabelle di parametrizzazione (riservate al presonale IT dedicato alla customizzazione dell'applicazione)\\ |
__Per il programmatore__:\\ |
* rendere indipendente il suo programma dal particolare utente che vi accede\\ |
* implementare nello stesso programma funzioni con livello di autorizzazioni diverse\\ |
* disporre di una funzione generica da introdurre nei suoi programmi\\ |
__Per il responsabile sistema informativo__:\\ |
* confidare sulla congruenza dei dati presenti nel sistema\\ |
\\ |
\\ |
!! Architettura Applicativa\\ |
Le autorizzazini in Sme.UP vengono configurate attraverso tre valori:\\ |
* la __CLASSE__, ovvero un elemento della tabella B£P, che definisce l'ambito applicativo sul quale l'auorizzazione deve avere effetto (applicazione, modulo, oggetto, istanza, componente, etc...).\\ |
* L'__UTENTE__, ovvero la persona sulla quale le autorizzazioni devono avere effetto. Possono essere definite autorizzazioni per utente, gruppo utente o utente generico **.\\ |
* La __FUNZIONE__, e quindi una declinazione specifica del contesto e quindi della classe sopracitata.\\ |
Le modalità con cui le autoizzazioni devono operare all'interno di ciascuna classe sono invece definite azioni (elementi della tabella B£S) e dal valore assunto da queste.\\ |
Le azioni possono essere le normali opzioni di aggiunta, modifica, copia... o azioni più complese e articolate. Ogni azione ha 10 possibili risposte. In tale modo, per ogni classe di autorizzazione, si viene a creare una sorta di tabella di dieci righe (azioni possibili: IMMISSIONE, MODIFICA, VISUALIZZAZIONE,...) e dieci colonne (risposte valide: 01/IM, 02/MO, 05/VI,..).\\ |
\\ |
\\ |
\\ |
!! Rappresentazione astratta\\ |
La funzione delle autorizzazioni può essere immaginata come uno strumento che fornisce una "RISPOSTA" rispetto alla eseguibilità di una "AZIONE" di "QUALCUNO" in un determinato "CONTESTO".\\ |
Sostituendo le parole astratte di sopra potremo avere ad esempio casi di questo genere:\\ |
* "Paolo" può "inserire" un nuovo "cliente"?\\ |
* "Tutti gli utenti" possono "vedere il costo" nelle "interrogazioni di magazzino?\\ |
''Schema Astrazione delle autorizzazioni'':\\ |
[{Image src='immagini/MBDOC-BXAUTO_01/BXAUTO01.png' caption='' width='100%' style='max-width: 100%;'}]\\ |
Quindi la tecnica adottata in Sme_up può benissimo essere ripresa senza alcun problema di conflitti concettuali.\\ |
\\ |
!! Rappresentazione tecnica\\ |
Lo schema seguente vuole descrivere gli elementi tecnici dell'impostazione.\\ |
\\ |
''Schema Tecnico delle autorizzazioni'':\\ |
[{Image src='immagini/MBDOC-BXAUTO_01/BXAUTO02.png' caption='' width='100%' style='max-width: 100%;'}]\\ |
La classe di autorizzazione fissa il significato di utente e funzione permettendo la scelta all'interno di un qualsiasi "Oggetto Applicativo", nonché il sottosettore da cui saranno riprese le azioni possibili.\\ |
Lo schema delle autorizzazioni rappresenta in modo semplice quello che risulta essere il comportamento dell'applicazione "Autorizzazioni" in Sme_up.\\ |
Per generare l'elenco di queste ultime devono essere scelti i parametri seguenti :\\ |
* Utente\\ |
* Funzione\\ |
* Classe\\ |
\\ |
!! Attribuzione Autorizzazioni\\ |
__Risalita__\\ |
All'interno di una classe possono essere attribuite Autorizzazioni per il generico utente "U**", per la generica funzione "F**" ed il generico Gruppo "G**".\\ |
Analogamente è possibile attribuire autorizzazioni anche per l'utente specifico su qualsiasi funzione e gruppo.\\ |
Riassumiamo schematicamente le suddette Autorizzazioni a partire da un livello più basso (utente/funzione) a quello più alto (classe):\\ |
%%quote |
- Utente specifico / F** |
- G** / Utente specifico |
- U** / Funzione specifica |
- G** / Funzione specifica |
- Gruppo specifico/ U** |
- Gruppo specifico / F** |
/% |
---- |
\\ |
''Schema risalita autorizzazioni'':\\ |
[{Image src='immagini/MBDOC-BXAUTO_01/BXAUTO03.png' caption='' width='100%' style='max-width: 100%;'}]\\ |
Immaginiamo ora che all'interno di un certo applicativo un utente voglia accedere ad una particolare funzione.\\ |
La richiesta d'accesso causerà la chiamata al programma B£AUA0G di gestione delle Autorizzazioni che andrà, come prima cosa, a verificare l'esistenza delle stesse relative alla funzione chiamata per l'utente chiamante.\\ |
Nel caso non siano state definite tali Autorizzazioni, il programma risalirà fino a quelle definite per l'utente generico e per la particolare funzione.\\ |
Se questo non andrà a buon fine, continuerà per quelle relative all'utente per una generica funzione all'interno della classe.\\ |
Nel caso in cui nemmeno queste siano state definite verranno prese quelle definite per default cioè U** / F** (Schema di Risalita).\\ |
\\ |
''Esempio - Astrazione delle autorizzazioni Sme.up'':\\ |
[{Image src='immagini/MBDOC-BXAUTO_01/BXAUTO04.png' caption='' width='100%' style='max-width: 100%;'}]\\ |
Lo schema precedente vuole essere di aiuto per comprendere il grado di astrazione delle autorizzazioni in SME_UP. Si noti che la logica rimane valida qualunque sia l'ambito preso in considerazione. Nel nostro caso avremo che "QUALCUNO" diventa "Veicolo", il "CONTESTO" diventa "l'ambiente" e le "AZIONI" sono le "attività eseguibili". Mediante le autorizzazioni potrò descrivere il fatto che un ciclomotore non può viaggiare in autostrada e che il limite di una automobile su strada urbana è di 50 Km orari.\\ |
\\ |