jorvik
jorvik copied to clipboard
Fix 620, [WiP] [donazioni] Donazioni
Fix #620 PR per il modulo donazioni.
@domeniconappo in linea generale va bene, e il sistema di deleghe e permessi mi sembra implementato correttamente -- ben fatto, considerando lo stato della documentazione in merito. Ho lasciato un paio di commenti sul codice.
@AlfioEmanueleFresta bisognerà aggiungere il nuovo repository in wonderbot.
@PaoloGiustiniani ho terminato poco fa di parlare in Skype con @domeniconappo -- siamo rimasti che avremmo configurato il tutto non appena il codice conterra' delle pagine nuove (viste), che saranno testabili (al momento non c'e' niente di nuovo lato utente).
@AlfioEmanueleFresta grazie a te per il supporto e per le dettagliate informazioni!
È possibile associare a questa PR una issue che spieghi in dettaglio cosa si sta andando ad introdurre di nuovo così che la cosa rimanga tracciata e si possano poi effettuare dei test in maniera coerente con quanto previsto in implementazione?
@AlfioEmanueleFresta @PaoloGiustiniani Sono state aggiunte alcune funzionalità lato utente. Fatemi sapere quando il repository sarà su un'istanza di stage così scriverò la lista di requisiti da testare con questo "rilascio" per il personale QA.
@domeniconappo va bene
Visto il codice, ho aggiunto il repository Staersistemi/jorvik alla lista dei repository fidati, e ho avviato la generazione dell'ambiente di staging. Sara' a breve disponibile su http://pr-599.sviluppo-gaia.ovh/
@AlfioEmanueleFresta Grazie per la review
@AlfioEmanueleFresta @luca-dex @PaoloGiustiniani
Requisiti da testare per QA:
Requisiti A
- Il prodotto permetterà l’accesso al pannello di gestione di tutte le Campagne di un Comitato CRI al Presidente ed ai Delegati Campagne e Donazioni dello stesso Comitato (“Delegati”).
- Il prodotto permetterà, ai Delegati, la creazione di nuove campagne.
- Il prodotto permetterà, ai Delegati, di visualizzare un elenco di tutte le campagne lanciate nel Comitato.
- Sarà necessario specificare nome, data di inizio e fine, descrizione e sede organizzatrice fra quelle dipendenti dal comitato per ogni Campagna.
- Sarà necessario specificare uno o più responsabili per la gestione della Campagna.
- Sarà possibile specificare una o più etichette per ogni Campagna.
- Sarà possibile eliminare le campagne con zero donazioni economiche.
- I responsabili di ciascuna campagna potranno effettuare tutte le operazioni dei normali delegati sulla campagna, eccetto la cancellazione della campagna stessa e la creazione di nuove campagne.
- Il prodotto permetterà l’accesso al pannello di gestione tramite il pannello admin di tutte le Campagne alle utenze autorizzate del Comitato Nazionale.
- Il prodotto permetterà, agli utenti autorizzati, la creazione di nuove campagne.
- Il prodotto permetterà, agli utenti autorizzati, di visualizzare un elenco di tutte le campagne lanciate nel Comitato Nazionale.
- Le entità autorizzate alla creazione di campagne saranno:
- Comitato nazionale
- Comitato territoriale
- Comitato regionale, solo quando abbiano impostato CF e PIVA e questi sono diversi dal Comitato nazionale
Requisiti B
- Sarà necessario specificare uno slug per ogni Etichetta.
- Le etichette saranno specifiche per ciascun Comitato
- Per ogni campagna sarà generata e applicata automaticamente una etichetta dallo stesso nome della Campagna
- Il comitato nazionale può creare delle etichette globali visibili a tutti i comitati territoriali
Nota: insieme ai requisiti C, da implementare nella prossima release (questo fine settimana) ci sarà un requisito del gruppo B:
- Sarà possibile effettuare ricerche sulle Campagne di ciascun comitato selezionando uno o più etichette fra quelle disponibili
A disposizione per ulteriori informazioni
Apro una issue a cui associare questa PR
@domeniconappo per favore facci sapere quando sarà possibile iniziare a testare il tutto, grazie.
@luca-dex E' possibile già testare i requisiti su http://pr-599.sviluppo-gaia.ovh/ (se gi aggiornato con il branch)
Per il test, bisogna usare (almeno) due sedi TERRITORIALI con due presidenti diversi. I presidenti devono aggiungere uno o più delegati campagne per la sede.
Alcuni casi di test:
Il presidente di un comitato dovrebbe vedere il link 'Campagne' fra i tab nella sua schermata /utente/
Il delegato campagne dovrebbe vedere il link 'Campagne' come il presidente

Cliccando sul link, si va alla pagina di gestione campagne. Nel menù a sinistra compaiono due voci per gestire Campagne e Etichette.
Direi di sperimentare da lì l'interfaccia per la creazione/modifica/eliminazione di campagne ed etichette.
Quando si crea una campagna, c'è un primo step dove si definiscono i campi descrittivi della campagna e l'aggiunta di etichette (precedentemente create), poi c'è un secondo step dove si aggiungono i responsabili per quella campagna (delega RESPONSABILE_CAMPAGNA per l'oggetto campagna che si sta creando).
Nello step uno, testare che le sedi disponibili per la campagna sono soltanto quelle fra cui si ha la delega (DELEGA_CAMPAGNE) o di cui si è presidente. Le sedi sono espanse ma sono filtrate secondo il requisito:
Le entità autorizzate alla creazione di campagne saranno:
- Comitato nazionale
- Comitato territoriale
- Comitato regionale, solo quando abbiano impostato CF e PIVA e questi sono diversi dal Comitato nazionale
Nello step uno, testare che le etichette che compaiono nel widget all'atto della creazione campagna dovrebbero essere soltanto quelle specifiche del comitato più quelle create dal comitato nazionale.
Testare anche loggandosi con un utente responsabile di alcune campagne per controllare che nella lista delle campagne compaiono soltanto quelle di cui è responsabile. Un responsabile di campagna non dovrebbe vedere il pulsante Crea nuova campagna né avere i permessi per visualizzare la pagina di creazione. Un responsabile di campagna non dovrebbe avere i permessi per la modifica/eliminazione di etichette.
A disposizione per chiarimenti e bugfix:)
@Ele81 è necessario che tu segua questa fase implementativa per la documentazione tecnica (wiki)
Cambiamo il nome all'etichetta ("campagne" in CRI non vuol dire nulla), quanto meno in "Donatori"
@domeniconappo le viste lato Django con i vari livelli di permesso (view,delete,change,add) sono stati previsti?
@galamarco Ok.
@PaoloGiustiniani No, le viste non usano i permessi definiti nei modelli. L'accesso alle viste e le varie funzionalità si basano sulle deleghe gestione_campagne e responsabile_campagna. Ho mancato qualcosa?:)
@domeniconappo gli admin devono essere in grado di poter amministrare e gestire tutte queste funzionalità lato Django ed i vari permessi lato admin devono poter essere delegati.
@AlfioEmanueleFresta potrà darti più informazioni.
La dicitura Responsabile Campagne Comitato è errata. Come aveva richiesto @galamarco va indicato come Responsabile campagne di raccolta fondi. Il nome della delega deve essere quindi Campagne di raccolta fondi e con Campagne Donazioni

@domeniconappo In aggiunta ai commenti allegati alla review, ho notato che l'oggetto etichetta ha un campo nome -- questo non e' nei requisiti ed e' un campo ridondante, va rimosso. Le etichette sono intese come dei tag e non dovrebbero avere piu' che un singolo campo identificativo - appunto, lo slug. Ti prego di notare che questo e' diverso dalle campagne, che hanno infatti un requisito che menziona esplicitamente il campo "nome".
Re. la normalizzazione del database -- le etichette dovrebbero avere un indice di univocita' multi-colonna (sede, slug), anche se noto che questa scelta architetturale e' stata rotta dall'introduzione del requisito B4 sulle etichette globali -- ho chiesto delucidazioni in merito a @galamarco in #620.
@AlfioEmanueleFresta Grazie per le dritte. Sto implementando i cambiamenti richiesti al codice. Avrò delle difficoltà riguardo alla logica di riconciliazione ma dovrei farcela.
Per quanto riguarda invece il campo 'nome' per Etichetta, ho una domanda al riguardo: Attualmente, il campo slug non viene inserito direttamente dall'utente tramite form. Lo slug viene popolato a partire dal campo 'nome' immesso dall'utente e l'univocità (slug, comitato) è già definita.
Eliminando il campo nome, diventa un po' più complicato gestire lo slug e sto cercando di capire come fare. Hai indicazioni al riguardo?
Eliminando il campo nome, diventa un po' più complicato gestire lo slug e sto cercando di capire come fare. Hai indicazioni al riguardo?
Per iniziare, un semplice LowerCaseField con un validatore su una regex (e.g. ^[a-z][a-z0-9\-]+[a-z]$)?
@domeniconappo, a quanto pare il problema che fermava Wonderbot e ci impediva di testare questa PR e' che requirements.txt ha dei requisiti non validi. In particolare, in un ambiente senza le dipendenze PIP installate, il comando che segue fallisce miseramente:
pip install -r requirements.txt
Pare che la versione di un pacchetto che richiedi esplicitamente non sia piu' disponibile su pipy.
Could not find a version that satisfies the requirement pyexcel-io==0.4.1 (from -r requirements.txt (line 45)) (from versions: 0.0.1, 0.0.2, 0.0.3, 0.0.4, 0.0.5, 0.0.6, 0.0.7, 0.0.8, 0.0.9, 0.1.0, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4.1, 0.4.2, 0.4.3, 0.4.4) No matching distribution found for pyexcel-io==0.4.1 (from -r requirements.txt (line 45))
(Errore cortesia di @luca-dex)
Il problema è pyexcel-io versione 0.4.1 che non è più presente nei repo
@luca-dex @AlfioEmanueleFresta Grazie per la segnalazione...perché hanno tolto dal repo proprio quella versione? :) Aggiorno alla più recente e faccio dei test per verificare che tutto sia a posto.
L'unica cosa che posso dire è la seguente: lo stile di questo form di ricerca non rispetta l'impaginazione degli altri oggetti:

Per il resto non ho potuto effettuare nessun tipo di test in quanto al momento di inserire l'organizzatore di una campagna di raccolta fondi ottengo questo errore:

Ho effettuato il test basandomi sull'ultima versione disponibile del codice e ricreando da zero l'istanza su wonderbot. Per effettuare il test ho utilizzato un presidente locale, un delegato a livello locale, il presidente nazionale, un delegato a livello nazionale e tutte le prove hanno dato lo stesso esito.
In conclusione alla data attuale il branch non può essere testato.
@luca-dex Ciao Luca, sì stupido bug dell'ultim'ora. Ho pushato un fix per questo.
I problemi segnalati l'ultima volta sono stati risolti, quindi ho provveduto ad effettuare dei nuovi test
Problemi che permangono:
- siccome non è possibile registrare donazioni nel futuro, se la campagna non è ancora iniziata, non deve essere possibile accedere alla schermata di inserimento delle donazioni, altrimenti l'utente compila tutta una serie di dati ma si trova poi impossibilitato a completare l'operazione


- alla registrazione del donatore il sistema accetta date di nascita nel futuro

- quando ci sono errori sui campi, il validatore del form segnala l'errore in fase iniziale, ma marca tutti i campi come validi (contorno verde) (vedi img sotto)
- se sono presenti delle donazioni associate ad una campagna non deve essere possibile variare la data di inizio e/o fine della campagna permettendo così alla donazione di finire al di fuori del periodo della campagna stessa


-
(segue dalla precedente) se dopo aver spostato le date la donazione finisce fuori dalla campagna, una volta che si accede in modifica il sistema obbliga a spostare la data di donazione all'interno del range

-
non vedo particolare utilità nell'avere donazioni da 0.00 €

- il layout di questo filtro non rispetta l'altezza di riga e in generale i filtri non sono uniformi tra le varie pagine delle donazioni

@luca-dex Grazie per i test. I fix saranno pushati sul branch insieme ai requisiti D (prossimo rilascio prima del 15 ottobre).
Soltanto una nota riguardo all'ultimo screenshot: non mi è possibile risolvere la differenza di altezza della riga dato che quel filtro permette l'aggiunta di etichette che vanno a riempire ed ingrandire di conseguenza l'area di testo. Serve per evitare che il pulsante con la lente di ingrandimento si disallinei dall'input. E' il meglio che sono riuscito a fare e non vedo soluzioni a meno di adottare qualcosa di completamente differente. Potresti inoltre indicarmi in che senso "i filtri non sono uniformi"? I filtri si adattano alla specifica lista ma il layout è identico (a parte questo caso segnalato nello screenshot).
Altra questione: sono stati testati i requisiti per l'import massivo di donazioni tramite XLS/CSV?
@luca-dex @PaoloGiustiniani Potreste creare una issue su JIRA per i requisiti D1-D12? Corrisponderebbero allo Sprint 5...