At line 1 added 64 lines |
%%(display:none) |
{{{ |
WikiUp |
}}} |
/% |
[{TableOfContents }]\\ |
!!! Descrizione\\ |
Solo alcuni utenti devono poter modificare i sorgenti in librerie di sviluppo.\\ |
Vanno quindi impostate le autorizzazioni in modo tale da garantire questa proprietà.\\ |
\\ |
Tale proprietà deve valere anche per gli utenti QPGMR.\\ |
\\ |
La modifica deve essere impedita indipendentemente dallo strumento utilizzato: nero verde, RDi, Looc.UP, Web.UP, FTP, ecc.\\ |
\\ |
!!! Dettagli\\ |
!! Comando B£QQ30\\ |
E' stato creato il comando B£QQ30, tramite il quale è possibile impostare la corretta autorizzazione su una libreria.\\ |
\\ |
Tramite questo comando è possibile impostare:\\ |
* il tipo di autorizzazione\\ |
* l'eventuale AUTL (solo per tipo SVI)\\ |
* l'eventuale OWNER (solo per tipo SVI)\\ |
\\ |
I tipi di autorizzazione sono i seguenti:\\ |
* DEV: come la SMEDEV distribuita - il QPGMR deve modificare e debuggare\\ |
* SRC: come la SMESRC distribuita - il QPGMR non deve modificare né debuggare\\ |
* OBJ: come la SMEUP_OBJ distribuita - il QPGMR non deve modificare ma deve debuggare\\ |
* SVI: librerie di sviluppo - solo alcuni utenti possono modificare, il QPGMR può debuggare\\ |
\\ |
!! Note su AUTL e OWNER\\ |
Con tipo SVI gli utenti autorizzati a modificare saranno SOLO quelli inclusi in una AUTL (opzionale). Nemmeno il QPGMR potrà\\ |
modificare il contenuto della libreria.\\ |
Quindi per SVI:\\ |
* verrà applicata AUTL se presente (solo a libreria, PF-SRC, MSGF e USRSPC)\\ |
* verrà modificato il proprietario (solo a libreria, PF-SRC, MSGF e USRSPC) rimuovendo le autorizzazioni specifiche di quell'utente. Questo perché mantenendo proprietario QPGMR, ogni utente QPGMR potrebbe modificare le autorizzazioni concedendosele...\\ |
\\ |
Mentre per NON SVI:\\ |
verranno rimosse eventuali AUTL da tutti gli oggetti\\ |
verrà applicato proprietario QPGMR su libreria, PF-SRC, MSGF e USRSPC\\ |
\\ |
!! Considerazioni tecniche\\ |
Perché agiamo su libreria, PF-SRC, MSGF e USRSPC e non su tutti gli oggetti?\\ |
Dovremmo agire su tutti (per impedire ad esempio la cancellazione di qualunque oggetto). Ma se lo facciamo su *PGM (e *CMD) innanzitutto non debugghiamo più. Inoltre proprietario QPGMR ci serve per il corretto funzionamento dei programmi. PF-DTA... Da valutare queste problematiche.\\ |
\\ |
La sola opzione OBJ è debole perché se QPGMR è OWNER, può concedersi le autorizzazioni alla modifica. Inoltre può creare file. Quindi, per non introdurre modifiche sulla SMEUP_OBJ, introduciamo questa opzione (SVI).\\ |
\\ |
Non cambiamo l'OWNER degli oggetti che non siano libreria, PF-SRC, MSGF e USRSPC perché temiamo di avere risultati impredicibili.\\ |
\\ |
Le autorizzazioni PUBLIC sono sempre e solo *USE\\ |
Le autorizzazioni QPGMR dipendono dalla tipologia di libreria:\\ |
\\ |
per modificare serve *ALL sui file source\\ |
per debuggare serve almeno *CHANGE sui *PGM\\ |
per non modificare deve essere *USE sui file source (con *CHANGE non riesco da nero verde ma ci riesco da loocup)\\ |
\\ |
Più precisamente, abbiamo raffinato le autorizzazioni nel seguente modo: Sulla libreria:\\ |
il gruppo QGPMR ha *OBJOPR *READ *EXECUTE.\\ |
\\ |
Sugli oggetti protetti:\\ |
il gruppo QPGMR ha *OBJOPR *READ *EXECUTE. sugli oggetti sbloccati:\\ |
il gruppo QPGMR ha *OBJOPR *OBJMGT *OBJEXIST *READ *ADD *UPD *DLT *EXECUTE.\\ |
\\ |
In conseguenza, gli utenti di gruppo QPGMR possono modificare i files sprotetti, leggere e copiare altrove i sorgenti protetti, NON possono compilare nella libreria di tipo SVI\\ |
\\ |