Migrations Arsia

1. Migration du LIMS 'local'

quand : du 14 au 16 mars

objectif : inconnu

à faire :

1. passer Cerise production en maintenance
2. réimporter toutes les tables du LIMS (via arsia.imports.ibrLims) pendant la journée du 16 mars, avant de faire d'autres migrations.

2. Migration Cerise

quand : le 16 mars

objectif : mettre le nouveau Cerise en production

à faire :

1. réimporter le Lims (cf 1.)
2. migrer les tables postgres :
   • pour vetoweb : importLimsVetes (importer les vété du Lims et faire la table de conversion Party - Sanvet_id)
   • pour vetoweb : importAssociations (recréer les associations existantes dans partage US)
   • pour bluetongue : migrateBluetongueDB (migration des tables --> party, sanitaryunits, etc)
3. activer les crons :
   • envois d'XML (chaque X minutes)
   • importLimsVetes (chaque jour)
   • updatePgCeriseDB (chaque jour)
4. forcer la langue en Français
5. réinstaller cerise.skin
6. enlever le user admin:admin !
7. remplir la page d'accueil
8. ordonner les portlets

3. Migration du LIMS 'serveur'

quand : le 23 mars

objectif : passer les numéros de troupeaux en numéros d'unités sanitaires

ATTENTION : on peut faire ce qu'on veut dans toutes les tables, sauf celles en rapport avec la compta (atsanperson et ataccount) et vetoweb (ibr_pa, ibr_rq, ibr_sc, san_vete, vetoweb_info, etc) car elles sont en production ! De plus, il faut faire gaffe de ne pas écraser et que les écrans ne rajoutent pas des infos (non migrées) dans les tables déjà migrées.

à faire :

1. réimporter le Lims - migrer les scripts foireux ET migrer les tables postgres correspondantes (type de colonnes - cf RequetesMigrationLims) :
   • IBR SC
   • IBR RQ
   • IBR PA
   • link vete (déprécié dans r5165)
   • san vete (déprécié dans r5165)
   • atsanperson (devrait être OK dans r5153)
   • ataccount (devrait être OK dans r5161)
2. réimporter les autres scripts :
   • vetoweb_info (voir s'il faut migrer les tables ou pas)
3. migrer le code :
   • pour vetoweb : ne plus utiliser la table veterinaire (mapper 'veterinaire')
   • OK c'est commité r5154 pour la compta : plus besoin de convertir les unités sanitaires en numéros de troupeaux (sanitaryUnitToTroupeau)
   • OK c'est commité r5155 pour vetoweb : plus besoin de convertir les unités sanitaires en numéros de troupeaux (getVeteSanitaryUnits)
   • pour ibr écrans et vérifications OK ça devrait être bon dans r5159 r5160 : utiliser la nouvelle vue sanitrace_bovins
   • pour ibr : migrer les PDF (unité sanitaire à la place de troupeau, donc décalage probable)
   • pour ibr : écran, checks et PDFS : utiliser les vétés et les détenteurs Oracle et plus postgres (déprécier link_vete_troupeau, san_vete, vetoweb_person et vetoweb_id_user)
   • régler l'import de sanitrace_bovins (4 derniers chiffres incorrects pour boucles étrangères)
4. OK les tables sont migrées sur Kriek IBR - migrer les tables postgres :
   • changer toutes les tables IBR --> numéro de troupeau + BE -0101 (cf ​http://trac.affinitic.be/trac/wiki/IBRmigration) et numéro de vétés / détenteurs --> numéros de party
5. OK c'est fait migrer les noms des PDFs sur le disque (script rename.sh cf #783)
   • /home/zope/arsia/bluetongue/pdf (ATTENTION, code différent car les nouveaux PDFs sont déjà dans le bon format et ne doivent plus être migrés !)
   • /home/zope/arsia/ibr/pdf/i2
   • /home/zope/arsia/ibr/pdf/i2d