09-09-2016, 22:20
Bonjour.
Si je comprends bien, vous bloquez actuellement pour passer de votre '1.3 alpha' à une 1.3.8 (si c'est bien le cas, il aurait peut-être fallut créer un autre thread plus approprié).
Dans l'absolu il faut aussi prendre le répertoire media/upload (si vous avez des entités Documents et Images surtout) ; pour le passage en 1.6 ça devrait passer sans ça, mais dans le futur il se pourrait que les fichiers uploadés soit modifiés (renommés/déplacés), notamment lorsque la fusion des Images et Documents sera faite.
Lorsque des ContentTypes sont devenus inutiles dans le code et que syncdb/migrate vous proposent de nettoyer la base, répondre 'no' ne peut en aucun cas être la source de bug (il reste juste des lignes inutiles en base) ; le pire qu va arriver c'est qu'on vous demandera à nouveau si vous voulez nettoyer la base la prochaine fois qu'une des 2 commandes est lancée (au prochain upgrade par exemple dans votre cas).
Si vous avez effectué toutes les migrations, répondre 'yes' devrait aussi fonctionner à moins évidemment d'un bug dans nos migrations. En général nous essayons de nettoyer nous-mêmes la base afin que ces messages n'apparaissent pas mais il se peut que nous en ayons oubliés.
Pour le moment je vous propose que vous répondiez 'no' pour ne pas prendre de risque ; le nettoyage pourra toujours être fait plus tard.
Bon, voilà la vraie source des problèmes semble se trouver ici. Notez qu'à partir du moment où vous n'avez pas effectué toutes les migrations, ce n'est pas vraiment la peine de continuer vu que la base de données est dans un état non finalisé ; il n'est pas étonnant que l'application plante par la suite.
Alors en effet vous êtes tombé sur un bug ; le vieux modèle 'Appel téléphonique' (Creme1.2 ou moins) autorisait à ne pas mettre de type d'appel (ce qui était sûrement une mauvaise idée, mais bref), mais la migration ne prend pas en compte ce cas où il n'y a pas de type d'appel, et plante lorsqu'un tel appel existe en base.
Solutions possibles :
Bon courage pour la suite !
Si je comprends bien, vous bloquez actuellement pour passer de votre '1.3 alpha' à une 1.3.8 (si c'est bien le cas, il aurait peut-être fallut créer un autre thread plus approprié).
Citation :J’ai effectué un « mysqldump » de la base de données associée avec crêmeCRM en service ...
Dans l'absolu il faut aussi prendre le répertoire media/upload (si vous avez des entités Documents et Images surtout) ; pour le passage en 1.6 ça devrait passer sans ça, mais dans le futur il se pourrait que les fichiers uploadés soit modifiés (renommés/déplacés), notamment lorsque la fusion des Images et Documents sera faite.
Citation :J’ai essayé avec « yes » et « no » chaque fois avec une nouvelle installation sans succès.
Lorsque des ContentTypes sont devenus inutiles dans le code et que syncdb/migrate vous proposent de nettoyer la base, répondre 'no' ne peut en aucun cas être la source de bug (il reste juste des lignes inutiles en base) ; le pire qu va arriver c'est qu'on vous demandera à nouveau si vous voulez nettoyer la base la prochaine fois qu'une des 2 commandes est lancée (au prochain upgrade par exemple dans votre cas).
Si vous avez effectué toutes les migrations, répondre 'yes' devrait aussi fonctionner à moins évidemment d'un bug dans nos migrations. En général nous essayons de nettoyer nous-mêmes la base afin que ces messages n'apparaissent pas mais il se peut que nous en ayons oubliés.
Pour le moment je vous propose que vous répondiez 'no' pour ne pas prendre de risque ; le nettoyage pourra toujours être fait plus tard.
Citation :Avec la réponse « no », le message d'erreur à la fin du »TraceBack » est ...
Bon, voilà la vraie source des problèmes semble se trouver ici. Notez qu'à partir du moment où vous n'avez pas effectué toutes les migrations, ce n'est pas vraiment la peine de continuer vu que la base de données est dans un état non finalisé ; il n'est pas étonnant que l'application plante par la suite.
Alors en effet vous êtes tombé sur un bug ; le vieux modèle 'Appel téléphonique' (Creme1.2 ou moins) autorisait à ne pas mettre de type d'appel (ce qui était sûrement une mauvaise idée, mais bref), mais la migration ne prend pas en compte ce cas où il n'y a pas de type d'appel, et plante lorsqu'un tel appel existe en base.
Solutions possibles :
- Mettre un type d'appel (Entrant/sortant/autre) à tous les Appels téléphoniques qui n'en ont pas (si vous le faites directement en SQL, et pas via Creme, il s'agit de la table 'activities_phonecall', colonne 'call_type_id').
- Corriger le fichier de migration creme/activities/migrations/0005_v1_3__migrate_n_clean_old_activities_n_related.py ; ligne 82, dans la fonction 'process_phone_call ', il faut gérer le cas où 'old_id' vaut 'None'.
Bon courage pour la suite !