ne pas proposer de ne pas stocker l'id_auteur si jamais on utilise l'id_auteur pour identifier une réponse et qu'en plus on a besoin d'identifer une réponse

en r112879 je disais "compatibilité assuré pour les gens qui auraient modifié les variables globales". C'était faux. Maintenant c'est vrai

Etape 5 : avoir une fonction qui trouve la réponse d'une personne à un formulaire tenant compte du choix principal d'identification des réponses

dire supprimer l'id_auteur

éviter de mettre une définition  dans un options, lorsque la valeur n'est utilisé que dans une fonction. Autant définir dans ce cas dans la fonction

- code plus clair en évitant de créer des variables juste pour inverser le résultat d'un test, et pour recopier la valeur d'une variable sans la modifier après (!)
- plus de variables globales pour modifier un réglage (qui de toute facon
aurait du passer plutot par un pipeline dédiée)
- limiter les cas d'appel a eval()

Compatibilité assuré pour les quelques personnes qui auraient modifiés
ces variables globales (mais qui?)

- suppression d'un code mort sur test de valeur brute ou pas brute,
puisque par défaut renvoyait les deux, le test avait lieu en amont
- pour déterminer la valeur humaine, on se base désormais sur
saisie-vues/xxx, ce qui assure d'avoir une valeur humaine aussi lorsque
c'est prévu mais qu'il n'y a pas d'argument datas à la saisie,
typiquement pour les saisies de type evenements (plugin agenda)

refactorisation du code : une seule fonction pour trouver la réponse qui doit être modifié si on autorise la modification des réponses
Pour le moment appeller:
  - lors du chargement du formulaire
  - lors de l'enregistrement des réponses

On modifie pour que l’export de base, sépare la génération du fichier de l’envoi au navigateur.
Une commande SPIP-Cli prend en premier argument l’identifiant numérique ou textuel du formulaire. Une option pour le format csv ou xls.

```
spip formidable:exporter:formulaire super-petition
spip formidable:exporter:formulaire 2 --format=xls
```

Cette commande génère l’export (dans tmp/cache/export) au format csv ou xls, et zip s’il y a des fichiers dans les réponses.
On affiche, si réussite, le chemin physique généré, et également un lien de téléchargement qui peut être donné à une personne.
Cette personne doit être connectée à SPIP, avoir les droits de lecture pour ces réponses de formulaire.
Le lien d’action (un peu long) n’est valide que pour 1 contenu de fichier donné.

Note: le nommage de la commande pourrait évoluer si quelqu’un·e à mieux.

On mutualise le code (ce qui en plus rend plus lisible la fonction de
traitement des emails)

lisibilite du code : ne pas reaffecter fichier mais utiliser un nom different pour la destination + remplir le tableau avec le meme index que das la source

possibilité d'avoir des PJ directement encloses dans le mail : constante + case à cocher + chaîne de langue

les constantes qui donnent le chemin des fichiers peuvent être utilisées par certain·e·s dans des squelettes->on les passe dans le fichier d'options

Version 3.2.5

Si on ne veut pas que le contenu de ces répertoires soient lisibles, autant s'en préoccuper nous même avec un htaccess

Version 3.2.4

réception
pour se faire définir _FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION à
false

r101463 avait gardé par copier-coller un continue non pertinent. Cela ne posait pas de problème en PHP 5, mais par contre est fatal en PHP 7

d'une réponse non enregistrée