Question migration et upgrade 1.9.7 vers 3.4.1e

Je suis en train de migrer mon serveur GRR1.9.7 vers un nouveau serveur GRR3.4.1e.
J'ai fait une exportation du vieux serveur (qui continue à fonctionner) vers le nouveau et je l'ai installé sur la nouvelle machine.
Cependant j'ai quelques petits détails à régler :

1. Par rapport à l'ancien serveur je ne disposerais plus de l'identification LDAP. Comment puis-je faire pour basculer les utilisateurs LDAP qui apparaissent comme extérieurs vers des utilisateurs locaux et leur assigner un mot de passe ?
2. Une fois le nouveau GRR en fonction, je voudrais le passer en production et par exemple ajouter les réservations qui ont été faites sur l'ancien serveur entre le backup initial et aujourd'hui. Y a-t-il un moyen de n'importer que les réservation faites depuis une certaine date?
3. Et dernière chose : il me semblait que l'on pouvait synchroniser GRR avec Google Calendar. Est-ce possible et comment ?

Merci d'avance,
Eic

Bonjour,
1. si vous avez accès à phpmyadmin sur votre nouveau serveur, vous pouvez modifier les valeurs dans la table grr_utilisateurs : remplacer la valeur du champ source qui est à ext pour les utilisateurs non locaux par la valeur local.
2. là aussi, vous pouvez le faire à l'économie avec phpmyadmin, sinon refaire une sauvegarde et la réimporter quand vous êtes prêt à passer en production. Il y aura plein d'erreurs sauf si vous effacez les réservations existantes.
3. dans le code de base, ce n'est pas implémenté. Il y a une option chez devome.com, mais je ne sais pas exactement quelles sont ses fonctionnalités. Contactez support@devome.com
Cordialement,
YN

Bonjour
Merci de votre réponse. J’ai des questions par rapport à ça :
1- je change le statut des utilisateurs externes en local mais qu’en est-il de leur mot de passe ?
2- j’ai comparé les code sql de la version 1 à la version 3 pour les réservations et les lignes sont plus longues en v1 qu’en v3. Il y a une colonne de plus. Si j’élimine cette colonne je n’aurais pas de problème ?
Merci

Bonjour
pour 1. effectivement il faudrait aussi gérer le mot de passe. Comme il est crypté dans la base, une (mauvaise du point de vue sécurité) solution est de traiter à la main un utilisateur puis de recopier avec phpmyadmin le résultat dans le champ de la table utilisateurs. Ou bien utiliser la fonction md5 pour crypter les mots de passe entrés en clair (essayer sur quelques comptes pour commencer).
Pour 2., pouvez-vous être plus précis pour désigner la requête que vous avez comparée ?
Cordialement
YN

En comparant la même ligne de grr_entry de la version 1.9.7 à la version 3.4.1e j'ai ça :
1.9.7 :INSERT INTO grr_entry values ('31561', '1556881200', '1556888400', '0', '0', '4', '2019-05-03 15:49:58', 'PIRES', '', 'PIRES', 'Chergui', 'M', 'Pires', '-', '-1', '@1@SPC@/1@@2@@/2@@11@@/11@@10@ICMPE@/10@', '0', '0');
3.4.1 : INSERT INTO grr_entry values ('31561', '1556881200', '1556888400', '0', '0', '4', '2019-05-03 15:49:58', 'PIRES', '', 'PIRES', 'Chergui', 'M', 'Pires', '-', '-1', '@1@SPC@/1@@2@@/2@@11@@/11@@10@ICMPE@/10@', '0', '0', '0', '0');
On voit qu'à la fin de la ligne il y a '0', '0', en plus sur la version 3.4.1 d'où ma question : est-ce que j'ajoute '0', '0', à mes entrées venant de la v1 pour les importer avec phpMyAdmin dans la v3 ?

Bonjour,
je dirais que, puisque ces champs ont une valeur par défaut, leur absence ne devrait pas poser de problème.
Mais je pense que le mieux est de partir de la sauvegarde de la 1.9.7, la convertir en utf-8 puis la restaurer et faire la mise à jour des tables quand GRR le demande et si le logiciel ne le demande pas, forcer la mise à jour (voir la documentation).
Bon courage,
cordialement,
YN

Bonjour,
Pour terminer le thread, j'ai ajouté '0', '0' à mes entrées de la v1 et ça a parfaitement fonctionné.
J'avais aussi des utilisateurs qui étaient identifiés avec un serveur LDAP donc marqués en externe. Avec phpMyAdmin, j'ai pu modifier le mode d'identification et leur assigner un mot de passe temporaire qui était leur login. Pour cela il faut taper une commande SQL qui met dans le champ password le MD5 de login