Currency formatting is not possible using the 'C' locale
#11
Je n'ai pas l'impression d'avoir mis de caractère spéciaux, vu que c'est pour tester je n'ai pas renseigné  beaucoup d'infos


Pièces jointes Miniature(s)
   
  Répondre
#12
Hum il a bien le statut "soldée" dans votre capture ; est-ce que ça marche avec "brouillon" à la place ?
  Répondre
#13
Même chose avec brouillon

Code :
[2020-04-24 16:52:25] ERROR - django.request : Internal Server Error: /billing/generate_pdf/17
Traceback (most recent call last):
  File "/home/user/.virtualenvs/creme_2_1/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/user/.virtualenvs/creme_2_1/lib/python3.6/site-packages/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/user/.virtualenvs/creme_2_1/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/user/.virtualenvs/creme_2_1/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/home/user/.virtualenvs/creme_2_1/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/srv/creme_crm-2.1/creme/billing/views/export.py", line 88, in export_as_pdf
    f.write(smart_str(template.render(context)))
UnicodeEncodeError: 'ascii' codec can't encode character '\\xe9' in position 854: ordinal not in range(128
  Répondre
#14
Je viens de tester en dev (runserver) en recopiant la BDD pour avoir la facture en question qui bloque en prod:
Code :
[24/Apr/2020 18:16:44] SERVER: "GET /billing/invoice/edit/17 HTTP/1.1" 200 47290
[24/Apr/2020 18:16:44] SERVER: "GET /creme_core/relation/entity/4/json?fields=summary HTTP/1.1" 200 40
[24/Apr/2020 18:16:45] SERVER: "GET /creme_core/relation/entity/23/json?fields=summary HTTP/1.1" 200 19
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
[24/Apr/2020 18:16:48] SERVER: "GET /billing/generate_pdf/17?format=pdf HTTP/1.1" 302 0
[24/Apr/2020 18:16:48] SERVER: "GET /download_file/upload/billing/Facture_17_24042020_181648.pdf HTTP/1.1" 200 14120

Tout fonctionne bien, j'ai bien le PDF qui sort.



Vraiment bizarre je comprend pas pourquoi en Dev c'est OK et pas en Prod, qu'est ce qui peut être différent ?
  Répondre
#15
Bonjour, enfin bonsoir,

Dans d'autre circonstance, sur une erreur un peu similaire (mais sur une lecture alors là que vous avez une écriture), j'ai pu régler le problème en forçant l'encoding du open.

Alors clairement c'est plus  une tentative désespérée qu'une vraie solution, mais cela peut marcher.

Si vous voulez tester je vous propose donc de remplacer la ligne 88 à savoir  :

Code :
with open(latex_file_path, 'w') as f:


par :

Code :
with open(latex_file_path, 'w', encoding="utf-8") as f:
  Répondre
#16
Effectivement ça fonctionne !
Mais bon si vous me dite que c'est pas une vraie solution Confused
  Répondre
#17
bonsoir,

je me suis mal exprimé. Ce n'est pas "pas une vraie solution", mais simplement j'avais quelques doutes sur le fait que cela allait fonctionner.

Et surtout je n'ai pas d'explication sur pourquoi cela ne fonctionne pas sans cette modification.

Mais si cela fonctionne, vous pouvez laisser comme cela.
  Répondre
#18
Ok, du coup j'imagine que je dois refaire la modif à chaque update, c'est pas hyper propre Confused
  Répondre
#19
Je testerai lundi de mon coté, mais ça devrait partir dans un correctif de la version 2.1.4 sans souci ; même si cela semble étrange qu'un environnement nécessite de préciser l'encodage (alors que Creme dans ses settings déclare utiliser 'utf8'), on a déjà rencontré des soucis similaires pour des lectures de fichier sous Windows par exemple. je préfère un correctif au final assez anodin (si c'était 300 lignes de code ça serait un autre problème) qui fait que ça marche chez le plus de gens possibles, qu'un code "pur" mais qui ne marche pas en pratique. Après le principal problème (vu qu'on n'arrive pas à reproduite le bug) est que ce genre de souci pourrait arriver dans d'autres partie du code. J'ai regardé un peu les quelques parties qui pourraient être problématiques, mais elles me semblent OK.

Bon week-end !
  Répondre
#20
Très bien, bon en tout cas merci pour le temps passé et bon week-end !
  Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)