ETQ Instructeur, je veux que les pièces jointes lourdes conservent leur nom + extension lors du téléchargement

[LeSim]

hs #9253

description du problème

Étapes pour reproduire

• etq usager, uploader un fichier avec le nom tableau.csv sur un champ pièce justificative (lourde).
• etq accompagnateur, télécharger ce fichier

résultat attendu :

téléchargement d'un fichier nommé tableau.csv

résultat constaté :

téléchargement du même fichier mais avec un nom aléatoire (sdfhsdj23424).

solution

Passer les champs pièces jointes sous OVH

Tâches

• Supprimer l’override de PieceJustificativeUploader#origianl_filename pour pouvoir mettre à jour Carrierwave
• Mettre à jour Carrierwave afin de pouvoir se passer de la gemme chapeau fog
• Ajouter dans ansible les données de configuration compatibles keystone v3 (2 nouvelles clefs : url version-agnostique et version d’api d’authent à utiliser)
• Déployer la configuration ansible avec les nouvelles données de configuration
• Enlever fog pour pouvoir mettre à jour fog-openstack vers la dernière version
• Mettre à jour fog-openstack. Mettre à jour les fichiers de configuration pour utiliser les données d’authentification compatibles keystone v3
• Faire la non-régression de Carrierwave
• Mettre en production DS avec la nouvelle version de fog-openstack
• Supprimer dans la configuration ansible l’ancienne URL d’authentification qui incluait le numéro de version
• Déployer la configuration ansible sans les anciennes données de configuration
• Ajouter activestorage-openstack (version patchée pour corriger la dépendance sur une mauvaise version de fog-openstack)
• Choisir ou créer un conteneur sur openstack pour les pj : ds_activestorage
• Cofigurer la temp url key sur le conteneur
• Configurer CORS sur le conteneur swift post -m "Access-Control-Allow-Origin: https://www.demarches-simplifiees.fr" ds_activestorage
• Configurer la temp URL key sur ansible de prod
• Déployer la config ansible de prod avec la temp url key
• Avertir les administrateurs de l’incohérence temporaire sur les pièces joints
• Configurer activestorage de prod pour utiliser OVH
• Purger les données de test du conteneur sur OVH, recopier les pièces jointes de CleverCloud vers OVH
• Rectifier les types MIME sur OVH
• Mettre en prod DS avec OVH comme fournisseur activestorage
• Refaire la copie CleverCloud -> OVH pour les pièces jointes qui ont été rajoutées entre temps
• Refaire la rectification des types MIME
• Vérifier s’il reste d’autres fichiers hébergés sur CleverCloud (feuille de style helpscout etc), les déplacer vers OVH
• Décomissionner CleverCloud
• Passer les champs pièce jointe en generally available
• Exposer les champs PJ comme les anciennes PJs sur l’API
• Interdire la création d’anciennes PJs
• Afficher le nombre de PJ migrées
• Migrer les anciennes PJs vers les champs PJ
  • Vérifier que les PJs sont marquées comme analysées par l'anti-virus
  • Migrer une unique démarche de prod, et vérifier que ça se passe bien
  • Faire des stats sur le temps de migration
  • Écrire une tâche pour migrer toutes les démarches
  • Lancer la tâche dans un screen
• Supprimer le code de support des anciennes PJs
• Migrer les autres utilisations de Carrierwave (logos) vers Activestorag
• Décommissionner Carrierwave

[LeSim]

Semble être du à l'interraction entre Active Storage (version Cellar) et Riak cs qui ne comprend pas les query parameters content-disposition

[kemenaran]

@tchak est-ce qu'on a du progrès sur cette issue ? Des choses encore à faire, ou on peut décommissionner ?

[tchak]

Je pense que c'est fait

[kemenaran]

Donc à priori on n'a plus qu'à décommissionner CarrierWave :

• Supprimer le code lié à CarrierWave
• Supprimer les fichiers sur le bucket
• Supprimer la facturation CarrierWave

[kemenaran]

Les dernières étapes sont déportées dans #4533

Fin de l'issue de l'angoisse ! \o/