Produits Entr'ouvert » Combo

J'ai dû rater une étape : on avait dit que justement ça serait un datetime pour éviter de se poser la question "est-ce que le jour est inclu ou pas" ? (et donc indiquer 00h00 ou 23h59 pour facilement clarifier).

C'est un peu dommage d'avoir abandonné ça, mais bon, ma faute, j'aurais dû être plus attentif.

Pour clarifier le code, remplacer "now = timezone.now()" par "today = timezone.now().date()".

Faudra mettre la doc à jour en précisant si la date limite est incluse ou pas... (et je me fatigue même pas à comprendre le code pour le savoir :) )

• apps/family/loaders/concerto_orleans.py : 'pay_limit_date': get_datetime(i['dat_limitepaie_fac']) (peut très bien renvoyer un datetime)
• passerelle/contrib/agoraplus/normalize.py: invoice['pay_limit_date'] = datetime.strptime(invoice['dateLimitePayment'], DATETIME_FORMAT) : va renvoyer un datetime
• passerelle/contrib/fake_family/default_database.py: "pay_limit_date": limit.strftime('%Y-%m-%dT%H:%M:%S')
• passerelle/contrib/stub_invoices/models.py: 'pay_limit_date': now + datetime.timedelta(days=2+random.randint(0, 10))

Bref, c'est pas mal le boxon... Je serais presque d'avis de pouvoir supporter les deux formats, et comparer avec now() ou today() selon le cas.

Le connecteur "fausses factures" (qui est ma référence en local pour les tests sur les factures) retourne des datetimes.

(entre temps Thomas a complété)

Plutôt que parser différemment les choses ici, il faudrait laisser à RemoteItem l'interprétation de ce qui est reçu (il accepte déjà les dates nues autant que les dates/heures).

Le loader concerto et le connecteur Teamnet retournent des dates:

• passerelle/apps/family/models.py::get_datetime
• passerelle/contrib/teamnet_axel/utils.py::normalize_invoice

parce que l'export d'Orléans, comme le WS de Teamnet, contient des dates, présumant que la date est incluse dans le delai de paiement.

Donc je vois plutôt une correction de l'interprétation de la date limite de paiement dans lingo pour ne pas appliquer make_aware.

Donc je vois plutôt une correction de l'interprétation de la date limite de paiement dans lingo pour ne pas appliquer make_aware.

J'insiste : il faudrait laisser à RemoteItem l'interprétation de ce qui est reçu. (→ ici également passer par RemoteItem plutôt qu'ajouter un endroit où les factures sont parsées différemment).

Ça me va de ne plus utiliser un dico non typé, mais clairement RemoteItem doit avoir une compréhension unique de ce qui est renvoyé concernant jour inclue ou jour exclu et toujours la même (en cas de date, pour les datetime le problème ne se pose pas, enfin j'espère, mais s'il se posait la réponse serait la même). Ensuite c'est aux connecteurs de renvoyer soit le jour d'avant, soit le jour courant soit le jour d'après selon ce qu'on a décidé pour RemoteItem (je ne connais pas la situation exacte, c'est juste que pour moi c'est la source, le connecteur, qui doit s'adapter dans ces cas là, RemoteItem ne peut pas deviner ça).

Effectivement, tous les connecteurs ne suivent pas encore le format qu'on s'est défini. La preuve, je me suis embrouillé en me basant sur un des connecteurs.
C'est l'occasion de les normer (y en a pas des masses).

Je ne vois pas vraiment de ticket central sur le sujet, je note du coup ici qu'on parle de dates limite de paiement, que le passage en datetime peut plutôt être une source de confusion (dans les interfaces on continue à parler de date et à juste afficher une date, il me semble).

Je tendrais plutôt à ce qu'on définisse le caractère inclus/exclu de la date de fin et que les connecteurs suivent ce qui aura été défini.

Pour moi, ça apporte plus de confusion d'avoir certains champs de type date et d'autres datetime, comme par exemple dans le connecteur family: la date limite de paiement est une date et la date de paiement est une datetime.
Côté combo, tous ces champs sont formatés comme des dates, donc même si passerelle retourne des datetimes ça fonctione.

même si passerelle retourne des datetimes ça fonctionne

On doit pouvoir informer sans ambiguité l'usager de la date limite, et on lui affiche une date, on doit donc pouvoir préciser si celle-ci est exclue ou pas, et on ne vas pas avoir dans combo du code pour dire "ah 23h59 donc c'est date de fin inclue".

Remarque de forme:

                invoice = build_remote_item(invoice, self)

Du coverage je vois que deux lignes ne sont pas testés dans ce code (voir https://jenkins.entrouvert.org/job/combo/2023/cobertura/apps_lingo/models_py/, ligne 250-251), au passage j'ajouterai bien leur couverture.

chipotage:

.strftime(date_format)

plutôt .date().isoformat() (ça fait pareil, mais c'est plus clair il me semble, parce que .strftime() existe aussi sur la classe @date)) ?

Ack.