Modifica Modello Delivery e Withdrawal

[dom_thual]

Si tratta di aggiungere una foreign key su Person per sapere chi è il referente ordine e consegna.

Cioè vuole dire non implementare la gestione ruoli dentro l'ordine.

[dom_thual]

In sostanza si tratta di non gestire ruoli parametrici dentro i modelli legati ai ordini:
GAS_REFERRER_ORDER, 'Referente di ordine'
GAS_REFERRER_WITHDRAWAL, 'GAS withdrawal referrer'
GAS_REFERRER_DELIVERY, 'GAS delivery referrer'

In pratica la gestione dei ruoli parametrici si applica solo alla parte anagrafica che permette di elaborare gli ordini:

OpenOrder - L'utente sceglie i referenti (ordine, delivery e Withdrawal) dentro un set di persone abilitate:

• lista dei referenti produttori
• Al salvataggio si memorizza il gasmember nel ordine per le 3 referenze senza creare ruoli parametrici.

EditOrder - Durante il ciclo di vita dell'ordine si recupera il modello registrato

• In visualizzazione si recupera il modello gasmember
• In controllo delle abilitazione si recuperano gli utenti dal modello GASSupplierOrder.referente.person.user e non più dall'estrazione del ruoli parametrico sull'ordine.

+ i ruoli parametrici delle anagrafiche

Si evita la generazione-proliferazione di ruoli parametrici nella parte produttiva tipo:
domthu is GAS delivery referrer for 2011-11-24 19:15:00 at Indi: produttore 1 principale, Castelbellino(AN)

Nel Archivio

• Visto che non abbiamo archivio, non c'è bisogno di gestire ruoli parametrici (eliminazione, pulitura)

In pratica, questa semplificazione segue la gestione ruoli per l'economico.
I caso del ruolo anagrafico GAS_REFERRER_CASH:
Ciascun GASMember(user) che ha questo ruolo può gestire la parte economica di tutti gli ordini senza dover passare per un GAS_REFERRER_ORDER_CASH

Questo permetterebbe di uniformare la gestione dei ruoli nel sistema.

Come beneficio toglie la specializzazione tra le classe Delivery e Withdrawal dal soggetto (gestione ruolo). Questa associazione ritorna a fare parte del GASSupplierOrder.
Di conseguenza Il referente ordine, delivery e withdrawal sarebbero field del GASSupplierOrder che implementa anche un Delivery e un Withdrawal (luogo per data).

Ditemi come vedete questa proposta?

[fero]

Questa è una scelta che va presa alle 1:40am.

OK! Mi hai convinto Dominique. Purtroppo devo è necessario che faccia ora questa scelta.

Ho verificato e considerato che:

• concordo che sia importante disaccoppiare il ruolo di referente di consgna dalla consegna. quantomeno per poter specificare un referente anche se la data di consegna non si sa;
• questa scelta non rompe l'API di django-flexi-auth: possiamo comunque usufruire dei campi can_*;
• evita la proliferazione di ruoli;
• semplifica e riduce di conseguenza i "punti di rottura" e pure le operazioni di scrittura, infati creo una sola istanza nel DB invece di 3: ordine, ruolo parametrico e principalparamrole;

Sono indeciso a cosa far puntare la ForeingKey: a Person o a User o a GASMember (come forse tra le righe proponevi tu)?

In un primo momento pensavo fosse più corretto assegnarlo a User dato che si tratta di un'associazione di ruolo, ma poi magari più efficiente collegarlo ad un GASMember che poi non si sa mai in caso di persona che appartiene a più GAS...

Alla fine per prendere questa decisione non critica è andato via troppo tempo, ma ho pensato che sarebbe preferibile collegarlo a Person e la scelta avviene fra le Person dei GASMember. Se un domani dovessimo eliminare la persona dal GAS (eliminare il GASMember) o addirittura eliminare l'utente dal sistema, potremmo avere ancora la tracciabilità di chi era referente per quello specifico ordine/consegna/ritiro.

Dunque farò così:

• aggiungo il campo delivery_referrer_person
• e la property delivery_referrer che restituisce delivery_referrer_person.user

anche per order e withdrawal

Lo lascio aperto per ulteriori commenti, positivi o critici che siano!