Produits Entr'ouvert » Combo

Et plutôt que type qui "oblige" à un bien moche typ, pourquoi ne pas parler de "catégories" de factures ?

Laissons le 0004 à un autre ticket. Je ne suis pas favorable à l'ajout d'informations à la colonne "libellé", ça appellera discussion.

Et il faudra un autre ticket pour le litigation, aussi.

Invoice = apps.get_model('lingo', 'Invoices')

C'est plutôt confus la disparition du "s" de l'un à l'autre.

Du coup je pense que pour éviter des problème dans un avenir où on aurait un autre modèle appelé "Invoice", on devrait appeler dès maintenant la cellule "InvoicesTable".

On l’appellerait pas InvoiceCell pour pas se tromper ?

Je m'étais mis en tête qu'on ne suffixait généralement pas avec Cell mais c'est tout le contraire, la grande majorité des modèles des cellules se terminent en Cell, donc oui, tout à fait, InvoicesCell.

Idéalement une migration manuelle ne s'appellerait pas 0019_auto_... mais passons sur ce détail.

Le changement de nom pour la classe n'a pas été total :

  File "/home/fred/src/eo/combo/combo/public/views.py", line 96, in ajax_page_cell
    return HttpResponse(cell.render(context), content_type='text/html')
  File "/home/fred/src/eo/combo/combo/apps/lingo/models.py", line 420, in render
    return super(Invoices, self).render(context)
NameError: global name 'Invoices' is not defined

(ce qui lèverait donc la nécessité de tests unitaires…)

Le retour en arrière ne crée que des cellules "factures actives" :

ItemsHistory = apps.get_model('lingo', 'ActiveItems')

Je préférerais vraiment ne pas copier du code au copyright extérieur, sous une autre licence, dans combo.

Je l'avais fait pour éviter de maintenir des packages exterieurs.
Mais ok, je package django-multiselectfield séparemment: https://dev.entrouvert.org/issues/10544

J'imaginais plutôt fonctionner sans le code, plutôt que le taper en dépendance.

Alors ça va être un select multiple, tout moche

Dans l'idée de pouvoir plus tard pouvoir choisir les factures par type de paiement: prélevement, en contentieux, payable en ligne et les colonnes à afficher dans le tableau, ça me parait plus pertinent d'utiliser des cases à cocher.

Alors ça va être un select multiple, tout moche.

Très bien, et quand on voudra autre chose on arrivera à le coder, sans dépendance externe.

Commentaire déplacé du #10494:
J'ai toujours du mal avec une section qui s'appelle "Vos factures à payer" et qui contient des trucs qu'on ne peut pas payer. Pour moi le statut de la facture devrait être donné directement dans le tableau sans click en plus, cette popup ne contient apparemment aucune donnée qu'on aurait pas déjà dans le tableau à part la raison de non-possibilité de paiement (je suppose que montant total = montant à payer dans 99,9% des cas). Je ne vois aucun lien "Payer", on est censé savoir qu'il faut cliquer sur les lignes du tableau ?

Je verrai un truc comme ça:

Vos factures            _non payées (en noir italique)_           _toutes (grisé italique)_

Je passe que si une facture est en contentieux on veut le savoir tout de suite, même si on ne peut pas la payer, et pour celle en prélèvement on veut savoir quand ce sera prélevé.

Si on clique sur "toutes":

Vos factures            _à payer (grisé italique)_           _toutes (en noir italique)_

[_Voir les factures précédentes_]

Si on clique sur voir les factures précédentes on charge d'autres factures en AJAX par paquet de 3 mois, si on a une facture PDF, télécharger donne tous les détails pas besoin de bouton [Voir] si on a pas de PDF je propose de balancer un HTML pseudo-"imprimable" genre facturette CB qu'on aurait mis avant dans la popup [Voir]. Mais [Voir] + [Télécharger] c'est trop.

Je viens de créer https://dev.entrouvert.org/projects/publik/wiki/Mockups_Publik_Jarticule_2016 , sans commentaires pour le moment, mais il y a des bouts qui sont faits et te rejoignent (voir + télécharger, c'est trop, on est tous d'accord). Aussi, la cellule unique avec filtre en haut, c'est quelque chose qu'on trouvait dans les mockup Orléans.

J'écrivais :

Alors ça va être un select multiple, tout moche.

Très bien, et quand on voudra autre chose on arrivera à le coder, sans dépendance externe.

Aussi, il semblerait possible que Django intègre de base select2 dans une version à venir et j'ai vu à cette occasion qu'il gérait aussi les <select multi>