Choisir et mémoriser un horizon de planification libre #57

New Issue

2026-10-05T11:42:34+02:00

nessar commented

2026-10-05 11:42:34 +02:00

(Migrated from 172.24.0.1:8928)

Blocked by: None — can start immediately

Parent

Part of #12 — spécification approuvée.

What to build

L’utilisateur choisit dans les réglages une date de début et une dernière date de planification inclusive, enregistre ce choix et obtient un calendrier correspondant exactement à ces dates après Calculer. Les dates passées et les horizons de plusieurs années sont acceptés, avec les jours fériés et les périodes de repos corrects sur toute la période. Cette tranche est démontrable avec des scénarios légers d’une journée, historiques, de deux ans et de trois ans ; la suppression du délai automatique de calcul relève d’une tranche suivante.

Acceptance criteria

Les réglages proposent les deux dates inclusives. Une sélection dont le début et la dernière date de planification sont identiques couvre une journée.
Sans horizon enregistré, le défaut reste aujourd’hui en Europe/Paris jusqu’à la même date douze mois plus tard, exclusive ; le champ de fin inclusive affiche la veille. Le 29 février suit la convention anniversaire existante.
Les dates passées, les horizons entièrement historiques et les horizons de deux ou trois ans sont acceptés par la saisie, la validation du planificateur et l’affichage, sans plafond fonctionnel de durée.
Un horizon valide est persisté et restauré avant d’appliquer un défaut. Ses dates restent fixes au rechargement et lorsque son début devient passé.
Une date impossible, une date malformée ou une fin antérieure au début empêche le lancement et donne une indication de validation. La saisie invalide ne remplace pas le dernier horizon valide enregistré.
Le Planning horizon reste semi-ouvert : sa borne exclusive est le jour calendaire suivant la dernière date de planification. La conversion reste correcte en année bissextile, autour des changements d’heure et avec un navigateur dans un autre fuseau.
Modifier les dates, soldes ou règles ne lance aucun calcul. Le calendrier conserve le résultat et l’horizon du calcul précédent jusqu’à la prochaine demande explicite.
Calculer capture l’horizon sélectionné dans le même instantané que les soldes et règles. Le résultat, les explications et la trace restent attachés à cet instantané ; un résultat ancien reçu en retard ne remplace pas le calcul courant.
Les mois partiels aux bornes et les jours fériés français de toutes les années couvertes sont correctement projetés. Les dates de placement restent dans l’horizon ; seuls les jours non travaillés adjacents peuvent prolonger une période de repos hors horizon.
Les soldes conservent leur disponibilité, expiration, type et provenance. Un solde expiré avant le début est expliqué comme une expiration inévitable ; il n’est pas placé.
Les états sans plan, de conflit, d’annulation ou d’erreur utilisent également l’horizon demandé, sans revenir silencieusement à l’année par défaut.
Les tests comportementaux des paramètres, de la restauration, du planificateur public et du calendrier couvrent ces cas. Les vérifications pertinentes de lint, types, tests et build passent.

Blocked by

None — can start immediately.

Further notes

Respecter l’ADR 0006 et les termes Planning horizon et Last planning date. Les suites CalendarSettingsService, UserSettings, UserInputService, CalendarService et CalendarYear fournissent les points d’appui. La projection des jours fériés du calendrier ne charge actuellement que deux années : couvrir toutes les années fait partie de cette tranche. Les objectifs du planificateur et les familles de règles restent inchangés. Aucun pré-refactoring indépendant n’est nécessaire.

**Blocked by:** None — can start immediately ## Parent Part of #12 — [spécification approuvée](https://gitlab.nessar.fr/nessar/vac-optimizer/-/work_items/12). ## What to build L’utilisateur choisit dans les réglages une date de début et une dernière date de planification inclusive, enregistre ce choix et obtient un calendrier correspondant exactement à ces dates après Calculer. Les dates passées et les horizons de plusieurs années sont acceptés, avec les jours fériés et les périodes de repos corrects sur toute la période. Cette tranche est démontrable avec des scénarios légers d’une journée, historiques, de deux ans et de trois ans ; la suppression du délai automatique de calcul relève d’une tranche suivante. ## Acceptance criteria - [ ] Les réglages proposent les deux dates inclusives. Une sélection dont le début et la dernière date de planification sont identiques couvre une journée. - [ ] Sans horizon enregistré, le défaut reste aujourd’hui en Europe/Paris jusqu’à la même date douze mois plus tard, exclusive ; le champ de fin inclusive affiche la veille. Le 29 février suit la convention anniversaire existante. - [ ] Les dates passées, les horizons entièrement historiques et les horizons de deux ou trois ans sont acceptés par la saisie, la validation du planificateur et l’affichage, sans plafond fonctionnel de durée. - [ ] Un horizon valide est persisté et restauré avant d’appliquer un défaut. Ses dates restent fixes au rechargement et lorsque son début devient passé. - [ ] Une date impossible, une date malformée ou une fin antérieure au début empêche le lancement et donne une indication de validation. La saisie invalide ne remplace pas le dernier horizon valide enregistré. - [ ] Le Planning horizon reste semi-ouvert : sa borne exclusive est le jour calendaire suivant la dernière date de planification. La conversion reste correcte en année bissextile, autour des changements d’heure et avec un navigateur dans un autre fuseau. - [ ] Modifier les dates, soldes ou règles ne lance aucun calcul. Le calendrier conserve le résultat et l’horizon du calcul précédent jusqu’à la prochaine demande explicite. - [ ] Calculer capture l’horizon sélectionné dans le même instantané que les soldes et règles. Le résultat, les explications et la trace restent attachés à cet instantané ; un résultat ancien reçu en retard ne remplace pas le calcul courant. - [ ] Les mois partiels aux bornes et les jours fériés français de toutes les années couvertes sont correctement projetés. Les dates de placement restent dans l’horizon ; seuls les jours non travaillés adjacents peuvent prolonger une période de repos hors horizon. - [ ] Les soldes conservent leur disponibilité, expiration, type et provenance. Un solde expiré avant le début est expliqué comme une expiration inévitable ; il n’est pas placé. - [ ] Les états sans plan, de conflit, d’annulation ou d’erreur utilisent également l’horizon demandé, sans revenir silencieusement à l’année par défaut. - [ ] Les tests comportementaux des paramètres, de la restauration, du planificateur public et du calendrier couvrent ces cas. Les vérifications pertinentes de lint, types, tests et build passent. ## Blocked by None — can start immediately. ## Further notes Respecter l’ADR 0006 et les termes Planning horizon et Last planning date. Les suites CalendarSettingsService, UserSettings, UserInputService, CalendarService et CalendarYear fournissent les points d’appui. La projection des jours fériés du calendrier ne charge actuellement que deux années : couvrir toutes les années fait partie de cette tranche. Les objectifs du planificateur et les familles de règles restent inchangés. Aucun pré-refactoring indépendant n’est nécessaire.

gitlab-35-issue-57.md

1.4 KiB

gitlab-35-issue-57.json

12 KiB

nessar commented

2026-10-05 11:43:17 +02:00

(Migrated from 172.24.0.1:8928)

mentioned in issue #59

nessar commented

2026-10-05 15:34:13 +02:00

(Migrated from 172.24.0.1:8928)

mentioned in commit 2edf2004f5

mentioned in commit 2edf2004f56f8a453a691846f3c0e6d960e27911

nessar (Migrated from 172.24.0.1:8928) closed this issue

2026-10-05 15:34:28 +02:00

gitea-emergency commented

2026-10-11 22:11:12 +02:00

Preserved GitLab #57 history: source attribution, exact timestamps, discussion grouping and review positions. Historical diff snapshots: 0; visible source notes: 2.

gitlab-35-issue-57.md (SHA-256 cd317d0adc6f4647974efb94211347367ee8d483e3dfa77b463b1ab33a2601f9)

gitlab-35-issue-57.json (SHA-256 1231efe7f9f2616bd14330247151269566f98a1b880a1eac039d54e6272ae3c5)

Old CI job execution and reports are omitted. Original source files and rollback backups remain protected.

Preserved GitLab #57 history: source attribution, exact timestamps, discussion grouping and review positions. Historical diff snapshots: 0; visible source notes: 2. [gitlab-35-issue-57.md](https://gitea.nessar.fr/attachments/8376a36b-1ebe-4c30-a147-37aebe949689) (SHA-256 `cd317d0adc6f4647974efb94211347367ee8d483e3dfa77b463b1ab33a2601f9`) [gitlab-35-issue-57.json](https://gitea.nessar.fr/attachments/b77a9767-28d5-4a07-8230-98ae30f0749b) (SHA-256 `1231efe7f9f2616bd14330247151269566f98a1b880a1eac039d54e6272ae3c5`) Old CI job execution and reports are omitted. Original source files and rollback backups remain protected.

gitea-emergency referenced this issue

2026-10-11 22:11:12 +02:00

Calculer les horizons longs sans arrêt automatique #59

gitea-emergency referenced this issue

2026-10-11 22:11:21 +02:00

Bump @angular/build from 20.3.10 to 21.0.0 #135

gitea-emergency added this to the Development project 2026-10-11 22:14:32 +02:00

gitea-emergency moved this to Closed in Development on 2026-10-11 22:14:32 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nessar/vac-optimizer#57