%%(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\\
\\