Produits Entr'ouvert » Combo

J'imaginais aussi ajouter le commentaire, renvoyé également par le webservice, sous le libellé de la facture. Une colonne supplémentaire dans le tableau pour ça me paraît inutile.

Nope. On peut avoir un code couleur, une icône ou un libellé court dans une nouvelle colonne, mais un tableau doit rester un tableau, avec ses informations affichées en colonnes.

(aussi on gagnerait à ajouter un commentaire utile dans la popup.)

(ton installation est à jour ? normalement la popup des factures a eu des changemetns de style)

Côté popup j'imaginais plutôt arriver à quelque chose genre "Cette facture n'est pas payable en ligne parce que vous avez opté pour le prélévement automatique", pas deux mots. Mais aussi, on se trouve avec deux fois la même info dans invoice.status et invoice.details ? (btw c'est moche d'appeler ça "comment" d'un côté et "details" de l'autre). Si c'est juste une correspondance, zappons "details", et assurons le mapping vers des libellés corrects côté lingo.

Faudrait remettre le <td>{{libellé}}</td> sur une seule ligne.

Il me semble aussi qu'on n'a pas de garantie d'avoir ce invoice.details et on n'a pas envie de voir apparaitre une colonne "details" à Fontenay-sous-Bois, genre; si l'attribut n'existe pas (None vs ''), il faudrait zapper cette colonne. Ou alors, vu mon récent regard à Fontenay-sous-Bois et ma découverte qu'une colonne y est cachée à coup de CSS, je serais, n'ajoutons pas du tout de colonne ici et prévoyons une série de cases à cocher dans la configuration, pour permettre de décider des colonnes affichées.

Je n'avais pas lancé make dans publik-base-theme.

Mon idée initiale était que le connecteur passerelle renvoie dans un champ commentaire le message accomapgnant une facture. Le connecteur Agora renvoie "impayée", "payée" ou "en contentieux" pour l'instant. La cellule du côté combo ne fait qu'afficher le message. D'ou l'attribut invoice.details.

Mais on peut très bien s'en passer, utiliser uniquement invoice.status pour définir une classe pour la ligne et décider que c'est la cellule lingo qui affiche le message("Cette facture n'est pas payable en ligne parce que vous avez opté pour le prélévement automatique" ou "Cette facture est en contentieux, vous pouvez la reglèr auprès du Trésor Public").

"Cette facture est en contentieux, vous pouvez la régler auprès du Trésor Public".

Pour moi cet exemple amènerait plutôt à avoir une version longue spécifique, parce que l'état "contentieux" ça ne doit pas nécessairement être une facture à régler au Trésor Public. (il y a bien sûr la possibilité de ne pas surpréciser, dans cette situation, de simplement afficher "Cette facture n'est pas payable en ligne parce qu'en contentieux.", point).

C'est pour ça que je voyais le logiciel métier nous remonter cette info via l'attribut invoice.details.

Serghei Mihai a écrit :

C'est pour ça que je voyais le logiciel métier nous remonter cette info via l'attribut invoice.details.

Je me dis qu'il faudrait attendre d'avoir ces informations dans passerelle avant de les anticipier, pour voir concrètement de quoi il retournera. Et de commencer sans ça, avec uniquement un statut.

https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_famille#Gestionremont%C3%A9e-des-factures

Je ne suis vraiment pas satisfait à considérer que "en contentieux" est un "mode de paiement"; pour moi il y a deux infos : "payable en ligne (o/n)" et le cas échéant "pourquoi ce n'est pas payable en ligne", je ne mêlerais pas l'info dans un même attribut.

_~~

J'aurais dans le code un mapping par défaut pour les explications, avec des belles phrases sujet/verbe/complément; aussi je ne préfixerais pas l'explication par "Détails", et au niveau du thème je travaillerais un peu le style pour avoir un symbole "info" devant. (je peux m'occuper de cette partie concernant le style).

_~~

if payment_mode:
    self.payment_mode = payment_mode

Je zapperais le if.

self.payment_mode_details = hasattr(settings, 'INVOICE_PAYMENT_MODES') and settings.INVOICE_PAYMENT_MODES.get(payment_mode)

J'aurais plutôt le retour d'une phrase d'explication dans une fonction; et le hasattr() n'est pas nécessaire, il suffit d'ajouter au fichier settings un dictionnaire vide LINGO_NO_ONLINE_PAYMENT_REASONS (pour prendre un nom m'allant mieux).

Commentaire déplacé sur #10483.

La trad, "This is a litigation invoice", ça sera "Cette facture est en contentieux" ? (et si oui, il me semble que la v.o. pourrait être changée en "This invoice is in litigation"). (pareil pour "This is a autobilling invoice" → "Autobilling has been set for this invoice", "Un prélévement automatique a lieu pour cette facture."). genre.

Par ailleurs, j'aurais gardé les chaines par défaut dans le code, le settings permettant de les surcharger. (pour ne pas imposer de placer toutes les chaines dans le settings quand on veut juste en adapter une).

Dans le item.html, il y a une raison à faire :

        {% with no_online_payment_reason_details=item.no_online_payment_reason_details %}
        {% if no_online_payment_reason_details %}
        <div class="no-online-payment-reason"><span>{{ no_online_payment_reason_details }}</span></div>
        {% endif %}
        {% endwith %}

Plutôt que directement :

        {% if item.no_online_payment_reason_details %}
        <div class="no-online-payment-reason"><span>{{ item.no_online_payment_reason_details }}</span></div>
        {% endif %}

?

Pour éviter d'appeler 2 fois la méthode no_online_payment_reason_details même si ce n'est pas très impactant niveau perfs.

Faisons sans, alors, si jamais il y a des considérations de performance à avoir, ce ne sera de toute façon pas là qu'il faudra chercher.

ok.