Riorganizzazione dei campi "indirizzo" dei produttori

[coder-molok]

Riprendo una proposta della #191 che è stata tralasciata nel "mischione" che si è creato in quella issue.

In virtù di tutte le potenziali elaborazioni che serviranno in futuro e ragionando anche sulle possibilità di cercare un prodotto per regione/zona (suggerito da @SimoSca ) riteniamo opportuno dividere il campo "address" nelle sue parti canoniche: (mi rifaccio a quelle italiane per ovvie ragioni) nazione provincia comune ind_tipo <-- via viale piazza vicolo indirizzo civico <-- attenzione, alcuni civici hanno delle lettere (es: 3b) usare alfanumerico localita <-- campo libero : nome della cascina o frazione o contrada o altra indicazione specifica CAP

La cosa migliore sarebbe gestire tutto con codici e tabelle di dominio, a parte indirizzo, civico e località. Sto cercando in internet un elenco aggiornato e gratuito da cui pescarli, ma poi li travaserei in locale (se non avete proposte migliori, ovvio)

[SimoSca]

É proprio come l'avevo pensato. Ma per capire meglio:

1. Ciascuno di questi campi deve essere avere una corrispondente voce nella tabella utenti? Oppure ad esempio si potrebbe optare per salvare tutto in una stringa con un formato specifico: nazione, regione, provincia, città, località. Penso che sia più corretta l'idea di creare nuovi campi, mentre la seconda sarebbe più comoda da gestire.
2. Tutti questi dati li inserisce solo il produttore o vogliamo lasciarli come opzionali per gli utenti standard?

Edit: Probabilmente sul sito dell'ISTAT si può trovare l'elenco completo, ma quasi sicuramente sara un foglio excel.

[coder-molok]

1. Non ritengo che un unico campo nella tabella utenti risulti più comoda da gestire, quindi opterei per modificare il DB. Se pensavi diversamente possiamo chattare su Telegram per chiarirci.
2. Per ora lasciamo i campi per il produttore.
3. Per i dati istat va bene anche dall'excel. Posso convertirlo io, poi ci guardo.

[SimoSca]

2 e 3 ok. Per il punto 1 la penso come te, ma devo come mia abitudine espandere la domanda, chiedendo opinione anche a @Panciz :

l'indirizzo attualmente è una peculiarità dell'azienda, che per noi è in corrispondenza di uno specifico utente. Pensando però che un domani per qualche motivo volessimo distinguere tra l'indirizzo associato ad un utente e l'indirizzo associato alle aziende, mi viene in mente che forse potrebbe essere piu' versatile creare un'apposita tabella "address" e salvando il relativo id nella tabella utente, per riuscire a relazionarli. In questo modo se un domani si decidesse di creare un'apposita tabella "Company", legare l'indirizzo sarebbe semplice. Naturalmente posso anche e solo aggiuntare i campi nella gia' presente tabella utenti.

A livello di lavoro non dovrebbe cambiarmi molto tra un metodo e l'altro: tanto i db e le api le devo modificare ugualmente.

[SimoSca]

@coder-molok :

ho gia' provveduto io a prendere l'elenco dall'istat (aggiornato a gennaio 2016!) e trasformarlo via PHP. In particolare lo esportero' come json, in modo che possa divenire direttamente un modulo AMD compatibile richiamabile anche da javascript, in caso un domani possa servire.

[DDDamage]

Definite questa issue.. perchè credo debba essere fissata prima che faccia registrare i produttori (oppure sistemiamo a mano il db?)

[SimoSca]

Si potrebbe fare a mano, ma evitarlo sarebbe preferibile. Sto aspettando i pareri.

[SimoSca]

Risolta.

Invito a fare alcuni test e chiudere una volta sincerati del buon funzionamento.

Edit:

Per completezza ricordo che ora abbiamo tre tipi di utenti: "standard", "approving" e "offerente". Per il momento l'utente standard inserisce solo i suoi dati base, mentre l'utente "approving" e' un utente che si e' iscritto e proposto come offerente, ma che nessun amministratore ha ancora reso offerente. Attualmente l'unico campo che blocco di un utente "approving" o "offerente" e' la partita iva. Mi dovreste dire voi che altri campi bloccare.

In ogni caso rammento che gli amministratori possono accedere alle pagine senza mai avere blocchi, pertanto un amministratore potra' sempre modificare qualunque campo dell'utente.

[DDDamage]

Perchè bloccare i campi?

[SimoSca]

Perché magari prima che un produttore modifichi dati come Partita Iva o nome dell'azienda volete che passi da un vostro accertamento. Il blocco della P. IVA era stato richiesto esplicitamente.

Anche in questo caso si parla di piccolezze che dovete accordare.

[DDDamage]

Mi ricordavo, solo non è corretto bloccare il campo per gli utenti "approving", ma solo per gli offerenti approvati. Altrimenti se in fase di approvazione chiediamo delle correzioni, l'utente non può farle.

I campi da bloccare sono:

• Nome titolare
• partita iva
• denominazione società

[SimoSca]

quei tre solamente una volta che l'utente è effettivamente stato approvato, right?

[DDDamage]

Sì

[SimoSca]

Fatto:

• gli amministratori possono sempre modificare tutto
• gli offerenti non possono modificare i tre campi precedentemente elencati

[DDDamage]

Si può snellire in certi campi? In particolare:

• Collassare "tipo", "indirizzo" e "località" in un unico campo con etichetta "indirizzo (via, piazza, località, ecc..)". Rischioso incasellare il tipo - ci sarebbero sicuro eccezioni.
• eliminare campo "nazione", lato frontend. Lascialo in backend se vuoi fillato automaticamente, ma considera che l'idea di servire produttori esteri è remota. Se funziona è meglio pensare a produttori italiani e consumatori all'estero.

[SimoSca]

Accordati con @coder-molok : l'avevamo conconcordato a inizio post, ma pensavo ne aveste parlato assieme.

Fatemi sapere

[coder-molok]

Nazione : per il momento puoi nasconderlo e valorizzarlo come Italia (come di fatto è già ora), per San Marino e Città del Vaticano ci adatteremo in futuro. Per la tipologia topologica, sono incerto, perché alcuni corrieri lo richiedono separato. Se ritenete che non sia determinante rimettiamolo assieme al campo indirizzo.

EDIT: Località puoi metterlo tra "comune" e "indirizzo" ma lo lascerei per tutti quei produttori il cui luogo di produzione si chiama "cascina Xyz" o "vecchio mulino" o ... che non corrisponde mai all'indirizzo.

[DDDamage]

Località ha un significato preciso negli indirizzi. Ieri ho mandato un pacco a questo indirizzo:

Loc. Pallodola c/o Mercato Ortofrutticolo 19038 Sarzana (Sp)

Attualmente non sarebbe possibile inserirlo per le seguenti ragioni:

• tipo non esistente
• numero civico obbligatorio

Non possiamo permetterci di non poter inserire degli indirizzi di produttori. @coder-molok la divisione attuale dei campi è arbitraria e comunque non risponde a nessuna necessità attuale. Come al solito, consiglio di evitare di fare scelte "a priori" per ragioni di sviluppo, che limitano la nostra futura libertà di azione.

Attualmente, questa organizzazione dei campi non ha alcuna utilità se non rendere la registrazione dei produttori più macchinosa.