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