= 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.


[[BR]]


== 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


[[BR]]

== 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