Refonte - Trésorerie - Journal - List

[vgreb]

No description provided.

[stakovicz]

Gros chantier ! Bravo !

[Mopolo]

Je n'ai pas compris de suite que c'était pour mapper la query, et vu que ça ne sert qu'à ça, je suis pas sûr que ce soit le bon namespace.

Là on pourrait penser que c'est un enum global à toute la tréso je trouve.

Peut-être le déplacer dans le même namespace que le controller ?

[vgreb]

J'ai effectivement créer un enum dédié parce qu'il manquait un cas dans \AppBundle\Compta\Importer\OperationType.

Je vais voir si je trouve une solution pour fusionner les deux sinon je déplacerai dans le namespace du controller.

[vgreb]

Au final, j'utilise le nouvel enum dans les classes d'import des relevés bancaire.

[Mopolo]

Ah. Alors je vais faire mon relou mais là ça pose un nouveau problème pour moi.

Avec cette fusion, on se retrouve avec le code de l'import qui pourrait être dans un état invalide (type = all) alors que ce n'est actuellement pas du tout possible grâce à l'enum limité. Et si on doit avoir du code qui ne peut être QUE débit ou crédit, et bien là il faudrait vérifier à chaque fois que la valeur n'est pas all.

Je comprend bien que les notions soient proches, mais elle ne sont pour autant pas les mêmes. Et j'insiste surtout pour avoir déjà fait ce genre de fusion sur des projets boulot et je l'ai regretté après.

En vrai, vu comment l'enum est utilisé dans le controller, tu pourrais même t'en passer et faire un simple assert :

$type = $request->query->getInt('type');
Webmozart\Assert\Assert::inArray($type, [0, 1, 2]);

Vu que de toute façon l'enum est retransformé en int immédiatement après, autant s'éviter la confusion non ?

[vgreb]

Ok, ça me va va j'étais parti sur un enum parce que travailler avec 0, 1 et 2 c'est pas très explicite :)

[Mopolo]

Ah oui t'as raison en fait 😄
Bin dans ce cas pourquoi ne pas en profiter pour utiliser "debit", "credit" et null ?