maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 10 Pull requests 4 Projects Releases 28 Packages Wiki Activity Actions

bugfix(reports): tendances ouvrent en byCategory+table (paie visible) (#262) #266

Closed
maximus wants to merge 0 commits from issue-262-trends-default-view into main
pull from: issue-262-trends-default-view
merge into: maximus:main
Conversation 2 Commits - Files changed - +10 -2
maximus commented 2026-07-07 22:58:50 +00:00
Owner
Copy link

Resolves #262

Generated autonomously by /autopilot run of 2026-07-07

Résumé

Le rapport Tendances (/reports/trends) s'ouvrait sur le graphique mensuel global, qui n'a pas de section revenus — la paie de l'utilisateur restait invisible tant qu'il ne basculait pas manuellement sur la vue « Par catégorie » en tableau. Cette vue plate a déjà une section income depuis la v0.12.0.

Le rapport ouvre désormais sur byCategory + table par défaut, rendant la section revenus (donc la paie) visible d'emblée. Insurance pour la plainte #260 si le chantier lourd (#264/#265) ne se termine pas.

Deux changements one-liner, tous deux scopés à Trends :

  • src/hooks/useTrends.ts — subView initial "global" → "byCategory"
  • src/pages/ReportsTrendsPage.tsx — fallback readViewMode(STORAGE_KEY, "table") (le fallback est un paramètre du call-site)

ViewModeToggle.tsx non touché (le défaut est déjà isolé par rapport via la clé de storage).

Critères d'acceptation

  • Ouverture sans état persisté → byCategory + table ✅
  • Compare réel-vs-réel (clé distincte reports-viewmode-compare) inchangé ✅ (aucune modif du call-site compare ni de ViewModeToggle)
  • Catégorie de revenu (ex. Paie) visible dans la section Revenus à l'ouverture ✅
  • Build (tsc+vite) + 713 vitest verts, aucune régression ✅

Décisions

  • [HIGH] Le titre de l'issue #262 finit par « (#260) » (référence à l'epic parent) ; l'issue implémentée est bien #262 (body identique à la tâche). PR/commit référencent #262.
  • [MEDIUM] CHANGELOG référence #262 (issue livrante) pour rester cohérent avec les entrées existantes (#254, #253, #256). Alternative rejetée : citer #260 (la plainte user-facing) — écarté car les entrées du repo citent l'issue livrante.
  • [HIGH] Aucun test n'assertait l'ancien défaut subView: 'global' ni le fallback Trends → rien à mettre à jour côté tests. Les tests readViewMode portent sur les clés highlights/compare (fonction pure), non affectés.
  • [HIGH] Aucune clé i18n ajoutée : les libellés des sous-vues et des modes existent déjà, seul le défaut change.

Fichiers

  • src/hooks/useTrends.ts
  • src/pages/ReportsTrendsPage.tsx
  • CHANGELOG.md (Changed)
  • CHANGELOG.fr.md (Modifié)
Resolves #262 Generated autonomously by /autopilot run of 2026-07-07 ## Résumé Le rapport Tendances (`/reports/trends`) s'ouvrait sur le graphique mensuel global, qui n'a pas de section revenus — la paie de l'utilisateur restait invisible tant qu'il ne basculait pas manuellement sur la vue « Par catégorie » en tableau. Cette vue plate a déjà une section income depuis la v0.12.0. Le rapport ouvre désormais sur `byCategory` + `table` par défaut, rendant la section revenus (donc la paie) visible d'emblée. Insurance pour la plainte #260 si le chantier lourd (#264/#265) ne se termine pas. Deux changements one-liner, tous deux scopés à Trends : - `src/hooks/useTrends.ts` — `subView` initial `"global"` → `"byCategory"` - `src/pages/ReportsTrendsPage.tsx` — fallback `readViewMode(STORAGE_KEY, "table")` (le fallback est un paramètre du call-site) `ViewModeToggle.tsx` non touché (le défaut est déjà isolé par rapport via la clé de storage). ## Critères d'acceptation - Ouverture sans état persisté → `byCategory` + `table` ✅ - Compare réel-vs-réel (clé distincte `reports-viewmode-compare`) inchangé ✅ (aucune modif du call-site compare ni de `ViewModeToggle`) - Catégorie de revenu (ex. Paie) visible dans la section Revenus à l'ouverture ✅ - Build (tsc+vite) + 713 vitest verts, aucune régression ✅ ## Décisions - [HIGH] Le titre de l'issue #262 finit par « (#260) » (référence à l'epic parent) ; l'issue implémentée est bien #262 (body identique à la tâche). PR/commit référencent #262. - [MEDIUM] CHANGELOG référence #262 (issue livrante) pour rester cohérent avec les entrées existantes (#254, #253, #256). Alternative rejetée : citer #260 (la plainte user-facing) — écarté car les entrées du repo citent l'issue livrante. - [HIGH] Aucun test n'assertait l'ancien défaut `subView: 'global'` ni le fallback Trends → rien à mettre à jour côté tests. Les tests `readViewMode` portent sur les clés highlights/compare (fonction pure), non affectés. - [HIGH] Aucune clé i18n ajoutée : les libellés des sous-vues et des modes existent déjà, seul le défaut change. ## Fichiers - `src/hooks/useTrends.ts` - `src/pages/ReportsTrendsPage.tsx` - `CHANGELOG.md` (Changed) - `CHANGELOG.fr.md` (Modifié)
maximus added 1 commit 2026-07-07 22:58:50 +00:00
bugfix(reports): open Trends on byCategory + table by default
All checks were successful
PR Check / rust (pull_request) Successful in 24m51s
Details
PR Check / frontend (pull_request) Successful in 2m34s
Details
64ae00a847 
The Trends report previously opened on the global monthly chart, which
has no income section — so a user's revenue (e.g. their pay) was hidden
until they manually switched to the "By category" table view.

Open the report on byCategory + table by default so the income section
(and therefore payroll) is visible immediately. Two scoped call-site
changes:
- useTrends initial subView: "global" -> "byCategory"
- ReportsTrendsPage viewMode fallback: readViewMode(key, "table")

Both defaults are scoped to Trends. The real-vs-real compare report
(distinct "reports-viewmode-compare" storage key) is unaffected, and a
user's own persisted view choice still wins over the new fallback.

Resolves #262

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
maximus added the
autopilot:pending-human
type:bug
 labels 2026-07-07 22:58:57 +00:00
maximus commented 2026-07-08 00:07:14 +00:00
Author
Owner
Copy link

/pr-review — PR #266 (résout #262)

Verdict : APPROVE ✅

Résumé

Deux swaps de constantes bien scopés qui font ouvrir Tendances sur byCategory + table, rendant la section Revenus (donc la paie, plainte #260) visible d'emblée. Changement type-safe, aucune régression sur les autres rapports, aucune migration.

Vérifié

  • Types corrects : "byCategory" ∈ TrendsSubView (useTrends.ts:6), "table" ∈ ViewMode, et readViewMode(key, fallback: ViewMode = "chart") accepte bien le 2ᵉ argument (pré-existant, introduit en 5ade865 — non touché par cette PR).
  • Isolation des autres rapports confirmée : les 3 call-sites de readViewMode utilisent des clés de storage distinctes — reports-viewmode-trends (modifié), reports-viewmode-compare et reports-viewmode-highlights (call-sites inchangés, défaut "chart"). Compare et Highlights ne bougent pas d'un octet.
  • La table byCategory a bien une section Revenus : CategoryOverTimeTable → computeOverTimeResults produit des sections income/expense/transfer. Et getCategoryOverTime (reportService.ts:112) sélectionne toutes les catégories sans filtre de type (top N par magnitude, avec types), donc la paie est dans le dataset pour la vue graphique comme tableau.
  • Sectioning CHANGELOG bien formé : ### Added/### Ajouté puis ### Changed/### Modifié sous [Unreleased]/[Non publié], ordre canonique Keep a Changelog, pas de heading dupliqué. Entrées dans les deux langues.
  • Aucune chaîne i18n en dur : les libellés sous-vues (reports.trends.subview*) et modes (reports.viewMode.*) existent déjà.
  • Commit unique et focalisé (64ae00a), diff = 4 fichiers / +10 −2, cohérent avec la PR.

Suggestions (non bloquantes)

  1. Pas de test de régression alors que l'issue est type:bug. Un garde-fou sur les deux nouveaux défauts (subView initial "byCategory" dans useTrends; viewMode "table" quand localStorage est vide) échouerait sur l'ancien code et passerait sur le nouveau — il verrouillerait le comportement lié à #260 contre un revert distrait. Je ne bloque pas : ce sont des constantes pures sans logique de branchement, et un vrai test demanderait renderHook + services mockés (ou un render de page avec i18n/router), coût non négligeable pour un change-detector. À considérer si tu veux figer l'intention.

  2. Nuance CHANGELOG : « la vue que vous choisissez reste mémorisée » est vrai pour le mode graphique/tableau (persisté), mais pas pour le choix Global / Par catégorie — le subView n'est jamais persisté et se réinitialise à byCategory à chaque visite (comportement pré-existant, ex-global). Un utilisateur qui préfère « Global » devra rebasculer à chaque ouverture. Formulation à préciser éventuellement, sinon acceptable comme copy produit.

  3. Portée réelle du fallback "table" : l'effet de montage de ViewModeToggle (localStorage.setItem au mount) persiste viewMode dès la 1ʳᵉ ouverture historique de Tendances. Les utilisateurs existants ont donc déjà reports-viewmode-trends renseigné → le fallback "table" ne touche que les utilisateurs vraiment neufs. La moitié qui porte le fix pour tout le monde, c'est le passage subView → byCategory (paie visible en graphique et tableau). Conforme au cadrage « insurance » de la PR — aucune action requise.

  4. Le type de commit bugfix(...) diffère du fix(...) conventionnel, mais aucun commitlint dans le repo et les préfixes y sont libres (polish, state, …) — purement stylistique.

Rien de bloquant. Bon à merger.

## /pr-review — PR #266 (résout #262) **Verdict : APPROVE** ✅ ### Résumé Deux swaps de constantes bien scopés qui font ouvrir Tendances sur `byCategory` + `table`, rendant la section Revenus (donc la paie, plainte #260) visible d'emblée. Changement type-safe, aucune régression sur les autres rapports, aucune migration. ### Vérifié - **Types corrects** : `"byCategory"` ∈ `TrendsSubView` (useTrends.ts:6), `"table"` ∈ `ViewMode`, et `readViewMode(key, fallback: ViewMode = "chart")` accepte bien le 2ᵉ argument (pré-existant, introduit en `5ade865` — non touché par cette PR). - **Isolation des autres rapports confirmée** : les 3 call-sites de `readViewMode` utilisent des clés de storage distinctes — `reports-viewmode-trends` (modifié), `reports-viewmode-compare` et `reports-viewmode-highlights` (call-sites inchangés, défaut `"chart"`). Compare et Highlights ne bougent pas d'un octet. - **La table byCategory a bien une section Revenus** : `CategoryOverTimeTable` → `computeOverTimeResults` produit des sections `income`/`expense`/`transfer`. Et `getCategoryOverTime` (reportService.ts:112) sélectionne toutes les catégories sans filtre de type (top N par magnitude, avec `types`), donc la paie est dans le dataset pour la vue graphique **comme** tableau. - **Sectioning CHANGELOG bien formé** : `### Added`/`### Ajouté` puis `### Changed`/`### Modifié` sous `[Unreleased]`/`[Non publié]`, ordre canonique Keep a Changelog, pas de heading dupliqué. Entrées dans les deux langues. - **Aucune chaîne i18n en dur** : les libellés sous-vues (`reports.trends.subview*`) et modes (`reports.viewMode.*`) existent déjà. - Commit unique et focalisé (`64ae00a`), diff = 4 fichiers / +10 −2, cohérent avec la PR. ### Suggestions (non bloquantes) 1. **Pas de test de régression alors que l'issue est `type:bug`.** Un garde-fou sur les deux nouveaux défauts (subView initial `"byCategory"` dans `useTrends`; viewMode `"table"` quand `localStorage` est vide) échouerait sur l'ancien code et passerait sur le nouveau — il verrouillerait le comportement lié à #260 contre un revert distrait. Je ne bloque pas : ce sont des constantes pures sans logique de branchement, et un vrai test demanderait `renderHook` + services mockés (ou un render de page avec i18n/router), coût non négligeable pour un change-detector. À considérer si tu veux figer l'intention. 2. **Nuance CHANGELOG** : « la vue que vous choisissez reste mémorisée » est vrai pour le mode graphique/tableau (persisté), mais **pas** pour le choix Global / Par catégorie — le `subView` n'est jamais persisté et se réinitialise à `byCategory` à chaque visite (comportement pré-existant, ex-`global`). Un utilisateur qui préfère « Global » devra rebasculer à chaque ouverture. Formulation à préciser éventuellement, sinon acceptable comme copy produit. 3. **Portée réelle du fallback `"table"`** : l'effet de montage de `ViewModeToggle` (`localStorage.setItem` au mount) persiste `viewMode` dès la 1ʳᵉ ouverture historique de Tendances. Les utilisateurs existants ont donc déjà `reports-viewmode-trends` renseigné → le fallback `"table"` ne touche que les utilisateurs vraiment neufs. La moitié qui porte le fix pour tout le monde, c'est le passage `subView → byCategory` (paie visible en graphique **et** tableau). Conforme au cadrage « insurance » de la PR — aucune action requise. 4. Le type de commit `bugfix(...)` diffère du `fix(...)` conventionnel, mais aucun commitlint dans le repo et les préfixes y sont libres (`polish`, `state`, …) — purement stylistique. Rien de bloquant. Bon à merger.
maximus commented 2026-07-08 00:34:02 +00:00
Author
Owner
Copy link

Mergée localement dans main (pile #266/#267/#268/#269, tip fe87313). Fermée manuellement — merge local d'une pile stackée (l'API merge Forgejo échoue sur les bases non-main), tip cumulé validé build + 728 vitest verts.

Mergée localement dans `main` (pile #266/#267/#268/#269, tip `fe87313`). Fermée manuellement — merge local d'une pile stackée (l'API merge Forgejo échoue sur les bases non-`main`), tip cumulé validé build + 728 vitest verts.
maximus closed this pull request 2026-07-08 00:34:02 +00:00
All checks were successful
PR Check / rust (pull_request) Successful in 24m51s
Details
PR Check / frontend (pull_request) Successful in 2m34s
Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
autopilot:pending-human

PR produced by /autopilot — awaits human review/merge

  
source:analyste

Créée par le Super-Analyste

  
source:defenseur

Créée par l Escouade Défenseur

  
source:human

Créée par un humain

  
source:medic

Créée par le Medic (auto-détection)

  
status:approved

PR approuvée, prête à merger

  
status:blocked

Bloquée (question, dépendance, clarification)

  
status:in-progress

Un agent (Medic/Dev) travaille dessus

  
status:needs-clarification

Issue blocked by ambiguity — Max needs to clarify before re-running autopilot

  
status:needs-fix

Reviewer demande des corrections

  
status:ready

Analysée et documentée, prête à prendre

  
status:review

PR créée, en attente du Reviewer

  
status:triage

Nouvelle issue, pas encore analysée

  
type:bug

Correction de bug → Medic

  
type:feature

Nouvelle fonctionnalité → Dev

  
type:infra

Config, CI/CD, déploiement → Dev

  
type:refactor

Refactoring / amélioration technique → Dev

  
type:schema

Modèle de données / migrations → Dev

  
type:security

Issue de sécurité → Medic ou Dev

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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: maximus/Simpl-Resultat#266
No description provided.
Delete branch "issue-262-trends-default-view"

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?