| Version 34 (modified by laz, il y a 16 ans) (diff) |
|---|
Migrations Arsia
1. Migration du LIMS 'local'
quand : du 14 au 16 mars
objectif : inconnu
à faire :
- passer Cerise production en maintenance
- 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 :
- réimporter le Lims (cf 1.)
- 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)
- activer les crons :
- envois d'XML (chaque X minutes)
- importLimsVetes (chaque jour)
- updatePgCeriseDB (chaque jour)
- forcer la langue en Français
- réinstaller cerise.skin
- enlever le user admin:admin !
- remplir la page d'accueil
- 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 :
- 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)
- réimporter les autres scripts :
- vetoweb_info (voir s'il faut migrer les tables ou pas)
- 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
- migrer les tables postgres :
- OK les tables sont migrées sur Kriek 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
- migrer les noms des PDFs sur le disque (script rename.sh cf #783 - ticket pour Jef : #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
