- avr. 15, 2015
-
-
kent1@arscenic.info a rédigé
Remonter le message de retour du formulaire pour que les traitements puissent l'utiliser, le modifier par exemple
-
kent1@arscenic.info a rédigé
-
- oct. 11, 2014
-
-
marcimat@rezo.net a rédigé
-
- juil. 24, 2014
-
-
camille.sauvage@espci.fr a rédigé
Controle du numero d'id_reponse en base Mise à jour du champ maj dans la table spip_formulaires_reponses Vérification de l'id_auteur lorsqu'un id_formulaires_reponses est fourni pour éviter qu'un auteur modofie les réponses d'un autre
-
- juil. 17, 2014
-
- mai 07, 2014
-
-
cedric@yterium.com a rédigé
On reduit les risques de sortie anormale de traiter() sans message d'erreur, et on log $_POST dans un post-mortem pour retrouver la trace du problème a posteriori et recouvrer eventuellement les donnees (on préfere utiliser json_encode qui ne cassera pas lors du decode malgré l'échappement des < par spip_log)
-
- mars 24, 2014
-
- mars 13, 2014
-
-
cedric@yterium.com a rédigé
Statut archive (refuse) pour les formulaires : ils ne sont plus visibles en ligne mais on conserve le contenu et les reponses + la balise #FORMIDABLE n'affiche que les formulaires publies (ou prop en preview) dans le site public
-
- fév. 26, 2014
-
-
cedric@yterium.com a rédigé
- les traitements doivent noter qu'ils ont bien ete executes dans ['traitements'] pour ne pas etre executes plusieurs fois - un traitement qui veut/doit passer apres un autre peut ne rien faire et rendre la main au premier tour pour laisser l'autre se faire - on refait la boucle 5 fois au maximum pour executer tous les traitements - si des traitements n'ont pas pu etre executes, on declenche un mail au webmestre avec l'erreur et un dump de dans le mail pour ne pas perdre de donnees - si aucun traitement n'a ete execute (defaut de configuration?) on declenche un mail au webmestre et un dump de dans le mail pour ne pas perdre de donnees Cette modification entraine une petite incompatibilite sur les traitements perso : ceux-ci seront executes 5 fois et une erreur sera generee si ils ne sont pas modifies pour renseigner ['traitements']
-
- fév. 17, 2014
-
-
cedric@yterium.com a rédigé
le $where ne sert que dans la requete juste dessous, on l'y intègre pour faciliter la relecture des requetes SQL
-
camille.sauvage@espci.fr a rédigé
correction d'un bug dans l'utilisation de la balise #FORMULAIRE_FORMIDABLE
-
- fév. 14, 2014
-
-
cedric@yterium.com a rédigé
Securite : toujours utiliser l'id passé en argument de #FORMULAIRE_FORMIDABLE et non celui qui est posté et a pu etre corrompu. On centralise la conversion de l'id en id_formulaire Extensibilite : fournir id_formulaire et id_formulaires_reponse si possible en sortie de la fonction traiter (pour les pipelines)
-
- fév. 10, 2014
-
-
cedric@yterium.com a rédigé
-
- jan. 31, 2014
-
-
rastapopoulos@spip.org a rédigé
Correction rapide des valeurs par défaut, lors du chargement, on insère les options "defaut" en tant que valeurs du charger() comme le fait d'ailleurs Saisies dans son API. Le mieux serait évidemment d'utiliser les "nouveautés" (plus tant que ça) de Saisies dans Formidable. Cela devrait corriger toutes ces saisies "selection" ou "oui_non" qui n'affichaient pas les bonnes valeurs par défaut.
-
- jan. 09, 2014
-
-
camille.sauvage@espci.fr a rédigé
Rectification de l'évaluation des options du formumlaire pour vérifier si un formulaire est modifiable à réponse unique et retrouver la réponse en cas d'anonymisation. Je ne comprends pas comment ça pouvait marcher avant...
-
- sept. 21, 2013
-
-
maieul@maieul.net a rédigé
comme le fait remarquer cedric, il n'est pas très poli de ne mettre aucun message après la validation d'un formulaire. Mettons un message par défaut à l'enregistrement en bdd.
-
- avr. 05, 2013
-
-
camille.sauvage@espci.fr a rédigé
pas garder de traces des utilisateurs ayant répondu (tout en gardant la possibilité d'avoir des réponses uniques, modifiables
-
- avr. 04, 2013
-
-
camille.sauvage@espci.fr a rédigé
-
camille.sauvage@espci.fr a rédigé
* traitement de l'anonymisation. Elle permet de créer des formulaires dont les réponses sont anonymes (pas d'adresse IP, pas de nom de cookie, pas de login) * export de l'analyse des données en en CSV depuis l'Espace Privé
-
- oct. 12, 2012
-
-
rastapopoulos@spip.org a rédigé
-
- sept. 20, 2012
-
- sept. 06, 2012
-
-
marcimat@rezo.net a rédigé
On permet de choisir l'affichage des statistiques de réponses après la saisie d'un formulaire (et si on a déjà rempli le formulaire et qu'on peut pas resaisir). On permet de configurer la classe css appliquée sur le modèle des barres de progression des statistiques.
-
marcimat@rezo.net a rédigé
On décore d'un graphisme les analyses des réponses de formulaire en mettant des barres de progression et des pourcentages. Le code provient du module de sondage qu'on va intégrer directement dans formidable en créant un nouveau type de retour.
-
- sept. 05, 2012
-
-
marcimat@rezo.net a rédigé
On complète très légèrement formidable pour préparer un petit module de sondage dans un plugin séparé : - Dans le chargement du formulaire formidable, on transmet la ligne SQL du formulaire (ça évite de refaire une requête pour les modules se branchant dessus) - Dans la construction des analyses de réponses, on indique dans l'attribut data-nombre le nombre total de réponse (ça permet de faire des pourcentages en jquery)
-
marcimat@rezo.net a rédigé
Notices PHP lors de l'utilisation de Formidable. Ajout d'un filtre pour désérialiser si possible sans générer d'erreur
-
- jan. 22, 2012
-