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.

permettre de mettre _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL à 0 pour que les liens envoyés par email restent valable à l'infini

si on est un utilisateur non connecté, pouvoir récupérer le fichier de la réponse qu'on a soit même posté, via le cookie

et maintenant le cas où on envoie la réponse, mais on l'enregistre pas. On en profite pour mutualiser du code

traitement email, cas simple: les réponses ont déjà été enregistrées. Dans ce cas, on se contente d'ajouter un lien, expirable, pour télécharger le fichier

- conventionnellement la boite raccourci sert a des liens, pas des boutons d'action de suppression
- on deplace le bouton de suppression en partie centrale, soumis aux conditions 1/que toutes les reponses sont affichees 2/ qu'il y a au moins 10 reponses a supprimer
- on le soumet a la bonne autorisation
- dans l'action on verifie l'autorisation
- dans l'action, le statut est refuse et pas poubelle
- on ne met pas un formulaire dans une boite dans une colonne

+ ajout du nombre de reponse de chaque statut dans les onglets, si non nul (mais pas sur l'onglet 'toutes')

Fix https://core.spip.net/issues/3617 : passer $set a objet_modifier_champs pour qu'elle ne detecte les conflits sur $_POST que quand c'est pertinent

suppression du echo devant $exporter_csv, qui rajoute le nom du fichier à la fin de l'export sur certains serveurs
incrémentation mineure de version

report de 81164

correction d'un bug dans la balise #FORMULAIRE_FORMIDABLE

Les actions supprimer ne font que mettre en statut poubelle/refuse, plus de risque de pertes de données à cause d'une action maladroite
on enleve le bouton "Supprimer" sur la page d'un formulaire

Lors de l'import f&t les formulaires sans réponses sont mis en statut proposé, les autres en publiés

squelette HTML du formulaire d'edition, declaration champs_editables et champs_versionnes dans l'API tables_objets_sql, nommage génériques et implémentation des fonctions de editer/formulaire (avec support des vieux nommages)
+ ajout d'une chaine de langue sur erreur de format
+ bugfix verification unicité de l'identifiant

Ajout d'une date de création du formulaire (nommée date_crea parce que date est un mot reservé mysql)
Incrémentation mineure de version et de shéma

possibilité d'exclure certains champ de l'analyse (utile notamment lorsque on des champs qui sont uniquement là pour conditionner l'affichage d'autres champs)

formulaires pour l'import et la duplication des formulaire.
Ajout par défaut de l'auteur courant comme auteur du formu-
laire dupliqué ou importé

* 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é

- déclarer 'spip_formulaires' en objet éditorial
- renommage des pages exec homogène avec le reste de SPIP : formulaires, formulaire  et formulaire_edit
- décoration des listes de formulaire aux nouvelles normes

Reste à gérer les réponses...

Petit inconvénient aussi, il fait du coup des urls propres pour les formulaires…