mise à jour depuis ubuntu 14.04 et GT 2.15.1

[pierreloicq]

Bonjour,

Je dois mettre à jour un GT-admin 2.15.1 installé sur un ubuntu 14.04. Pour commencer, je voudrais l'amener sur un ubuntu 18.04.
Je soumets ici ma méthode. Si jamais quelqu'un pense que ça ne marchera pas, cela m'intéresse.

Le support pour ubuntu 14.04 a été abandonné sur la 2.30.0 et la doc de notre version actuelle (2.15.1) ne mentionne pas de compatibilité avec ubuntu 18. Je dois donc passer par une version compatible avec ubuntu 14 et 18: la 2.29.15

1) sur l'ubuntu 14, passer de 2.15.1 à 2.29.15 avec la méthode "Software update" de la 2.29.15. J'ai un doute s'il ne faut pas encore une étape supplémentaire car il est écrit :

WARNING: Intermediate versions are required to upgrade your instance. If your version is < 2.13.1, you need to install this version. If your version is < 2.16.3, you need to install this version

mais le "this" ne comporte pas de lien et on s'attend à ce que this ne désigne pas la 2.29.15 sinon la ligne ne serait pas dupliquée...

2) sur la machine ubuntu 18, appliquer la méthode "server migration" de la 2.29.15, qui inclut le transfert de la BDD 2) faire en sorte que le logiciel fonctionne. 3) appliquer la section "Upgrade from Geotrek-admin <= 2.32" du manuel actuel

Qu'en pensez-vous ? Merci

[gutard]

C'est bien ça l'idée. Le this fait référence à la version qui est citée à gauche dans la phrase. Il vous faut donc faire une double mise à jour, d'abord vers la 2.16.3, puis vers la 2.29.15. Il est possible de faire le transfert entre serveurs et la mise à jour 2.16.3 -> 2.29.15 en même temps. Ça sera plus rapide. Mais en cas de souci ça sera plus compliqué à déboguer. En tout cas, à chaque étape il faut s'assurer un minimum que Geotrek fonctionne toujours correctement.

[pierreloicq]

d'acc, merci beaucoup

[numahell]

Je complète la réponse de Gael : il est possible qu'il y ait des problèmes à la mise à jour vers 2.29.15 à cause de paquets python qui ne sont plus compatibles avec python 2. Pour cela il faut fixer la version de ces paquet dans le fichier conf/buildout.cfg.

Au cas où, j'ai fait une branche avec ces modifications, en attendant de faire une version 2.29.16 : https://github.com/GeotrekCE/Geotrek-admin/commit/93eb3be269fccc590c1a8b4a4f1a4908e19da355

[camillemonchicourt]

C'est vrai que dans ton cas, il y a pas mal de retard au niveau de la version de Geotrek-admin, mais aussi au niveau de la version de l'OS, donc ça commence à être compliqué à mettre à jour. Au niveau de Geotrek-admin lui-même mais surtout de ses dépendances que l'on ne maîtrise pas.

C'est moins le cas depuis la révision complète de la méthode d'installation et mise à jour de Geotrek-admin depuis la version 2.33.0 et la mise en place d'un paquet Debian qui fixe les versions des dépendances.

Cependant là il faut passer la marche pour passer à ce nouveau mode d'installation. Et pour cela il faut un Geotrek-admin fonctionnel sur un Ubuntu en version 18...

Dans tous les cas, c'est important de bien faire des grosses sauvegardes, et idéalement des snapshots pour revenir en arrière. Et si possible, bien tester tout ça sur un serveur de test/pre-prod avant car là il y a beaucoup de retard à rattraper.

[pierreloicq]

Bonjour et merci pour vos réponses.

En fait notre GT-admin actuel ne marche pas bien. Quand j'essaie de mettre à jour un simple champ d'un itinéraire, ça fini en timeout, et quand j'essaie d'ajouter un tronçon, en geojson ou kml WGS84 (SRID 4326 à priori), celui-ci se positionne correctement sur la carte mais quand je clique sur créer j'obtiens un "Internal Server Error".

ERROR 2020-09-18 12:10:57,927 django.contrib.gis Error creating geometry from value '""' (String or unicode input unrecognized as WKT EWKT, and HEXEWKB.) ERROR 2020-09-18 12:10:57,934 django.request Internal Server Error: /path/add/

Le début du fichier geojson:

{ "type": "FeatureCollection", "name": "partOfcA", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }, "features": [ { "type": "Feature", "properties": { "Name": "Track 0", "description": "Exported from DDAAXX TCX Converter", "timestamp": null, "begin": null, "end": null, "altitudeMode": null, "tessellate": -1, "extrude": 0, "visibility": -1, "drawOrder": null, "icon": null }, "geometry": { "type": "LineString", "coordinates": [ [ 7.084413, 45.515508, 2300.0 ], [ 7.084571, 45.515471, 2300.0 ], [ 7.08471, 45.515436, 2300.0 ], [ 7.084861, 45.515408, 2298.0 ], [ 7.085011, 45.515406, 2295.351187301590016 ], [ 7.085123, 45.515354, 2293.0 ], [ 7.085142, 45.515261, 2292.0 ], [ 7.085174, 45.515166, 2290.0 ], [ 7.085271, 45.515096, 2289.0 ], [ 7.085414, 45.515055, 2289.0 ], [ 7.085551, 45.515109, 2291.0 ], [ 7.085679, 45.515167, 2291.0 ], [ 7.085809, 45.515223, 2291.0 ], [ 7.085942, 45.515267, 2290.0 ], [ 7.086011, 45.515345, 2289.6130048 ], [ 7.086148, 45.515399, 2289.0 ], [ 7.086292, 45.51546, 2288.0 ], [ 7.086436, 45.515512, 2288.0 ], [ 7.086553, 45.51557, 2288.41141121902001 ], [ 7.086622, 45.515647, 2288.0 ], [ 7.086678, 45.515732, 2287.0 ], [ 7.086748, 45.51583, 2286.0 ],

Devrais-je corriger ces bugs avant de mettre à jour, ou à l'inverse il risquent d'être corrigés par la MAJ ? Merci Pierre

[gutard]

Quand j'essaie de mettre à jour un simple champ d'un itinéraire, ça fini en timeout

Sur un très long itinéraire (> 50 km) ou peut-être avec une machine peu puissante, c'est possible. Ceci a été réglé dans les dernières versions.

et quand j'essaie d'ajouter un tronçon, en geojson ou kml

Je ne comprends pas très bien la manipulation effectuée. Depuis l'interface, il n'est pas possible d'ajouter un tronçon à partir d'un fichier. Le bouton qui permet de télécharger une trace permet juste de l'afficher sur la carte comme un guide pour dessiner le tronçon à la main. Là j'ai l'impression que vous ajoutez un itinéraire dont la géométrie n'est pas définie, d'où le plantage.

[pierreloicq]

Ha oui en effet je pensais que la géométrie chargée formait le tronçon. Ca marche si je dessine quelque chose. Merci

[gutard]

OK, par contre ça ne devrait pas crasher avec "Internal server error". Si j'essaie ça m'affiche proprement un message "le formulaire contient des erreurs" et "Valeur géométrique non valide"

[pierreloicq]

même dans mes vieilles versions ? Ca m'inquiète moins vu que j'ai quand même un message explicite dans le log, avec des erreurs python derrière

[gutard]

Je ne vois pas ce qu'il y a de très inquiétant. On enregistre un tronçon sans le dessiner et on a un message dans les logs qui indique qu'il n'arrive pas a construire un géométrie à partir de rien. C'est plutôt cohérent. La seule chose qui est curieuse c'est que la validation devrait intervenir en amont et afficher un message d'erreur. Si vous cliquez sur "Ajouter un tronçon" puis immédiatement sur "Créer" sans rien faire d'autre entre temps avez-vous un plantage ? Si non, quelle est la succession d'opérations à effectuer pour reproduire systématiquement ce plantage ? Cette information nous permettrait d'essayer de reproduire le même scénario et d'essayer de le comprendre.

[pierreloicq]

Si vous cliquez sur "Ajouter un tronçon" puis immédiatement sur "Créer" sans rien faire d'autre entre temps avez-vous un plantage ?

oui, pareil : Internal Server Error

[gutard]

OK. Je n'avais pas réalisé à quel point votre version actuelle est ancienne. Depuis on a corrigé des centaines de bugs. Donc aller chercher à comprendre pourquoi ci ou ça ne fonctionne pas sur cette vieille version est une perte de temps. Il faut absolument faire la mise à jour. Attention à bien sauvegarder la base de données à chaque étape.

[pierreloicq]

Bonjour,

J'ai un problème avec celery Si je mets dans buildout.cfg: celery = 4.2.0 django-celery-results = 1.0.1

Version and requirements information containing celery: [versions] constraint on celery: 4.2.0 Requirement of geotrek: django-celery Requirement of django-celery: django>=1.8 Requirement of django-celery: celery<4.0,>=3.1.15 While: Installing django. Error: The requirement ('celery<4.0,>=3.1.15') is not allowed by your [versions] constraint (4.2.0)

Si je mets: celery = 3.1.23 django-celery-results = 1.0.1

Installing omelette. Getting distribution for 'django-celery-results==1.0.1'. Got django-celery-results 1.0.1. Version and requirements information containing celery: [versions] constraint on celery: 3.1.23 Base installation request: 'mapentity', 'celery[redis]', 'django-celery-results' Requirement of django-celery-results==1.0.1: celery<5.0,>=4.0 Requirement of celery[redis]==3.1.23: redis>=2.8.0 Requirement of celery[redis]==3.1.23: pytz>dev Requirement of celery[redis]==3.1.23: kombu<3.1,>=3.0.34 Requirement of celery[redis]==3.1.23: billiard<3.4,>=3.3.0.23 While: Installing omelette. Error: The requirement ('celery<5.0,>=4.0') is not allowed by your [versions] constraint (3.1.23)

Et si je ne précise pas de version

Error: There is a version conflict. We already have: celery 3.1.26.post2 but django-celery-results 1.2.1 requires 'celery<5.0,>=4.4'.

une idée ? Merci Pierre

[gutard]

Commençons par le début : pourquoi souhaites-tu changer la version de celery et sur quelle version de Geotrek essaies-tu cela ?

[pierreloicq]

Je tente d'installer la 2.16.3 sur ubuntu 2014 avec la méthode "Software update" de la 2.16.3. J'avais un

Could not setup python environment !

j'ai d'abord remplacé mon buildout.cfg par ce fichier et cela a mené à ces erreurs

[camillemonchicourt]

Avec un tel retard et de tels décalages, je pense que ça va être compliqué, à moins de maitriser en détail les OS et tout l'environnement applicatif.

Pourquoi ne pas plutôt laisser de côté toute la mise à jour applicative. Installer un nouveau Geotrek à jour sur un OS à jour. Le brancher à ta BDD (très) ancienne et appliquer tous les scripts de migration de la BDD. Car là je vois pas trop l'intérêt de repasser par toutes ces installations de versions intermédiaires anciennes. Encore moins sur un Ubuntu version 20 pour lequel elles n'ont pas été prévues. C'est uniquement la BDD que tu veux mettre à jour. Mais ce scenario simpliste n'est peut-etre pas viable. ni faisable..

[gutard]

Mais ce scenario simpliste n'est peut-etre pas viable.

Effectivement ce n'est pas viable car il y a eu un reset des migration à un point donné.

[gutard]

Je tente d'installer la 2.16.3 sur ubuntu 2014 avec la méthode "Software update" de la 2.16.3. J'avais un Could not setup python environment !

OK et quelle est l'erreur de version remontée par Geotrek sur la 2.16.3 non modifiée ?

[pierreloicq]

J'avais identifié ceci mais il y a plein d'erreurs avant en fait, donc j'ai attaché tout le fichier

Getting distribution for 'venusian>=1.0'. error: Setup script exited with error: 'egg_base' must be a directory name (got src) An error occurred when trying to install /tmp/tmp5tQrrvget_dist/venusian-3.0.0.tar.gz. Look above this message for any errors that were output by easy_install. While: Installing django. Getting distribution for 'venusian>=1.0'.

install_1.log

[gutard]

OK je vois des soucis avec Pygments et venusian, pas avec celery. Je fais quelques test et je te dis.

[pierreloicq]

Le log que je donne ci-dessus est celui de ma 1ere tentative. Le problème avec Pygments et venusian semble résolu avec la 2eme tentative (ce buildout)

Getting distribution for 'Pygments==2.5.2'. Got Pygments 2.5.2.

Getting distribution for 'venusian==1.2.0'. Got venusian 1.2.0.

### Récap :

tentative 1: buildout par défaut problèmes pygments et venusian

2: le buildout trouvé sur github: celery = 4.2.0 django-celery-results = 1.0.1 ==>

Version and requirements information containing celery: [versions] constraint on celery: 4.2.0 Requirement of geotrek: django-celery Requirement of django-celery: django>=1.8 Requirement of django-celery: celery<4.0,>=3.1.15 While: Installing django. Error: The requirement ('celery<4.0,>=3.1.15') is not allowed by your [versions] constraint (4.2.0)

install_2.log

3: celery = 3.1.23 django-celery-results = 1.0.1 ==>

Installing omelette. Error: The requirement ('celery<5.0,>=4.0') is not allowed by your [versions] constraint (3.1.23)

install_3.log

4: pas de version celery précisée ==>

While: Installing omelette. Error: There is a version conflict. We already have: celery 3.1.26.post2 but django-celery-results 1.2.1 requires 'celery<5.0,>=4.4'.

install_4.log

[gutard]

Le buildout que tu as trouvé est destiné à la 2.29, pas à la 2.16. Il vaut mieux éviter de tester un peu n'importe quoi, c'est la meilleure manière de tout casser.

Essaie plutôt avec la version 2.16.4 que je viens de publier : https://github.com/GeotrekCE/Geotrek-admin/releases/tag/2.16.4

[gutard]

Et ensuite il faudra prendre la 2.29.16 et non la 2.29.15.

[pierreloicq]

Good job ! Les dépendances python sont ok. Par contre j'ai un "Could not update data !" maintenant.

bin/develop update -f INFO: Queued 'django-modeltranslation' for update. INFO: Queued 'pygal' for update. INFO: Queued 'screamshotter' for update. INFO: Updated 'screamshotter' with git. INFO: Updated 'pygal' with git. INFO: Updated 'django-modeltranslation' with git. bin/django collectstatic --clear --noinput --verbosity=0 Traceback (most recent call last): File "bin/django", line 120, in sys.exit(djangorecipe.binscripts.manage('geotrek.settings.custom')) File "/home/geotrekback/Geotrek-admin-2.16.4/lib/eggs/djangorecipe-2.2.1-py2.7.egg/djangorecipe/binscripts.py", line 9, in manage management.execute_from_command_line(sys.argv) File "/home/geotrekback/Geotrek-admin-2.16.4/lib/eggs/Django-1.8.18-py2.7.egg/django/core/management/init.py", line 354, in execute_from_command_line utility.execute()

install.log

[gutard]

Effectivement. Comme je suis pas payé plus cher j'ai fait ça à l'arrache ;)

Nouvelle version : https://github.com/GeotrekCE/Geotrek-admin/releases/tag/2.16.5

[camillemonchicourt]

Merci pour les releases archéologiques !

[pierreloicq]

ça marche, merci ! J’enchaîne toujours avec 2.29.16 ?

[gutard]

Oui. Et peut-être bien qu'il faudra une 2.29.17 ;)

C'est pour ça qu'on a changé la méthode d'installation à partir de la 2.30 histoire d'avoir un max de garanties que ce qui s'installait à une époque continue à s'installer quelques années plus tard.

[pierreloicq]

Je suis actuellement en 2.29.16 sur le nouveau serveur et tout va bien :-)

[pierreloicq]

Et en 2.38.1 :-) Merci beaucoup Gaël

[camillemonchicourt]

Bingo !

[pierreloicq]

Bonjour,

J'ai un Server Error (500) quand j'essaie d'ajouter une intervention, un chantier. Les tronçons et POI marchent.

postgresql-10-main.log 2020-09-28 16:03:29.833 CEST [26217] geotrek@geotrekdb STATEMENT: CREATE SCHEMA public; 2020-09-28 16:03:29.836 CEST [26217] geotrek@geotrekdb ERROR: schema "public" already exists 2020-09-28 16:03:29.836 CEST [26217] geotrek@geotrekdb STATEMENT: CREATE SCHEMA public; 2020-09-28 16:18:16.735 CEST [26331] geotrek@geotrekdb ERROR: record "new" has no field "nom" 2020-09-28 16:18:16.735 CEST [26331] geotrek@geotrekdb CONTEXT: PL/pgSQL function gestion.update_name_intervention() line 3 at assignment 2020-09-28 16:18:16.735 CEST [26331] geotrek@geotrekdb STATEMENT: INSERT INTO "maintenance_intervention" ("structure_id", "date_insert", "date_update", "deleted", "geom_3d", "ascent", "descent", "min_elevation", "max_elevation", "slope", "target_type_id", "target_id", "name", "date", "subcontracting", "width", "height", "area", "material_cost", "heliport_cost", "subcontract_cost", "length", "stake_id", "status_id", "type_id", "project_id", "description", "eid") VALUES (1, '2020-09-28T14:18:16.728551+00:00'::timestamptz, '2020-09-28T14:18:16.728570+00:00'::timestamptz, false, NULL, 0, 0, 0, 0, 0.0, 15, 70871, 'test', '2020-09-28'::date, false, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, NULL, 1, NULL, NULL, '', NULL) RETURNING "maintenance_intervention"."id"

sudo geotrek migrate

Operations to perform: Apply all migrations: admin, auth, authent, cirkwi, common, contenttypes, core, django_celery_results, easy_thumbnails, feedback, flatpages, infrastructure, land, maintenance, mapentity, sessions, signage, tourism, trekking, zoning Running migrations: No migrations to apply. Your models have changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

Dois-je lancer manage.py makemigrations ? Merci

[gutard]

Dois-je lancer manage.py makemigrations ?

Non. Le problème est ailleurs. Rien d'intéressant dans les log SQL. Il faudrait plutôt regarder les logs Python. Cf. https://geotrek.readthedocs.io/en/master/installation.html#troubleshooting

[pierreloicq]

sudo journalctl -eu geotrek-ui (les deux autres sont vides)

sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: ERROR 2020-09-28 16:49:20,605 django.request Internal Server Error: /intervention/add/ sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: Traceback (most recent call last): sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/db/backends/utils.py", line 84, in _execute sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: return self.cursor.execute(sql, params) sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: psycopg2.errors.UndefinedColumn: record "new" has no field "nom" sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: CONTEXT: PL/pgSQL function gestion.update_name_intervention() line 3 at assignment

sept. 28 16:49:20 GeotrekAdminU18 gunicorn[10315]: The above exception was the direct cause of the following exception: ...............

[gutard]

Cette fonction update_name_intervention() semble inconnue au bataillon. Ni dans le passé ni dans le présent du code de Geotrek-admin. Est-ce qu'elle n'aurait pas été rajoutée spécifiquement par vous (le parc) ? Si c'est bien le cas c'est à vous de la modifier ou supprimer. Quelle est sa définition PL/pgSQL ?

[gutard]

de la modifier

En remplaçant simplement nom par name.

[pierreloicq]

En effet update_name_intervention() a probablement été créée par une stagiaire qui est passée par ici. Elle est appelée par m_t_intervention_name(). Cette fonction est-elle connue au bataillon ?

Si je remplace nompar name et que je désactive m_t_intervention_name(), j'ai toujours l'erreur 500 après avoir cliqué sur "créer" (un chantier ou une intervention) mais l'objet s'enregistre.

sept. 29 11:12:06 GeotrekAdminU18 gunicorn[10315]: ERROR 2020-09-29 11:12:06,062 django.request Internal Server Error: /intervention/923/ sept. 29 11:12:06 GeotrekAdminU18 gunicorn[10315]: Traceback (most recent call last): sept. 29 11:12:06 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py", line 829, in _resolve_lookup sept. 29 11:12:06 GeotrekAdminU18 gunicorn[10315]: current = current[bit] sept. 29 11:12:06 GeotrekAdminU18 gunicorn[10315]: TypeError: 'Intervention' object is not subscriptable

Merci

[gutard]

Elle est appelée par m_t_intervention_name(). Cette fonction est-elle connue au bataillon ?

Non plus.

Si je remplace nom par name

Où ça ? Dans le code de la fonction PL/pgSQL ?

j'ai toujours l'erreur 500 après avoir cliqué sur "créer"

Il n'y a plus d'erreur à la création. Par contre il y a une erreur systématique sur les pages détail des interventions et chantiers. Or la page de création redirige vers la page détail une fois l'intervention créée.

Par contre, je ne vois pas trop quel est le problème. La backtrace est assez énigmatique et ça ne m'évoque rien de connu.

[pierreloicq]

Je pense en effet que le namecorrige le 1er problème.

Où ça ? Dans le code de la fonction PL/pgSQL ?

Oui :

CREATE TRIGGER m_t_intervention_name
    BEFORE INSERT
    ON public.maintenance_intervention
    FOR EACH ROW
    EXECUTE PROCEDURE gestion.update_name_intervention(\x);

CREATE FUNCTION gestion.update_name_intervention()
    RETURNS trigger
    LANGUAGE 'plpgsql'
    COST 100
    VOLATILE NOT LEAKPROOF
AS $BODY$
BEGIN
    NEW.name = to_char(NEW.date,'YYYY-MMDD-') || NEW.id;
    RETURN NEW;
END;
$BODY$;

ALTER FUNCTION gestion.update_name_intervention()
    OWNER TO geotrek;

Pour être exhaustif, il y a une seconde erreur mentionnée, voici le log plus complet :

sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: ERROR 2020-09-29 14:37:36,411 django.request Internal Server Error: /project/3/ sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: Traceback (most recent call last): sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py", line 829, in _resolve_lookup sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: current = current[bit] sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: TypeError: 'Project' object is not subscriptable sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: During handling of the above exception, another exception occurred: sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: Traceback (most recent call last): sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: response = get_response(request) sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/core/handlers/base.py", line 145, in _get_response sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: response = self.process_exception_by_middleware(e, request) sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/core/handlers/base.py", line 143, in _get_response sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: response = response.render() sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/response.py", line 106, in render sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: self.content = self.rendered_content sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/response.py", line 83, in rendered_content sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: content = template.render(context, self._request) sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/backends/django.py", line 61, in render sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: return self.template.render(context) sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: File "/opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py", line 171, in render sept. 29 14:37:36 GeotrekAdminU18 gunicorn[10315]: return self._render(context)

Il serait peut-être intéressant de voir si cette ligne 829 est présente sur une autre installation qui marche ? (@camillemonchicourt ) Dans le fichier /opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py. Est-il aussi écrit "current = current[bit]"

[camillemonchicourt]

Dans le fichier /opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py. Est-il aussi écrit "current = current[bit]"

Oui bien sur, tous ces dossiers sont installés automatiquement lors de l'installation de Geotrek-admin et de ses dépendances, donc on a tous les mêmes.

[pierreloicq]

En théorie oui, mais en pratique je n'y mettrais pas ma main à couper. Je vais faire une seconde install pour comparer le code et la structure de la BDD.

[gutard]

L'erreur ne vient sûrement pas de Django et du fichier /opt/geotrek-admin/lib/python3.6/site-packages/django/template/base.py mais je ne peux pas en dire plus sans avoir accès ssh au serveur et y passer du temps (TMA).

[pierreloicq]

Le bug est lié à notre BDD car il apparait quand je mets notre BDD sur une fresh install. @gutard Me conseillerais-tu une approche où je modifie la BDD et vois si ça change quelque chose, ou bien une approche au debugguer ?

[gutard]

Voir ma réponse au dessus :

je ne peux pas en dire plus sans avoir accès ssh au serveur et y passer du temps (TMA)

[pierreloicq]

Chez moi, remplacer get() par filter() dans /geotrek/maintenance/models.py ligne 269 corrige le problème pour les interventions: if self.target_type == ContentType.objects.get(model='signage'):

J'espère que ça fait sens !

[camillemonchicourt]

Je déconseille fortement de faire des modifications bricolées comme ça localement, dans le code du cœur de Geotrek. Nous n'avons pas de soucis, donc il vaudrait mieux faire investiguer proprement le soucis chez vous et voir si il y a problème spécifique chez vous, ou alors si il y a problème avéré de Geotrek-admin, mais qui n'impacterait que vous ??? D'ailleurs il mériterait un ticket dédié car il n'est pas lié au sujet de ce ticket.

[gutard]

J'espère que ça fait sens !

Euh ! Oui et non. Disons que ça pointe bien le problème. Par contre je ne vois pas trop comment ce fix peut fonctionner correctement. C'est pas parce que ça évite le crash a cet endroit que ça va forcément bien fonctionner par la suite. Essaye la commande sudo geotrek remove_stale_contenttypes et dis nous ce que ça raconte.

[gutard]

D'ailleurs il mériterait un ticket dédié car il n'est pas lié au sujet de ce ticket.

Je ne sais. En tout cas ce problème ne peut pas se produire sur une install neuve ou une mise à jour lorsque la 1ière version installée était >= 2.23. Par contre, il est susceptible de se produire dans les autres cas. Un fix est possible.

[pierreloicq]

Bonjour, Voici le résultat de sudo geotrek remove_stale_contenttypes

Some content types in your database are stale and can be deleted. Any objects that depend on these content types will also be deleted. The content types and dependent objects that would be deleted are:

- Content type for paperclip.attachment
- 5 auth.Permission object(s)
- 22 auth.Group_permissions object(s)
- 6 auth.User_user_permissions object(s)

This list doesn't include any cascade deletions to data outside of Django's models (uncommon).

Some content types in your database are stale and can be deleted. Any objects that depend on these content types will also be deleted. The content types and dependent objects that would be deleted are:

- Content type for infrastructure.baseinfrastructure
- 15 auth.Permission object(s)
- 33 auth.Group_permissions object(s)
- 21 auth.User_user_permissions object(s)
- 1 common.Attachment object(s)
- Content type for infrastructure.signage

This list doesn't include any cascade deletions to data outside of Django's models (uncommon).

Some content types in your database are stale and can be deleted. Any objects that depend on these content types will also be deleted. The content types and dependent objects that would be deleted are:

- Content type for tourism.datasource
- 3 auth.Permission object(s)
- 6 auth.Group_permissions object(s)
- 3 auth.User_user_permissions object(s)
- Content type for tourism.reservationsystem
- 3 auth.Permission object(s)
- 3 auth.Group_permissions object(s)
- 3 auth.User_user_permissions object(s)

This list doesn't include any cascade deletions to data outside of Django's models (uncommon).

[gutard]

OK. Ce qui m'intéressait c'est ça : Content type for infrastructure.signage. Et du coup, ça marche sans ta modification de code et après avoir exécuter cette commande ?

Il est possible que des permissions aient sauté lors de la mise à jour, en particulier sur les fichiers attachés et les aménagements. Il faudra éventuellement les redonnées aux différents groupes/utilisateurs.