Transfert GRR sur un nouveau serveur et migration de 1.9.7e en 3.4.0

olivierardouin écrit: Je pense avoir trouvé un palliatif:

en cherchant une ancien version j'ai à tout hasard téléchargé celle-ci:

github.com/mtalmont/grr.git
qui est une 3.7 ? je n'ai pas regardé dans les détails mais c'est peut-être un fork.

oui, c'est une branche qui évolue indépendamment de la nôtre...

quoiqu'il en soit :

installation de cette version sur une base mysql vide. Création de la base du GRR (vide). connexion, mise à jour, --> OK

Conservation de la base mysql

Installation des fichiers de la v 3.4.0, mise à jour "forcée" de la base de donnée ---> j'ai accès même si certain champs de présentation (Mairie de Thalmont St Hilaire) ne sont pas à jour.

Ce n'est pas super satisfaisant comme migration car vu que certains champs ne sont pas passés, j'ai un doute sur ceux non vérifiés.

Y à t'il des anciennes version 2 stable qui seraient téléchargeables pour faire une étape ?

Il n'est pas utile de faire des étapes intermédiaires, le script de mise à jour devrait faire le job.
Avez-vous réessayé de modifier le numéro de version dans la base ?
Puis faire une mise à jour forcée ?
J'ai mis la documentation à jour sur ce point sur le dépôt Github
github.com/JeromeDevome/GRR/commit/51deb...1ecd6a9d060207179b05
Si ça ne convient toujours pas, merci de rapporter vos problèmes afin de mettre au point la procédure de mise à jour.
Cordialement,
YN
P.S. comme ça me turlupinait, j'ai refait la démarche :
installation d'une 340
restauration d'une sauvegarde 198
il faut alors ouvrir une nouvelle session (avec un compte administrateur local de mot de passe connu dans l'ancien GRR si on veut que ça marche)
GRR indique alors qu'il y a lieu de faire une mise à jour
la mise à jour se passe (bien dans mon cas )
je peux alors accéder à GRR par la page monGRR/login.php ou une page de planning, ou autre, et même la page index, qui fait le plus de vérifications, passe en renvoyant sur le planning par défaut (dans mon cas : monGRR/ --> monGRR/day.php)

Effectivement là cela fonctionne.

Je résume la manip pour ceux qui seraient dans le même cas de figure:

1 - génération d'un dump (sauvegarde) à partir de l'interface web du serveur "original" en 1.9.6 ---> fichier .sql

2- installation sur le nouveau serveur de la version 3.4.0

3- Modification du fichier GRR/include/connect.inc.php
(surtout si la base de données vide est déjà crée) et bien reprendre la valeur $table_prefix pour coller à celle du dump.

4- Se connecter au nouveau serveur et choisir "installer une nouvelle base" et entrer les valeurs en accord avec la base mysql utilisée.

5- se connecter au nouveau GRR "vierge" et restaurer le dump généré en 1

6- forcer la mise à jour de la base :
http://mon_site.fr/GRR/admin/admin_maj.php?force_maj=
entrer le login et password d'un administrateur de l'ancien site

7- dans un mysql (ou phpmyadmin mais je ne connais pas)
vérifier la version de la base dans la table préfix_setting

select value from prefix_setting where name = 'version';"

si encore à 1.9.6 changer cette valeur:

update prefix_setting set value = '3.4.0' where name = 'version';

8- se connecter au GRR sur le nouveau serveur et ça marche (dans mon cas en tout cas il a fallut en passer par là)

il faut encore changer les propriétés d'affichage dans les settings et un peu plus gênant reprendre l'ensemble des champs avec des caractères accentués qui sont tous remplacé par des "?" mais à part ces détails, c'est ok.

Merci

Bonjour,
merci pour votre retour d'expérience, de plus cette fois positif ! Votre message pourra servir de référence.
Je regarde pourquoi la mise à jour forcée n'a pas mis à jour le numéro de version.
Quant aux accents, j'ai eu le même problème lors de mes tests. Là aussi, il faudrait creuser parce que pour l'instant la base de données est toujours codée en latin1.
Cordialement,
YN