Project

General

Profile

Segnalazione #8

Controlli su utenti e permessi, e cosa può vedere ogni utente

Added by Mark Caglienzi over 10 years ago. Updated over 10 years ago.

Status:
Chiuso
Priority:
Normale
Assignee:
Christopher R. Gabriel
Start date:
08/29/2013
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

Description

  • Tutte le view sono protette dal decoratore @login_required
  • Prima dell'integrazione degli utenti, non c'erano controlli su cosa si potesse vedere (tutti gli utenti vedevano tutto)
Controlli aggiunti, situazione commit ec39a0a4:
  • 'My School': vengono visualizzate solo le scuole amministrate dall'utente attualmente loggato (mediante la m2m School.managed), come si era già detto al telefono ieri. Un superuser le vede tutte, ovviamente.
  • Se un utente non ha scuole, viene visualizzato un messaggio nella pagina.

Aggiunta la lista degli utenti che amministrano la scuola in show_school.html, con link a una nuova view chiamata review_user() che contiene le stesse informazioni del vecchio Octomon (nome, mail, elenco delle scuole amministrate).

History

#1

Updated by Mark Caglienzi over 10 years ago

Altri controlli aggiunti:
  • Filtro sul widget select con l'elenco delle scuole durante la creazione di un nuovo computer, in modo che siano visualizzate soltanto le scuole che l'utente amministra (ovviamente un superuser le vede tutte).
  • Template schools.html: il bottone 'Create school' compare solo se l'utente ha il permesso add_school.
  • Template schools.html: il bottone 'Add computer' compare solo se l'utente amministra almeno una scuola (non ha senso creare un computer se non puoi associarlo a nessuna scuola, dato che non ne amministri), e se ha il permesso add_host.
  • Template schools.html: il bottone 'Destroy' viene mostrato solo se l'utente ha il permesso delete_school.
  • View create_school(): se l'utente non ha il permesso add_school, stampa un messaggio e redirect verso la lista delle scuole

In questo modo il controllo sul permesso add_school è presente nel template (non viene mostrato il bottone) ma anche nella view (in caso si scriva a mano l'URL /schools/create/).

Ovviamente bisognerà procedere, durante la migrazione degli utenti, all'aggiunta dei relativi permessi.

Ad esempio se ogni utente può anche distruggere le scuole che amministra, il permesso delete_school andrà dato di default a tutti (aggiungendo un ulteriore check a livello di view, in modo che ogni utente possa cancellare solo le proprie scuole), oppure bisognerà rimuovere il controllo del suddetto permesso. Se invece solo un superuser può cancellare le scuole, quel permesso non dovrà essere dato a nessuno.

Bisogna definire per bene chi può fare/vedere/cancellare/modificare cosa, a tutti i livelli.

#2

Updated by Mark Caglienzi over 10 years ago

Situazione al commit c5d8091b:

Oggi ho aggiunto tutti i controlli a livello di modelli che ho trovato in giro.
Tutte le view hanno il check dei permessi, e i template presentano i pulsanti e i link solo se l'utente loggato ha il relativo permesso (o i relativi permessi).

Al di là dei controlli standard, queste sono le cose un po' diverse che ho fatto:
  • La lista delle attività nella pagina di ricerca elenca tutte le attività solo per l'utenza superuser, mentre per tutti gli altri utenti vengono visualizzate le attività relative alle scuole amministrate (la lista delle attività di ogni scuola invece è già automaticamente filtrata sulla scuola stessa)
  • Le liste di ticket visualizzano solo i ticket relativi a computer o other_hardware delle scuole amministrate (oppure tutti i ticket, se l'utente è superuser)
#3

Updated by Christopher R. Gabriel over 10 years ago

  • Status changed from Nuovo to Chiuso
  • Resolution set to fixed

Risulta tutto corretto per il momento. Chiudo attivita', nel caso riapriamo nuovo ticket specifico.

Also available in: Atom PDF