Warning: session_write_close(): write failed: No space left on device (28) in /var/www/dw_docs/doku.php on line 119

Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions) in /var/www/dw_docs/doku.php on line 119
test [Il nostro punto della strada]

User Tools

Site Tools


test

Table of Contents

   ___          _     _            ___    _ _          
  / _ \__ _ ___(_)___| |_ __ _    / __\__| (_) ___ ___ 
 / /_\/ _` / __| / __| __/ _` |  / _\/ _ \ | |/ __/ _ \
/ /_\\ (_| \__ \ \__ \ || (_| | / / |  __/ | | (_|  __/
\____/\__,_|___/_|___/\__\__,_| \/   \___|_|_|\___\___|
 

Versione di Test 0.9.9.9 http://desmacerata.it:8000/gasistafelice/accounts/login/?next=/ su server MC

Bug di regressione ed errori rilevati

Nota: questa pagina wiki è l'ennesimo tentativo di soluzione del problema del tracciamento dei bug. Si era proposto JAGOM, poi GITHUB, ora GITHUB+questa pagina. Ottima l'iniziativa di Orlando, ma la inserirei in un flusso di lavoro. Ho già un'idea ma non allungo.

A: Problemi nel box di ricarica conto gasista Impossibile effettuare ricariche

FIXATO LF: il problema `sys.stdout access restricted by mod_wsgi` è dovuto alla presenza di “print” nel codice. Soluzioni possibili: eliminare la print o trasformarla in log.debug o log.warning o log.error, … In questo caso log.debug

Mostra dettagli (in fondo)

B: Problemi con la propagazione della disponibilità dei prodotti e variazione prezzi di un listino per un gas su gli ordini aperti e su quelli preparati

Ci sono disfunzioni che impediscono la realizzazione di queste operazioni ed al momento vengono propagati negli ordini aperti solo l' eventuale aggiunta di nuovi prodotti del fornitore dal livello Des e però non vengono effettuati cambiamenti, nel senso di propagazione a gli ordini aperti e preparati, di prezzo fatti dallo stesso livello (Des), nè cambiamenti di disponibilità fatti dal livello listino gas, nel caso che i prodotti in questione siano già stati ordinati riguardante quindi in questo ultimo caso solo gli ordini aperti.

Nel caso cioè che un ordine sia aperto e che la modifica riguardi la variazione di prezzo di un prodotto ordinato, questo sarà notificato nel pdf riepilogativo ma non sarà calcolato nei sub-totali nè sul totale dell 'ordine e nemmeno dopo la chiusura dell 'ordine stesso in fase di Decurtazione-Registrazione.

Immaginando che non sarà facile in tempi rapidi risolvere e ritestare queste disfunzioni propongo che almeno in questa fase non sia consentita la preparazione di ordini preparati nella versione ufficiale, per non appesantire inutilmente il software e concentrarsi solo sulla propagazione di dette modifiche almeno su gli ordini aperti tenendo però conto anche dell 'osservazione che segue.

Fare in modo che l' immissione di nuovi prodotti in un listino fornitore non si propaghi di default su tutti gli ordini aperti o preparati se fatti da un admin se invece è fatto da un ref. informatico che si propaghi solo al suo gas di riferimento.

Questo per evitare alcuni effetti indesiderati illustrati in uno scambio di mail precedenti con Dominique che ripropongo in sintesi qui di seguito:

Una modifica al listino va propagata (cascading) a tutti gas con la seguente regola: se la modifica e stata fatta da Referente informatico, la modifica va propagata a tutti i GAS però risulta: * abilitata solo per il(i) GAS al quale appartiene il referente che porta la modifica. * crea però rende non disponibile per gli altri GAS

aggiungendo appunto che nel caso sia fatta da qualcuno con privilegi di admin non si propaghi a tutti di default.

C

Alcune disfunzioni con i privilegi di referente fornitore

Premetto che un referente fornitore non dovrebbe essere una figura unica all' interno di un gas ma che sarebbe auspicabile che ve ne fossero almeno due per ogni fornitore in modo da far fronte ad eventuali assenze o indisposizioni o permettere una loro cogestione dell' ordine ed a questo riguardo in particolare la disfunzione che si nota è che se un referente apre l' ordine l'altro pur abilitato allo stesso patto del gas non riesce ad effettuare le operazioni di Registrazione e Decurtazione.

Inoltre più in generale si ravvisano le seguenti anomalie con i privilegi di referenti fornitore che andrebbero anche queste corrette e che sono purtroppo presenti anche nella versione ufficiale:

c1

Un referente abilitato per un patto riesce ad aprire nuovi ordini anche di altri patti,questo risulta particolarmente frustrante per il "vero referente" che poi non riesce ad avere la possibilità di chiudere un ordine aperto da altri

Ciò può di fatto verificarsi involontariamente quando un gasista con i privilegi di referente apre l' ordine invece che dal proprio patto a cui è abilitato dalla finestra più generale della scheda ordini del gas, per es.: (http://desmacerata.it:8000/gasistafelice/rest/#rest/gas/8/9)

Cliccando su aggiungi ordine infatti si apre la scheda che dà la possibilità, che si dovrebbe evitare, di aprire qualsiasi ordine da parte di qualsiasi referente (Please select the pact you want to make an order for)

che dà appunto la possibilità di autocrearsi referente di qualsiasi ordine o selezionare un altro referente ed aprirlo per lui, cosa che tra l' altro gli impedirà successivamente di annullarlo nel caso lo abbia fatto per errore (improbabile visto che di default compare come referente il nome di chi agisce ma sempre possibile)

*

c2

Qualsiasi referente riesce a sopprimere i prodotti di un ordine anche di cui non è referente andando nel box report dell' ordine tasto "modifica" e "Togli prodotti dall' ordine"

Anche questo purtroppo ho potuto constatare essere accaduto con chi in buona fede così facendo pensava di intervenire solo nel proprio paniere.

La realtà sembra sempre superare qualsiasi possibilità di immaginazione.

Questo purtroppo ha degli effetti collaterali devastanti perchè ripristinare un prodotto eliminato da un ordine è un impresa impossibile e risulta complicato persino repristinarne la sua disponibilità, visto che come è già stato segnalato e come ricorderò anche nella parte “suggerimenti e proposte di modifica” questa operazione ha difficolta a propagarsi negli ordini già aperti.

Naturalmente questa possibilità risulta molto utile se usata correttamente e andrebbe solo corretto il fatto di non renderla disponibile a tutti i referenti in generale ma solo a quelli responsabili del patto in questiome per cercare di eliminare in parte le possibilità di errore che per altro debbono essere affrontate in sede di formazione dei referenti stessi

Suggerimenti, proposte di modifica e priorità

Realizzazione nuovo server

Per far fronte alla necessita che lo smantellamento della provincia di Macerata impone ed all 'ingresso di nuovi gas che volessero testare il software.

Di fatto il server con una istallazione di gasista felice è stato già installato a questo indirizzo:

Con questo fine proporre ai gas aderenti al progetto un contributo di 10 € a famiglia a partire dal nuovo anno, da estendere successivamente ai produttori interessati nella modalità che avevamo immaginato dell' 1% sul venduto o in altre forme anche per la loro formazione nell' utilizzo del software e per eventuali modifiche da loro proposte.

Implementazione ordini intergas

Una questione davvero fondamentale per facilitare la creazione effettiva del Des dando la possibilità reale di ottenere vantaggi economici nel risparmio sui costi di trasporto nelle ordinazioni soprattutto di eventuali prodotti fuori regione come arance, parmigiano ecc…

E soprattutto stimolando un senso di appartenenza ad un Des

Implementare la possibilità di stampare un listino-fornitore per il singolo gas

In modo da rendere più agevole il controllo dei prodotti immessi e resi disponibili ed i loro relativi prezzi

Implementare l' invio automatico delle mail al produttore ed ai gasisti che hanno effettuato l'ordine

In modo da prevenire dimenticanze e facilitare il Referente fornitore nel suo compito

Dare al produttore la possibilità di cambiare la sua password poichè non è al momento possibile come per il gasista

Da una mail di Dominique

Implementare la possibilità di effettuare consegne in luoghi diversi

Importante per quei gas molto estesi sul territorio che non hanno tuttavia un numero di soci tale da giustificare la gemmazione di nuovi gas

Analisi Ipotetica di realizzazione

  1. Tra le possibili opzioni di configurazione dell ordine del gas dare la possibilità di selezionare questa opzione
    • Immissione dei Luoghi di consegna
  2. Rendere indisponibile questa opzione in caso di ordine intergas
  3. Quando il gasista seleziona l' ordine per ordinare ed appare il listino, appena sotto deve poter selezionare il luogo di consegna preferito tra quelli disponibili.
    • Nel caso chiuda l' ordine senza selezionare il luogo, un messaggio di errore lo deve avvisare
  4. Nel Pdf riepilogativo dell' ordine i gasisti che hanno ordinato vengono raggruppati per luogo e poi in ordine alfabetico.
    • In seguito si potrebbe dividere anche la parte riepilogativa finale del pdf in modo che fornisca i sub totali delle merci e dei valori per i luoghi di consegna in modo da facilitarne il controllo del referente

Soluzione dei problemi con la creazione dei file Pdf dal Report dell 'ordine

Problema risolto : Ticket229

Purtroppo continuano a verificarsi errori soprattutto quando il numero dei prodotti o dei gasisti che ordinano aumentano e che in genere hanno questa forma nella segnalazione: TypeError at /gasistafelice/rest/order/943/order_report/createpdf unsupported operand type(s) for +: 'NoneType' and 'int' Request Method: GET Request URL: http://ordini.desmacerata.it/gasistafelice/rest/order/943/order_report/createpdf Django Version: 1.3 Exception Type: TypeError Exception Value: unsupported operand type(s) for +: 'NoneType' and 'int' Exception Location: /var/lib/virtualenvs/desmacerata/lib/python2.6/site-packages/reportlab/platypus/tables.py in spanFixDim, line 205 Python Executable: /var/lib/virtualenvs/desmacerata/bin/python Python Version: 2.6.5

A parte alcune imperfezioni che sicuramente saranno anche dovute all' applicazione di conversione ed al fatto che il problema si risolve creando direttamente il file html: http://dialogo.desmacerata.it/domanda/9/creazione-dellordine-pdf-non-funziona-come-fare

Si nota tuttavia anche nel file html stesso una non corrispondenza tra il numero dei prodotti e le rows (numeratore sulla singola rows) che generano l' accorpamento delle righe nella colonna finale, quella con il nome del gasista il suo sub totale ed il numero dei prodotti acquistati. Queste infatti non sempre o meglio mai per un numero superiore a 3, corrisponde con il numero dei prodotti. Ad esempio se in un ordine è presente un gasista che ha ordinato 6 prodotti nel file html generatore la rows corrrispondente ha valore 5 e così più in generale in tutti questi casi (più di 3 prodotti) avremo il numeratore rows uguale a (n-1) dove n rappresenta il numero dei prodotti ordinati.

Ci si accoge di questo aprendo il file html con un editor html (NVU) dove questo viene evidenziato, mi domando se non si potrebbe tentare di risolvere intervenendo sul “codice” che crea l' Html generatore, ponendo il valore del numeratore rows sempre uguale al numero dei prodotti ordinati.

Ripristino della data di consegna ordine nella visualizzazione delle transazioni individuali (decurtazioni)

Per facilitare la lettura ed il controllo da parte del singolo gasista dei movimenti (transazioni) nel suo conto sarebbe utile ripristinare questa visualizzazione che era presente nelle prime release del software (fig 3). Questo perchè a volte succede che le transazioni (decurtazioni) che il referente fà su gli ordini non sempre avvengono in tempi rapidi e visto che non è possibile dal box decurtazioni inserire una data ma viene impostata di default quella in cui la decurtazione stessa avviene ciò genera confusione per il gasista che poi vorrebbe controllare il proprio conto.

Si potrebbe anche ipotizzare di rendere modificabile la data delle transazioni- decurtazioni così come avviene per altre operazioni e che in questo caso è possibile fare solo lato admin alla voce transaction

Fig 3 (in rosso la situazione attuale in blu quella delle versioni precedenti, naturalmente invece il nome del gasista può essere lasciato ommesso perchè ridondante)

In quest' ottica di facilitazione del controllo del proprio conto sarebbe anche utile dare la possibilità a tutti di visualizzare il file Pdf dell 'ordine che ora è prerogativa dei soli referenti

Dettagli

A: Problemi nel box di ricarica conto gasista Impossibile effettuare ricariche

1)il box non visualizza nulla

2)cliccando sul display per variare il numero di elementi si visualizza il seguente errore:

IOError at /gasistafelice/rest/gas/8/recharge/edit_multiple

sys.stdout access restricted by mod_wsgi

Request Method: GET Request URL: http://desmacerata.it:8000/gasistafelice/rest/gas/8/recharge/edit_multiple?render_as=table&sEcho=1&iColumns=5&sColumns=&iDisplayStart=0&iDisplayLength=50&mDataProp_0=0&mDataProp_1=1&mDataProp_2=2&mDataProp_3=3&mDataProp_4=4&sSearch=&bRegex=false&sSearch_0=&bRegex_0=false&bSearchable_0=true&sSearch_1=&bRegex_1=false&bSearchable_1=true&sSearch_2=&bRegex_2=false&bSearchable_2=false&sSearch_3=&bRegex_3=false&bSearchable_3=false&sSearch_4=&bRegex_4=false&bSearchable_4=true&iSortingCols=1&iSortCol_0=2&sSortDir_0=asc&bSortable_0=true&bSortable_1=true&bSortable_2=false&bSortable_3=false&bSortable_4=false&_=1354045797187 Django Version: 1.3 Exception Type: IOError Exception Value:

sys.stdout access restricted by mod_wsgi

Exception Location: /mnt/shares/gasistafelice/gasistafelice/rest/views/blocks/recharge.py in _get_records, line 118 Python Executable: /usr/bin/python Python Version: 2.6.5

test.txt · Last modified: 2014/10/28 12:28 (external edit)