2012-10-23 12 views
7

Sto costruendo un'app che presuppone l'esistenza di determinati gruppi e autorizzazioni per il proprio flusso di lavoro. Ad esempio, un "membro" può accedere all'app e visualizzare e modificare i propri dati personali, ma non può visualizzare le note che normalmente vengono visualizzate sullo stesso schermo. Un "dipendente" può vedere quelle note e creare o modificare le proprie, ma solo un "membro manager" può cancellare o modificare le note di chiunque.i gruppi e le autorizzazioni di Django devono essere hardcoded o bootstrap?

Il mio problema è con il bootstrap dei dati per questa app. Posso creare dati di fixture JSON per i gruppi, ma poi devo codificare i PK in modo rigido, il che sembra una cattiva pratica (e se un'app di terze parti volessi usare la stessa cosa e ci fosse un conflitto?) Un grande problema è il permesso - dovrei aggiungere PK alle autorizzazioni che a loro volta avrebbero PKs ai loro tipi di contenuto.

Ho letto sull'utilizzo del hook post_syncdb per aggiungere i dati iniziali in modo più programmatico, che spero possa aiutarmi a risolvere il problema del PK hardcoded. Ma mi chiedo se questa sia la soluzione migliore a questo problema, o se sto "abusando" del concetto di Django Group e dei permessi, qui, e dovrei fare qualcos'altro, come creare nuovi modelli o semplicemente mettere dei flag (come " is_member_manager ") sul mio modello profilo utente, ecc.

risposta

0

Generalmente crea un'applicazione init con un comando di gestione initialize, ho inserito tutto il codice per avviare l'applicazione. Questo ti permette di:

  • se si utilizza uno strumento di distribuzione (io uso [Ansible] (http://www.ansible.com/home, pipistrello può essere amy tessuto strumento, bash ...) è possibile automatizzare il processo e rimuovere l'applicazione init da teh le applicazioni installate dopo il provisioning (prima installazione)

o

  • di controllo se il comando è stato già lanciato per saltare il processo (Group.objects.all().exists()?)

(o entrambi)

Ho trovato questa soluzione molto facile da mantenere e abbastanza potente per qualsiasi circostanza.

post_syncdb (post_migrate in Djang 1.7) non è una soluzione, come viene chiamata per ogni migrazione

Se avete solo bisogno di caricare i dati e/o creare record (vale a dire gruppi/amministratori ...) la migliore soluzione IMHO è utilizzato Migrazioni dati] (https://docs.djangoproject.com/en/1.7/topics/migrations/#data-migrations)