- si une personne reprend une veille session alors qu'il y a une modif
en base des champs de formulaire, la veille session est annulée
(correction faite au niveau du plugin saisies
saisies@673fcfac)
- si une personne modifie les saisies et qu'entre le moment où il
commence sa modification et le moment où il valide l'ensemble des
modifs, une tierce personne a modifié en base :
  - on met un message d'erreur
  - on demande de recommencer les modifs, à partir de ce qu'il y a en
  base

Ricardo Porto a rédigé il y a 5 ans et salvatore a validé il y a 5 ans

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

oups, dans la config d'un traitement, une case décochée a bien une valeur enregistré en base (''), donc faut modifier le test

[Salvatore] [source:lang/ paquet-formidable] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source:lang/ formulaires_reponse] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source:lang/ formulaire] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source: paquet-formidable] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source: formulaires_reponse] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source: formulaire] Mise a jour du bilan depuis https://trad.spip.net

[Salvatore] [source: formidable] Mise a jour du bilan depuis https://trad.spip.net

effacer TOUT les anciens résultats, et pas uniquement pour les champs
qui viennent d'être postés.
En effet, les nouvelles valeurs peuvent conditionner le non-affichage
d'un champ pour laquelle une valeur avait été enregistrée avant. Dans ce
cas il faut aussi effacer cette valeur.
Exemple
- Le formulaire est configuré de sorte que si la case_1 est cochée, alors afficher le champ input_1.
- Premier enregistrement de la réponse : case_1 cochée, champ input_1
valant 'toto'
- Modification de la réponse : case_1 décochée.
  - Avant ce commit, la valeur 'toto' restait associée à case_1 en base,
  faussant tableau d'analyse et autre
  - après ce commit, ce n'est plus le cas

SPIP 3.0 n'est plus supporté. On passe donc en compat spip 3.1 minimum , ce qui permet d'utiliser recuperer_url, de faire une requete HEAD plutot que GET, pour vérifier que le fichier est inaccessible

nouveau raccourci pour le message de l'accusé de réception : @message_retour@. Permet de prendre le message standard de retour de formulaire puis de le compléter

Plus de séparation entre les traitements à choisir et leur configuration, moins de marges inutiles, plus d'espace.

charger() et pas à la fin de traiter(), sinon on ne peut pas accéder a
leurs valeurs dans le pipeline formulaire_traiter()

c1baaee2 était un peu trop fort. En effet, si jamais on a un identification par id_auteur sans anonymisation, alors la variable PHP peut être pertinente

Amélioration de l'anonymisation dans le cadre une d'identification par identifiant de la personne identifiée. Modification légère de la base.

Possibilité d'utiliser une méthode d'identification par l'identifiant de la personne identifiée tout en anonymisant les réponses.

Inversons la logique actuelle…

Le span passe en absolute et on passe le texte en relative. Ca permet d'avoir la même baseline du texte entre le label et le texte dans la barre (ex: 67% - 8 réponses). Accessoirement ca permet de modifier la taille du texte effet de débord (suppression de la hauteur en px de .progress-bar).

Eclaircir le gris, trop foncé pour y mettre du texte par dessus.

En attendant html5 qui a sa propre balise <progress>