rapport - par categorie - probleme de presentation avec combobox #126
Labels
No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: maximus/Simpl-Resultat#126
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Contexte
Le rapport d'analyse "par categorie" (
/reports/category) utilise depuis le commitbd992f2le composant partageCategoryComboboxa la place d'un<select>natif. Le combobox calcule correctement la profondeur de chaque categorie (viaparent_id) et applique une indentation proportionnelle, mais il affiche les items dans l'ordre recu — c'est-a-dire l'ordre degetAllCategoriesWithCounts():ORDER BY c.sort_order, c.name.Comme
sort_orderest attribue par parent (et non globalement), le tri global entremele parents et enfants. Resultat : la liste non filtree montre des niveaux melanges avec indentation visuelle, mais sans logique d'arbre. Le filtrage au clavier semble fonctionner car, en reduisant la liste, il masque l'interclassement des niveaux.La solution canonique existe deja dans le projet :
buildTree+flattenTreeToCategoriesdanssrc/hooks/useCategories.ts:61-92(parcours depth-first qui emet chaque parent immediatement suivi de ses enfants).Travail a faire
buildTreeetflattenTreeToCategoriesdesrc/hooks/useCategories.tsvers un util partagesrc/utils/categoryTree.ts(ou reexport depuisuseCategories.ts)src/components/shared/CategoryCombobox.tsx, trier la propcategoriesen ordre d'arbre (depth-first, siblings tries parsort_orderpuisname) viauseMemo, reutiliser la meme passe pour calculer la profondeurflattenTreeToCategorieset surCategoryCombobox(ordre des<li>rendus)## [Unreleased] > FixeddansCHANGELOG.mdet## [Unreleased] > CorrigedansCHANGELOG.fr.mdFichiers concernes
src/components/shared/CategoryCombobox.tsx— tri hierarchique en memo, reutilisation dedepthssrc/hooks/useCategories.ts— exporter (ou deplacer)buildTree/flattenTreeToCategoriessrc/utils/categoryTree.ts(nouveau, optionnel) — emplacement partage si extractionCHANGELOG.md+CHANGELOG.fr.md— entree Fixed / CorrigeSurface de test
CategoryCombobox: aucuncategoryServicepour le tri : aucun (categorizationService.test.tsetreportService.test.tsne couvrent pas l'ordre)src/utils/categoryTree.test.ts— cas multi-niveaux avecsort_orderper-parent (chaque parent suivi immediatement de ses enfants)src/components/shared/CategoryCombobox.test.tsx— rendu : ordre des<li>respecte la hierarchie, indentation matche le depthDecision de scope
Fix dans le composant partage
CategoryCombobox(decision confirmee lors de l'analyse).Les quatre consommateurs (
CategoryZoomHeader/ rapport par categorie,TransactionFilterBar,SplitAdjustmentModal,TransactionTable) beneficient automatiquement du correctif sans modification.Ecarte : pre-trier dans
getAllCategoriesWithCounts— laisserait la meme bombe a retardement dans les trois autres consommateurs.Criteres d'acceptation
parent_id) restent tries parsort_orderpuisnamedepth(inchangee visuellement, mais l'ordre devient coherent)TransactionFilterBar,SplitAdjustmentModaletTransactionTablebeneficient automatiquement du correctifnpm run buildetnpm testpassent## [Unreleased]Complexite estimee
Simple — ~30 lignes de changement net (extraction helper +
useMemodans le combobox + 2 tests). Aucun changement de schema, aucun changement IPC, aucun impact i18n.Root cause (resume technique)
getAllCategoriesWithCounts()retourneORDER BY c.sort_order, c.name— tri global sur un champ qui est alloue par parent.CategoryCombobox.computeDepthscalcule la profondeur mais ne reordonne pas.