Menu
▾
▴
partecipa-net-devel — Developers list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(5) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Enrico A. <an...@na...> - 2008-02-21 13:13:20
|
Aggiornamento del CVS: 1) Implementazione password criptate: Il sistema ora scrive le password nel database (Partecipa.base tabella persone) in un hash Md5 one-way, dal quale non puo' essere ricavata la password in chiaro. Sono state modificate tutte le routine che confrontavano la password e quindi le procedure di login, modifica password sia da utente che da amministratore, remind della password e registrazione iniziale dell'utente. Ho cercato di attenermi il piu' possibile alle procedure che tutti gli utenti Partecipa.net conoscono, ma nel caso del reminder della password ho dovuto cambiare leggermente la modalita': anziche' trasmettere la password in chiaro, cosa che evidentemente non e' piu possibile, all'utente viene azzerata la password e ne viene generata una nuova in modo pseudocasuale. Per non modificare la logica procedura di registrazione iniziale che prevede la scelta della password da parte dell'utente, ho dovuto implementare un sistema che salva temporaneamente la password fornita dell'utente in un file temporaneo che viene eliminato alla conferma della registrazione. Se ci fossero dubbi sulla sicurezza della cosa: finche' l'utente non conferma la registrazione lo stato dell'utente e' sospeso, quindi tale password non puo' essere usata in alcun modo... inoltre se qualcuno dovesse raggiungere il filesystem del server, la directory /tmp contiene anche le sessioni di apache che sono ben piu' pericolose... inoltre questi file non contengono l'account dell'utente ma solo la password, e vengono eliminati dal filesystem non appena l'utente conferma la registrazione. Per aiutare chi ha gia' una base installata con password in chiaro ho realizzato uno script di conversione che si trova in ./contrib: lo script va eseguito dalla stessa directory con: ./partecipa-maint.pl pwdconv che effettua la lettura della password in chiaro, le salva in un file cleartext_password_<data>.txt nella directory corrente ed effettua un update su tutti gli utenti con la password MD5. Inoltre eseguendo: ./partecipa-maint.pl savepwd viene creato uno script sql contenente le password attuali (indipendentemente dal fatto che siano in chiaro o meno) e che importato nel db riportera' le password di tutti gli utenti a quello stato. 2) Fix per integrazione Sympa: Dopo il fix per le accentate del precedente aggiornamento, ho scoperto che l'integrazione con sympa per l'archivio newsletter non funzionava piu': indagando ho trovato un pezzo di codice perl in TRIStateCGI.pm immesso da un terminale non UTF8 e che dava problemi in fase di conversione UTF8: per ora ho cambiato encoding prima della riga incriminata e l'ho rimesso in UTF8 immediatamente dopo, e la cosa sembra non dare problemi, quindi nel frattempo metto il fix in cvs: con calma vedro' se e' possibile adottare soluzioni piu' pulite (forse basta riscrivere manualmente la riga di codice incriminata senza cut&paste) |
|
From: Enrico A. <an...@na...> - 2008-02-12 16:41:33
|
Salve a tutti, ho appena aggiornato il CVS con alcuni bugfix importanti, che condizionano il corretto funzionamento di Partecipa.net: 1) La gestione delle accentate era sbagliata: per prima cosa venivano renderizzate in HTML con UTF-8 direttamente anziche' con le corrette html entities (è à etc. etc.); inoltre nella modifica a dati come titoli di aree tematiche e newsletter venivano impropriamente scritte nel database con codifica ISO-8859-1 e quindi risultavano errate; qualora poi un utente avesse nel proprio nome o cognome una lettera accentata, il login falliva. 2) Il file principale di Partecipa.base, cioe' il cgi-bin "unox1" non era inserito correttamente nell'albero sorgente, causando il mancato aggiornamento in caso di upgrade 3) Un file necessario alla gestione dinamica delle aree tematiche (aree_tematiche.conf) mancava dall'albero sorgente, causando un'errore all'avvio dell'applicazione 4) La tabella "log" necessaria alle statistiche mancava completamente di indici nel database postgres, causando tempi di esecuzione di qualsiasi modulo statistico esageratamente lunghi: ho quindi aggiornato nel CVS lo script di creazione db; questo si risolve comunque velocemente senza dover reinstallare eseguendo l'istruzione SQL: CREATE INDEX statistiche_idx ON log USING btree (autore, "time", servizio, attivita, error, completed, extra) Questi bugs sono stati corretti ed aggiornati nel CVS: se qualcuno avesse urgenza di aggiornare la propria installazione ed avesse problemi ad accedere al CVS, puo' chiedere in lista: forniro' istruzioni su come accedere e scaricare l'albero di sviluppo in CVS; a breve comunque uscira' una release contenente queste modifiche. Se avete problemi ad accedere al CVS per motivi di rete o altre limitazioni, chiedete in lista, postero' i files incriminati in modo che sara' sufficiente copiarli sopra le vecchie versioni sull'installato. |
|
From: Enrico A. <an...@na...> - 2008-01-25 17:40:55
|
Quoting Lucia Mazzoni <luc...@as...>: > Ciao, > ho fatto l'aggiornamento alla RC3 di una installazione su macchina > virtuale che non era ancora mai stata aggiornata. > > La procedura =E8 stata eseguita in generale correttamente (qualche > inceppo, ma non saprei rimapparlo) ma quando mi collego a partecipa mi > viene scodellata la pagina che allego. D=E0 l'idea che manchi un modulo > perl. Risulta? Risulta risulta... e' il modulo per gli hash ordinati (usati per =20 risolvere il bug delle popup con ordinamento casuale); se sei su =20 CentOS il pacchetto e' perl-Tie-IxHash, altrimenti vai di CPAN... =20 oltre a quello si lamentera' anche per Spreadsheet::WriteExcel: ho =20 preferito non includerli nella release perche' non ho problemi =20 specifici di versione quindi preferisco usare quanto fornito dalla =20 distribuzione e/o da CPAN. Il problema e' che mentre ho segnalato di =20 installare WriteExcel questo me l'ero completamente scordato! |
|
From: Enrico A. <an...@na...> - 2008-01-18 16:40:47
|
Rilasciata la release RC3_FINAL. Questa release e' marcata RC3_FINAL nonostante sia feature complete =20 solo perche' non ho potuto testarla su altre installazioni, e non ha =20 passato un periodo di utilizzo reale da parte degli utenti: e' =20 comunque stata testata ripetutatmente sulla mia macchina di sviluppo e =20 dovrebbe essere completa nonche' funzionante. Ho sistemato alcuni bugs della RC2, il piu' grave nel Makefile, che =20 causava un errore verso la fine di "make install". Inoltre ho sistemato alcuni bugs minori in sendPage e nel cgi-bin. Aggiunto un sistema di logging separato dal log di apache, per =20 chiarezza e per velocizzare il debugging: ora tutti i log vanno in =20 /var/log/partecipa.log. Implementato ed integrato nel Makefile il sistema di upgrade per i =20 templates ed i fogli di stile: il sistema e' autodocumentato, nel =20 senso che durante la normale procedura ./configure, make l'utente =20 viene avvertito del nuovo target "make upgrade" e del suo utilizzo; la =20 procedura funziona in questo modo: a fianco della directory che ospita =20 i templates, solitamente =20 /usr/local/Partecipa.net/partecipa.base/lib/servers/pub/templates e' =20 stata creata una directory custom_templates: qui vanno copiati i =20 template modificati rispetto allo standard: se il sistema trova un =20 template personalizzato in questa directory con lo stesso nome di =20 quelli standard, verra' visualizzato quello personalizzato, evitando =20 cosi' eventuali sovrascritture con conseguente perdita delle =20 personalizzazioni durante l'installazione. In aggiunta a questo sistema, se l'utente non ricorda quali files ha =20 modificato (!!) viene proposta dopo il make l'esecuzione del nuovo =20 target "make upgrade", il quale lancia una procedura che legge la =20 configurazione di unox1.conf uscente dal make appena eseguito, ricava =20 i path di templates e stylesheets (che se l'utente non ha sbagliato il =20 configure corrispondono all'installazione precedente **), calcola il =20 checksum MD5 dei files attualmente installati e li confronta con un =20 suo database interno contenente i checksum di tutte le release finora =20 rilasciate: qualora vengano riscontrate differenze viene presentata =20 alla fine una lista dei files modificati, e vengono presentate le =20 istruzioni su come procedere, che consistono nel copiare a parte i =20 files indicati, eseguire "make install" e ricopiare i files salvati =20 nella directory custom_templates. Un lavoro analogo viene fatto con i fogli di stile, solo che purtroppo =20 per questioni inerenti l'implementazione del codice non e' stato =20 possibile implementare lo stesso meccanismo per i CSS: l'utente viene =20 comunque avvertito se i files sono diversi, e da li e' possibile unire =20 manualmente le modifiche o sovrascrivere la nuova versione di CSS con =20 la propria. L'upgrade dello schema di database deve comunque venire eseguito a =20 mano perche' ci sono troppe varianti in gioco (versione di Postgres, =20 versioni di perl) e si rischiava di perdere tutti i dati preesistenti. NOTE: ** in ogni caso se l'utente sbaglia il configure il sistema avverte =20 che non riesce a trovare i files, quindi l'utente e' incoraggiato a =20 ripetere la procedura. |
|
From: Lucia M. <luc...@as...> - 2008-01-11 15:45:49
|
Enrico Ansaloni wrote: > E' pronta la release di Partecipa.base 1.1 RC2. >=20 > Aggiunti i bugfix e le funzionalita' richieste mancanti alla RC1: > - export Excel sulle statistiche > - aggiunta dinamica di news in homepage > - integrazione con gli archivi newsletter di Sympa. >=20 > Per l'integrazione con sympa, leggere le istruzioni in =20 > contrib/sympa/README.txt Grazie! e buon anno ad Enrico! Lucia NB ora c'=E8 ancora in ballo solo la parte sui template, dico bene? |
|
From: Enrico A. <an...@na...> - 2008-01-11 15:41:10
|
E' pronta la release di Partecipa.base 1.1 RC2. Aggiunti i bugfix e le funzionalita' richieste mancanti alla RC1: - export Excel sulle statistiche - aggiunta dinamica di news in homepage - integrazione con gli archivi newsletter di Sympa. Per l'integrazione con sympa, leggere le istruzioni in contrib/sympa/README.txt |
|
From: Lucia M. <luc...@as...> - 2007-12-07 11:48:24
|
Enrico Ansaloni wrote: > Salve a tutti e' in linea la nuova release 1.1 RC1 > La versione definitiva richiede un po' di test ulteriori ma le > funzioni richieste sono tutte implementate. > Manca la procedura di upgrade automatico che verra' aggiunta in una > successiva release. > Questa versione richiede un po di test perche sono state aggiunte > moltissime funzioni e modificate delle parti essenziali che erano > buggate o male implementate: soprattutto sono molto utili > installazioni su distribuzioni diverse dalla mia o configurate in modo > diverso, per evidenziare eventuali bug che nella mia piattaforma di > testing e sviluppo io non posso vedere. YOUPPPPPPPPPPIIIIIIIIIIIIIIIIII! Complimenti Enrico per il lavorone! :) Lucia |
|
From: Enrico A. <an...@na...> - 2007-12-07 11:26:53
|
Salve a tutti e' in linea la nuova release 1.1 RC1 La versione definitiva richiede un po' di test ulteriori ma le funzioni richieste sono tutte implementate. Manca la procedura di upgrade automatico che verra' aggiunta in una successiva release. Questa versione richiede un po di test perche sono state aggiunte moltissime funzioni e modificate delle parti essenziali che erano buggate o male implementate: soprattutto sono molto utili installazioni su distribuzioni diverse dalla mia o configurate in modo diverso, per evidenziare eventuali bug che nella mia piattaforma di testing e sviluppo io non posso vedere. |
|
From: Enrico A. <an...@na...> - 2007-11-21 20:01:47
|
E' pronta l'implementazione completa dei livelli di accesso legati =20 alle redazioni. Questa funzione ha comportato le seguenti modifiche: 1) creazione della tabella "redazioni" contenente l'elenco delle =20 redazioni ricavato dal campo responsabile della tabella news. Lo =20 script per creare questa tabella e' contenuto in =20 contrib/create_redazioni_table.sql; per inizializzare questa tabella =20 con le newsletter gia' registrate e' possibile utilizzare lo script =20 popola_tabella_redazioni_dalle_news.pl sempre in contrib 2) creazione della tabella persone_redazioni contenente la relazione =20 fra utenti di tipo editore e redazioni di competenza 3) il meccanismo stesso dei livelli d'accesso, che oltre ai template =20 contenuti nel precedente update cvs, filtra automaticamente le news =20 visualizzate per redazioni registrate per l'utente 4) Implementazione del cambio di tipologia utente nell'interfaccia di =20 gestione utenti: e' possibile ora impostare qualsiasi utente come =20 utente, amministratore o editore: nell'ultimo caso sara' visualizzato =20 un elenco di redazioni nello stesso stile delle iscrizioni alle =20 newsletter 5) Aggiunta automatica delle redazioni nell' apposita tabella in caso =20 di aggiunta / modifica di una news |
|
From: Enrico A. <an...@na...> - 2007-11-21 20:01:45
|
|
From: Enrico A. <an...@na...> - 2007-11-06 14:53:51
|
Ho aggiornato il cvs con la nuova funzionalita' di creazione template automatica alla creazione di aree tematiche. Il tutto funziona creando 4 files con nome: <argomento>_general.template <argomento>_personal.template corpo_lista_<argomento>.template corpo_lista_<argomento>_personal.template all'utente resta solo da creare il quadratino del colore desiderato nel foglio di stile, che poi apparira' nel menu di sinistra (prendere ad esempio lo stile contrassegnato con: #sx1 li .generale) La cosa funziona anche in caso di modifica o cancellazione di una classe: nella modifica il file viene cancellato e ricreato col nuovo nome argomento, mentre nella cancellazione i template attinenti vengono eliminati automaticamente |
|
From: Enrico A. <an...@na...> - 2007-11-05 16:01:24
|
Salve a tutti ho aggiornato il CVS con le ultime modifiche per implementare la prima versione dei livelli di accesso: la cosa non e' ancora completa perche' manca il filtraggio delle statistiche sulle newsletter che fanno capo alla redazione dell'utente: infatti mancava completamente una parte che abbinasse una redazione ad un utente, cosa che sto ancora implementando. Intanto pero' se un utente viene registrato come figura 2 (Editore) al login avra' un menu con la voce statistiche che appare come nel login di amministratore, e potra' visualizzare le statistiche sulle newsletter, ripeto senza ancora il filtro per redazione. Inoltre resta da implementare l'inserimento di questi dati (figura, redazione) nell'interfaccia di gestione utenti dell'amministratore: al momento l'impostazione della figura "editore" puo' essere fatta solo accedendo direttamente al database postgres. |
|
From: Enrico A. <an...@na...> - 2007-09-28 16:23:25
|
Changelog: * Realizzazione modifiche richieste a tutti i moduli statistici: - rimozione campi di ricerca inutili - correzioni testi - aggiunta dell'opzione SORTBY alla definizione di form per permettere =20 la scelta di ordinamento by label o by value nei popup (richiesto per =20 ordinamento login) - correzioni alle dimensioni delle scrolling list - completa reimplementazione delle funzioni di calcolo date per =20 rispettare i limiti temporali del periodo (settimana inizia al lunedi, =20 mese inizia il primo del mese etc.) - riscrittura delle funzioni di visualizzazione data in modo da =20 fornire dati comprensibili e variabili in base al periodo scelto, ad es: Giornaliero: 28 Settembre 2007 Settimanale: Settimana X (Lun 24 Settembre 2007) Mensile: Settembre 2007 Annuale: 2007 * BUGFIX: - aggiunta del meccansimo di forking a tutti i moduli statistici per =20 evitare timeout: si tralascia newsletter istantanee perche' quella =20 query non varia molto al variare della quantita' di dati. - implementazione del passaggio parametri ai popup con Tie::IxHash per =20 manenere l'ordinamento, spostando la sort da perl a SQL ed evitando lo =20 spreco di CPU |
|
From: Enrico A. <an...@na...> - 2007-09-28 12:24:44
|
Salve a tutti. Ho pubblicato su SourceForge un'immagine vmware di un sistema linux installato e configurato con tutti i componenti di Partecipa.net. La policy di SourceForge non consente di pubblicare files troppo grandi, quindi sul sito troverete un documento contenente le istruzioni per il setup e l'URL per lo scaricamento. |
|
From: Enrico A. <an...@na...> - 2007-09-05 11:25:10
|
Ho aggiornato il cvs per un problema che si era manifestato presso il =20 Comune di Modena dove, essendoci molti iscritti, quando si eseguivano =20 certe statistiche (in particolare la statistica utenti) si verificava =20 un timeout lato server in quanto l'esecuzione in linea dello script =20 richiedeva piu' di 300 secondi (che e' il timeout di default di apache) Questo problema ne espone uno molto piu' generico che ho dovuto =20 risolvere per forza: qualsiasi operazione in Partecipa.base viene =20 eseguita in linea, e se supera il timeout di apache puo' incorrerre =20 nello stesso problema; avevo gia' riscontrato un problema simile =20 nell'invio in massa delle email per i sondaggi (ora risolto), ma in =20 quel caso ho preferito optare per una soluzione specifica perche' la =20 mail aveva bisogno di sicurezze aggiuntive e soprattutto non c'era la =20 necessita' di un feedback immediato all'utente, come nel caso delle =20 statistiche. Per questi motivi ho dovuto interrompere il resto dello sviluppo per =20 concentrarmi su questa cosa, che mi ha richiesto parecchio tempo =20 perche' comporta varie modifiche al componente principale di tutto =20 Partecipa.net, cioe' il cgi-bin unox1 (normalmente installato in =20 /var/www/cgi-bin/partecipa.base/unox1) che esegue tutte le funzioni =20 condivise dell'applicativo (template, autorizzazioni, database etc) e =20 che lancia le procedure esterne richieste (i comandi .uxu). Inoltre la soluzione doveva essere piu' generica possibile, ed =20 implementabile con le minori modifiche possibili ai moduli che via via =20 presentassero questo problema di timeout. La soluzione che ho scelto e' la seguente: implementare nel cgi-bin =20 unox1 un redirect comandato da parametri cgi, che rimadasse ad una =20 pagina intermedia di attesa, generica, che a sua volta effettuasse un =20 refresh periodico per mostrare l'avanzamento dell'elaborazione, ed =20 alla fine di questa elaborazione presentasse all'utente un link per =20 visualizzare il risultato dell'elaborazione. Inoltre a fronte di questo redirect sono stato costretto a lanciare i =20 comandi .uxu "pesanti" con un fork, in quanto senza questo espediente =20 l'elaborazione rimarrebbe in linea e si incapperebbe nello stesso =20 errore di timeout, perche' il wrapper (unox1) attende l'uscita dal =20 comando .uxu per chiudere la sessione http. L'aggiornamento che ho appena fatto sul cvs comprende appunto le =20 modifiche al cgi-bin unox1, la form di attesa, la funzione per =20 aggiornare lo stato corrente dell'elaborazione e le modifiche alla =20 form e al comando di statistiche utenti. Per ora sembra funzionare egregiamente nel mio ambiente di test; =20 lascio da parte l'implementazione di questo nuovo sistema nei restanti =20 moduli statistici per permettervi di testare questo codice in ambienti =20 diversi dal mio: se il riscontro sara' positivo, o in alternativa se =20 fra un po' di tempo non avro' nessun riscontro procedero' alla =20 modifica a tappeto di tutti i moduli statistici . I files da aggiornare tramite cvs sono: ./src/common/lib/functions/misc-utils.pl ./src/web-interfaces/pub/templates/head_refresh.template ./src/web-interfaces/pub/templates/wait_page.template ./src/web-interfaces/pub/templates/corpo_wait_page.template ./src/web-interfaces/pub/templates/top_refresh_personal.template ./src/web-interfaces/pub/unox1 ./src/web-interfaces/pub/forms/statistiche_utenti.form ./src/web-interfaces/pub/cmds/adminStatUsers.uxu Come sempre vi consiglio di non testare il codice su macchine di =20 produzione e comunque di fare un backup dei files originali in modo da =20 poter tornare indietro in caso di problemi. |
|
From: Enrico A. <an...@na...> - 2007-08-30 09:44:01
|
La release 1.0rc6 di Partecipa.base e' ora disponibile per il download su http://partecipa-net.sourceforge.net |
|
From: Enrico A. <an...@na...> - 2007-08-30 09:23:53
|
Salve a tutti a breve pubblichero' una release intermedia di bugfix su partecipa-net.sourceforge.net: Il changelog completo sara' visibile sul sito, vi invito a testare l'installazione possibilmente non su macchine di produzione, o in quel caso a creare una copia di backup dei files precedenti, ad esempio (mantenendo le directory di installazione di default): cp -ar /usr/local/Partecipa.net /usr/local/Partecipa.net.bak cp -ar /var/www/cgi-bin /var/www/cgi-bin.bak cp -ar /var/www/html /var/www/html.bak |
|
From: Enrico A. <an...@na...> - 2007-06-08 15:06:09
|
BUGFIX: Aggiunto il controllo di range in OpenCA::TRIStateCGI.pm - ora =20 specificando "range <min> <max>" nelle definizioni di form viene =20 effettuato un controllo sui limiti minimo e massimo del range di un =20 input numerico; in questo caso serve per validare l'input del popup =20 delle province di residenza (min 1 max 106). Ora tutte le form di =20 modifica dati utente hanno il controllo esplicito anche sulla =20 selezione della provincia. BUGFIX: Sistemato il controllo che evita di inserire e/o modificare i =20 dati dei contatti in adminModPersona, e che a volte generava l'errore =20 di "email gia' esistente" Per aggiornare: - cvs checkout Partecipa.base - Copiare i files: da: <cvs_dir>/src/modules/openca-tristatecgi/TRIStateCGI.pm a: <install_dir>/modules/perl5/OpenCA/TRIStateCGI.pm da: <cvs_dir>/src/web-interfaces/pub/cmds/adminModPersona.uxu a: <install_dir>/partecipa.base/lib/servers/pub/cmds/adminModPersona.uxu da: <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona.conf a: <install_dir>/partecipa.base/etc/servers/pub/forms/mod_persona.conf da: <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona_registra.conf a: =20 <install_dir>/partecipa.base/etc/servers/pub/forms/mod_persona_registra.conf da: <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona_totale.conf a: <install_dir>/partecipa.base/etc/servers/pub/forms/mod_persona_totale.co= nf da: <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona_admin.conf a: <install_dir>/partecipa.base/etc/servers/pub/forms/mod_persona_admin.con= f |
|
From: Enrico A. <an...@na...> - 2007-06-01 15:53:09
|
BUGFIX: ho impostato la form di modifica dettagli utente in fase di =20 registrazione in modo che le varie tendine abbiano i default vuoti, e =20 che quindi venga generato un errore se non viene selezionato nessun =20 valore. L'unico problema e' nel caso della provincia di residenza, perche' il =20 framework CGI sottostante (OpenCA::TRIStateCGI) non distingue fra tipi =20 di dati e l'unico controllo possibile sul dato numerico (id provincia) =20 e' sul numero di cifre, non sul numero in se, mentre l'altro framework =20 di astrazione dei dati (UnoX1::Object) non mi permette di impostare =20 valori vuoti come option select, per cui l'unica gestione dell'errore =20 possibile e' quella di eseguire una query errata (UPDATE persona SET =20 residenza=3D'0') e poi catturare l'errore in un template specifico =20 successivo, oppure creare una variabile ad arte ed inserirla in una =20 cella adiacente alla tendina. Per ora ho inserito nel CVS le modifiche ai default su sesso e data di =20 nascita, a breve aggiornero' anche questo controllo d'errore sulla =20 residenza. Per aggiornare: - cvs checkout di Partecipa.base - copiare i files: <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona_registra.conf <cvs_dir>/src/web-interfaces/pub/configs/forms/mod_persona_totale.conf nella directory <install_dir>/partecipa.base/etc/servers/pub/forms/ sovrascrivendo i files esistenti |
|
From: Enrico A. <an...@na...> - 2007-05-31 21:43:37
|
Risolto il bug che impediva all'applicazione di aggiornare correttamente lo stato dell'utente a 'R' quando l'utente veniva cancellato dall'amministratore Per aggiornare: - fare il checkout del cvs - copiare il file: <cvs_dir>/src/web-interfaces/pub/cmds/adminDelUser.uxu in <install_dir>/partecipa.base/lib/servers/pub/cmds/adminDelUser.uxu |
|
From: Enrico A. <an...@na...> - 2007-05-28 14:54:12
|
Ho aggiornato il cvs con delle sostanziali modifiche alla parte =20 preposta all'invio di email per i sondaggi: la routine usata (sia =20 all'apertura del sondaggio che al reminder di un sondaggio gia' =20 aperto) aveva problemi nell'invio di un quantitativo di email =20 superiore a 200, in quanto la procedura non era scollegata dalla =20 generazione della pagina e ciclando sull'invio delle mail ad un certo =20 punto incontrava il timeout interno del webserver causando =20 l'interruzione della procedura. Inoltre non c'era nessun controllo per =20 evitare di piantare la macchina che esegue sendmail con troppi =20 processi aperti. Per ovviare a questi inconvenienti ho riscritto completamente quella =20 parte, creando un apposito modulo perl (Safe::Sendmail) che ricalca le =20 procedure di invio in massa utilizzate da Sympa, in modo da usare cose =20 gia' ampiamente collaudate per volumi di mail maggiori di 30000. Inoltre la parte che alla pressione di "Invia Email" rimaneva appesa =20 causando il timeout, ora effettua un fork di un processo perl, che a =20 sua volta cicla sugli utenti trovati nel db ed iscritti al sondaggio =20 corrente: per questo l'utente avra' immediatamente una pagina di =20 conferma dell'operazione, con un link che rimanda ad un file html che =20 viene generato dalla procedura in background: aprendo questo link e =20 facendo refresh l'utente potra' seguire il progresso dell'invio delle =20 email; questa parte e' ancora ampiamente migliorabile, accetto =20 suggerimenti in proposito: lo scopo di questa update pero' e' =20 soprattutto quello di risolvere il bug che impediva di fatto l'invio =20 di email di notifica e/o reminder per sondaggi con piu' di 200 iscritti. Un log delle operazioni si potra' trovare in /tmp/safesendemail.log: =20 anche questa parte e' modificabile facilmente. Per installare i nuovi files su una installazione gia esistente, =20 effettuate le seguenti operazioni: 1) checkout dell'ultimo CVS sia di Partecipa.base che di Partecipa.poll 2) Entrare nella directory <Partecipa.base_cvs_dir>/src/modules/Safe 3) Eseguire i comandi perl Makefile.PL; make test; make; make install 4) Copiare i seguenti files: <Partecipa.base_cvs_dir>/src/common/lib/functions/misc-utils.pl =3D> =20 <install_dir>/partecipa.base/lib/functions/misc-utils.pl <Partecipa.poll_cvs_dir>/src/pub/templates/admin_phpESP_sendEmailResult.temp= late =20 =3D> <install_dir>/partecipa.base/lib/servers/pub/templates/admin_phpESP_sendEmai= lResult.template <Partecipa.poll_cvs_dir>/src/pub/forms/admin_phpESP_sendEmail.form =3D> =20 <install_dir>/partecipa.base/lib/servers/pub/forms/admin_phpESP_sendEmail.fo= rm <Partecipa.poll_cvs_dir>/src/pub/cmds/admin_phpESP_sendSurveyEmail.uxu =20 =3D> =20 <install_dir>/partecipa.base/lib/servers/pub/cmds/admin_phpESP_sendSurveyEma= il.uxu |
|
From: <an...@na...> - 2007-05-25 12:54:55
|
Salve a tutti. Ho effettuato un aggiornamento del CVS in seguito ad alcuni bugfix, che elenco: 1) Pagina bianca in fase di registrazione iniziale: invece di apparire la pagina con i dettagli dell'utente, cliccando il link dalla webmail di Libero si arriva ad una pagina bianca: il bug era dovuto ad una mancata gestione di eccezioni. <install dir>/partecipa.base/lib/server/pub/cmds/modPersonaTotale.uxu NOTA: per quanto riguarda il problema del link spezzato nelle webmail di Alice e Libero, non era dovuto a particolari bug sul nostro codice: il bug stava nelle varie webmail che davano problemi, tant'e' vero che ora non e' stato piu' riportato: probabilmente gli autori di quei software di webmail hanno corretto il *loro* bug: infatti con ad esempio Google Mail non dava mai problemi. 2) Problemi col filtro delle localita: il filtro javascript che si attiva quando si attivano i radio button per selezionare Citta/Italia/Estero filtrava alcune localita nel caso fosse selezionata Italia; ho sistemato il codice che applica la regular expression sulla option list in modo che gestistca le regex negate, aggiunto l'opzione alla funzione filterlist.js e sistemate le form in modo da utilizzare correttamente la nuova sintassi. <install_dir>/partecipa.base/lib/servers/pub/forms/mod_persona_totale.form <install_dir>/partecipa.base/lib/servers/pub/forms/mod_persona_admin.form <install_dir>/partecipa.base/lib/servers/pub/forms/mod_persona_cerca_admin.f= orm <install dir>/partecipa.base/lib/servers/pub/forms/mod_persona_registra.form <document_root>/partecipa.base/javascript/filterlist.js In caso di upgrade di una versione gia' installata sara' sufficiente fare il checkout del cvs sul modulo partecipa.base e copiare i files nella directory di installazione, in quanto nessuno di questi files necessita della procedura di install per sostituire macro e/o valori dinamici quali directory di installazione o simili. N.B: nella directory ottenuta dal checkout cvs, i files sono in directory leggermente diverse, per cui l'operazione di sovrascrittura dei files in linea dovra' partire da punti diversi da quelli di installazione, ad esempio le forms in origine stanno in: <cvs_dir>/Partecipa.base/src/web-interfaces/pub/forms mentre nell'installazione sono in <install_dir>/partecipa.base/lib/servers/pub/forms in caso di problemi usare find o locate per individuare i files Purtroppo non posso allegare direttamente i files per via delle policy =20 sulle liste di sourceforge, comunque sono facilmente ricavabili in =20 base alle istruzioni qui sopra. |
|
From: Lucia M. <luc...@as...> - 2007-05-25 10:52:59
|
an...@na... wrote: > Salve a tutti. Ho effettuato un aggiornamento del CVS in seguito ad=20 (..omit...) Ciao Enrico, penso valga la pena di far circolare anche su users queste info dato che = coloro che aggiornano le installazioni sono l=EC. Peraltro lo zip non c'=E8, forse =E8 stato strippato automaticamente perc= h=E8=20 la lista non supporta gli allegati. Se possibile va allegato come solo=20 testo. ciao Lucia --=20 ASTER Scienza Tecnologia Impresa - S.Cons.p.a. Area della Ricerca di Bologna Via Gobetti 101 - I-40129 Bologna Tel +39 051 6398099 Fax +39 051 6398131 http://www.aster.it |
|
From: <an...@na...> - 2007-05-25 09:28:08
|
WARNING: This e-mail has been altered by MIMEDefang. Following this
paragraph are indications of the actual changes made. For more
information about your site's MIMEDefang policy, contact
MIMEDefang Administrator's Full Name <postmaster@localhost>. For more information about MIMEDefang, see:
http://www.roaringpenguin.com/mimedefang/enduser.php3
An attachment named ultime_modifiche_20070525.zip was removed from this document as it
constituted a security hazard. If you require this document, please contact
the sender and arrange an alternate means of receiving it.
|
|
From: Fiorenza B. <fio...@co...> - 2007-02-01 16:03:48
|
Vi mando la lista delle possibili implementazioni per il kit=20 Partecipa.net e di quelle gi=E0 in corso a Modena (ovviamente da=20 integrare/rivedere durante la riunione di luned=EC 5 febbraio). --=20 Dott.sa Ballabeni Fiorenza=20 Comune di Modena Rete Civica Mo-Net - Settore Cultura, Sport, Turismo, Marketing e Politic= he Giovanili Via Scudari 20 - 41100 Modena tel. 059 203.2992 fax 059 203.2612 e-mail: fio...@co... |
