Piloter la prévention des pertes depuis les règles #71

Closed
opened 2026-10-08 22:59:05 +02:00 by nessar · 8 comments
nessar commented 2026-10-08 22:59:05 +02:00 (Migrated from 172.24.0.1:8928)

Blocked by: #70

What to build

L’utilisateur crée une règle d’optimisation de prévention des pertes, l’enregistre, la déplace parmi ses préférences et constate son effet sur les congés placés et les soldes restants. La désactiver retire réellement sa priorité automatique.

Première tranche fonctionnelle du modèle commun de l’ADR 0008. Continuer la branche d’intégration du ticket #70 ; l’ajout des six préréglages aux données existantes et la mise en service sont traités au ticket #75. Les scénarios de cette tranche soumettent explicitement leurs règles.

Acceptance criteria

  • Proposer la famille Optimisation dans la liste existante et permettre de créer, nommer, éditer, activer, désactiver, supprimer et réordonner une règle utilisant la somme des soldes à risque non placés. Seul le mode préférence est disponible pour cette famille.
  • L’édition, les résumés et les commandes utilisent le contrat du ticket #70, sont traduits et accessibles au clavier. La configuration complète est sauvegardée localement et restaurée, avec son identité, ses paramètres, son activation et sa position.
  • Le calcul résout les obligations conjointement puis utilise l’ordre des préférences actives pour arbitrer les placements. Placer la prévention des pertes sous une préférence personnelle peut laisser davantage de congés à risque inutilisés ; la remonter restaure sa priorité.
  • Remplacer l’exécution implicite de la prévention des pertes par l’exécution de sa configuration explicite. Mettre en place le parcours ordonné partagé des règles ; aucun objectif n’est ajouté implicitement à une requête pour compenser une règle absente ou une configuration non prise en charge.
  • Une règle désactivée donne le même plan que son absence, à autres entrées identiques. Une requête sans règle active n’ajoute aucun congé, même avec des soldes à risque, et conserve les jours déclarés. Les départages par expiration et dates ne déclenchent aucun placement.
  • Les quantités, disponibilités, expirations, jours éligibles et jours déclarés restent des contraintes de validité. Une configuration active incompatible ou mal formée produit une erreur d’entrée rattachable à la règle, sans devenir un conflit d’obligations ni réactiver un défaut.
  • Les chemins direct et worker conservent tous les paramètres de la règle dans l’instantané du calcul. L’explication, la trace et les analyses contrefactuelles suivent le même ordre actif ; une modification ultérieure dans l’éditeur ne change pas le résultat soumis.
  • Adapter les consommateurs concernés, notamment ceux qui supposent qu’une règle comporte toujours un nombre de jours à poser. L’estimation de durée reste finie et les règles existantes Si… alors… et Période restent utilisables.
  • Les tests de comportement couvrent création et rechargement, déplacement au clavier, priorité inversée contre une préférence personnelle, désactivation équivalente à suppression, absence de règles, entrée invalide et passage par le worker. S’appuyer sur les suites existantes de gestion des règles, de planification et d’instantané immuable.
  • Les fonctionnalités communes de cette tranche sont réutilisables par les familles des tickets #72, #73, #74. Ne pas conserver une exécution historique parallèle comme solution transitoire ; la série est livrée après sa validation commune.

Vérification de bout en bout : Avec un solde à risque et une préférence personnelle concurrente, déplacer la prévention des pertes, recalculer et comparer les placements et soldes ; désactiver ensuite toutes les règles et vérifier l’absence de nouveaux congés.

Blocked by

  • #70 — Unifier l’évaluation et la comparaison des objectifs
Blocked by: #70 ## What to build L’utilisateur crée une règle d’optimisation de prévention des pertes, l’enregistre, la déplace parmi ses préférences et constate son effet sur les congés placés et les soldes restants. La désactiver retire réellement sa priorité automatique. Première tranche fonctionnelle du modèle commun de l’ADR 0008. Continuer la branche d’intégration du ticket #70 ; l’ajout des six préréglages aux données existantes et la mise en service sont traités au ticket #75. Les scénarios de cette tranche soumettent explicitement leurs règles. ## Acceptance criteria - [ ] Proposer la famille Optimisation dans la liste existante et permettre de créer, nommer, éditer, activer, désactiver, supprimer et réordonner une règle utilisant la somme des soldes à risque non placés. Seul le mode préférence est disponible pour cette famille. - [ ] L’édition, les résumés et les commandes utilisent le contrat du ticket #70, sont traduits et accessibles au clavier. La configuration complète est sauvegardée localement et restaurée, avec son identité, ses paramètres, son activation et sa position. - [ ] Le calcul résout les obligations conjointement puis utilise l’ordre des préférences actives pour arbitrer les placements. Placer la prévention des pertes sous une préférence personnelle peut laisser davantage de congés à risque inutilisés ; la remonter restaure sa priorité. - [ ] Remplacer l’exécution implicite de la prévention des pertes par l’exécution de sa configuration explicite. Mettre en place le parcours ordonné partagé des règles ; aucun objectif n’est ajouté implicitement à une requête pour compenser une règle absente ou une configuration non prise en charge. - [ ] Une règle désactivée donne le même plan que son absence, à autres entrées identiques. Une requête sans règle active n’ajoute aucun congé, même avec des soldes à risque, et conserve les jours déclarés. Les départages par expiration et dates ne déclenchent aucun placement. - [ ] Les quantités, disponibilités, expirations, jours éligibles et jours déclarés restent des contraintes de validité. Une configuration active incompatible ou mal formée produit une erreur d’entrée rattachable à la règle, sans devenir un conflit d’obligations ni réactiver un défaut. - [ ] Les chemins direct et worker conservent tous les paramètres de la règle dans l’instantané du calcul. L’explication, la trace et les analyses contrefactuelles suivent le même ordre actif ; une modification ultérieure dans l’éditeur ne change pas le résultat soumis. - [ ] Adapter les consommateurs concernés, notamment ceux qui supposent qu’une règle comporte toujours un nombre de jours à poser. L’estimation de durée reste finie et les règles existantes Si… alors… et Période restent utilisables. - [ ] Les tests de comportement couvrent création et rechargement, déplacement au clavier, priorité inversée contre une préférence personnelle, désactivation équivalente à suppression, absence de règles, entrée invalide et passage par le worker. S’appuyer sur les suites existantes de gestion des règles, de planification et d’instantané immuable. - [ ] Les fonctionnalités communes de cette tranche sont réutilisables par les familles des tickets #72, #73, #74. Ne pas conserver une exécution historique parallèle comme solution transitoire ; la série est livrée après sa validation commune. **Vérification de bout en bout :** Avec un solde à risque et une préférence personnelle concurrente, déplacer la prévention des pertes, recalculer et comparer les placements et soldes ; désactiver ensuite toutes les règles et vérifier l’absence de nouveaux congés. ## Blocked by - #70 — Unifier l’évaluation et la comparaison des objectifs
nessar commented 2026-10-08 22:59:05 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #72

mentioned in issue #72
nessar commented 2026-10-08 22:59:06 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #73

mentioned in issue #73
nessar commented 2026-10-08 23:01:06 +02:00 (Migrated from 172.24.0.1:8928)

changed the description

changed the description
nessar commented 2026-10-08 23:01:10 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #75

mentioned in issue #75
nessar commented 2026-10-10 16:08:37 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in commit 6811142299

mentioned in commit 6811142299b21124af146ac7f8cf02a96c4d91c7
nessar commented 2026-10-10 16:08:49 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in merge request !189

mentioned in merge request [!189](https://gitea.nessar.fr/nessar/vac-optimizer/pulls/267)
nessar commented 2026-10-10 16:56:50 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in commit 0d900fd72d

mentioned in commit 0d900fd72d1a405d257f5a566c55cc0cb3d2bc61
nessar (Migrated from 172.24.0.1:8928) closed this issue 2026-10-10 16:56:50 +02:00

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

gitlab-35-issue-71.md (SHA-256 2ef9cafb4064a7d61db24ac78b5a9efd0ff4fe479302d77f34cf8d891b59f495)

gitlab-35-issue-71.json (SHA-256 cabc2aba4077746348c83e3775907bb2a76fe752469fc01add76ca068107b261)

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

<!-- gitlab-to-gitea-history:35:Issue:71 --> Preserved GitLab #71 history: source attribution, exact timestamps, discussion grouping and review positions. Historical diff snapshots: 0; visible source notes: 7. [gitlab-35-issue-71.md](https://gitea.nessar.fr/attachments/980c8dab-b149-4d58-ac0f-4aa2ef2b407c) (SHA-256 `2ef9cafb4064a7d61db24ac78b5a9efd0ff4fe479302d77f34cf8d891b59f495`) [gitlab-35-issue-71.json](https://gitea.nessar.fr/attachments/4497349a-e0cf-46a3-ad72-d0a0f769c3aa) (SHA-256 `cabc2aba4077746348c83e3775907bb2a76fe752469fc01add76ca068107b261`) Old CI job execution and reports are omitted. Original source files and rollback backups remain protected.
gitea-emergency added this to the Development project 2026-10-11 22:14:33 +02:00
gitea-emergency moved this to Closed in Development on 2026-10-11 22:14:33 +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#71