-
Notifications
You must be signed in to change notification settings - Fork 3
Condivisioni
feroda edited this page Oct 2, 2012
·
11 revisions
- Apertura di una action:
- sceglie i territori
- sceglie i politici
- completa la action
- Geonames: fanno avere loro widget ed eventualmente dump per la ricerca geografica e l'autocompletamento
- Politici: fanno avere loro la API. Protocollo:
- chiedere politici a OpenPolis
- parsare JSON/XML di risposta
- calcolare lo score
- restituire all'utente la form di scelta dei politici (formato?) con lo score per l'agg. del totale via javascript. Evidenziare la possibilità di proporre una mail per un politico
- ricevere la POST, registrare la action, inviare eventuali email proposte ad OpenPolis
- Categorie: basta il nome della categoria e la aggiungono ad admin interface
- [Token: valido per un utente, per una azione](Il modello). Tempo di scadenza variabile, ma sarà impostato "lungo"
- Modifica in generale avviene solo in stato DRAFT, ma lasciare aperta la possibilità di implementare controlli più fini in futuro
- Follow/Unfollow
- I moderatori possono fare tutto quello che fanno i proprietari di una action, tranne approvare ulteriori moderatori.
- API politici OpenPolis restituisce (istituzione, carica, abitanti) = parametri per calcolo del threshold.
- I Geonames vengono restituiti da una API OpenPolis
- Relazione utente/associazione: può rappresentarla, concede accesso dati
- TODO: l'utente che concede i dati ad un'associazione per una action -> ha concesso a quell'associazione il trattamento dei dati per tutte le action. Questa è una info che deve essere ritornata nella vista di una action.
- TODO: tutti i voters seguono la action
- Localizzazione: in generale tutto quello che non deve essere tradotto all'utente ok in inglese, ma per il resto risparmio della traduzione. (p.e: eccezioni)
- Protocollo per risposte HTTP/Ajax. Stub in lib/views_support.py <--- vedere vista per vista
- Integrazione social_auth <-- vedere branch "social_auth" in openmunicipio
- Notifiche (oa_notification): definizione, backends e configurazione <-- backend uso di API facebook
- Un utente può essere associato con un solo account esterno per tipo di backend
- Recupero amicizie: se l'utente vuole, il sistema identifica gli amici dei social network che hanno un account su OpenAction <-- per ora supportare solo le amicizie facebook
-
user_join_same_action: è da pazzi :) se una action riceve 1000 voti, ogni utente riceve ~1000 notifiche? Prevedere operazioni temporizzate (cron) in questo caso che mandi un riepilogo dei voti dell'ultima settimana (ad esempio) [TODOFUTURE]
-
create_action. La specifica attuale prevede diverse notifiche su creazione di una action: Un utente della sua rete social apre una action, Una action del suo territorio (regione, provincia, comune) viene aperta, Una action con tema preferito viene aperta, se si verifica più di una delle precedenti condizioni l'utente riceve notifiche multiple. Sarebbe il caso di cambiare punto di vista? Tipo: "notifica creazione action interessante" con un elenco "perché ti dovrebbe interessare questa action"? [OK]
- Le richieste di moderazione possono essere indirizzate ai followers che non sono già moderatori
- Possono essere fatte al massimo MAX_MODERATION_REQUESTS (default=3) verso un follower per richiedere di moderare una action, se non bastano sarà lo staff ad intervenire nell'admin interface
- Le action request indirizzate a NULL sono indirizzate allo staff di OpenAction
- abbiamo messo la possibilità di scrivere un commento alla richiesta di moderazione e alla risposta (alla fine è una sorta di messaggi privati)
- TODO Possibilità di rimuovere un moderatore
- TODO il messaggio è indirizzato a tutti i referrers
- TODO le risposte (testo) sono da gestire? sì. Come? come le richieste di moderazione
- TODO sempre con il metodo delle richieste
- TODO comunicarlo a tutti i referrers
- TODO Concessione dati personali a terzi: consentiamo di decheckare la concessione dei dati all'associazione, e avvisiamo che devono rivolgersi a loro per la cancellazione dei dati da loro
- per quello che riguarda il processo di moderazione (A richiede, B risponde), cosa ci va messo nelle attività di A e B? CE NE FREGHIAMO
- TODO se ha votato in modo anonimo -> mettere utente ha aderito ad "una action"
- riusato modello Activity di askbot (proof-of-concept con Matteo sembra ok, da revisionare Luca)
- TODO? implementata gestione per stati VICTORY e CLOSED
- TODO? implementata gestione per segui l'associazione, rappresenta l'associazione
- templatetags
- Gestione dei collegamenti a risorse esterne
- Risposte del politico: la risposta del politico vogliamo che possa essere votata/commentata/etc o no? In caso positivo sarà un commento sull'azione fatta da un utente "bot" con la referenza ''in nomine politician'' all'ID del politico.
- TODO: seguitori anonimi? Se uno vota in modo anonimo poi appare tra i follower... valutare i problemi.
- Registrazione --> accettazione tos e pri, non devono essere salvate nel db?