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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
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
mentioned in issue #72
mentioned in issue #73
changed the description
mentioned in issue #75
mentioned in commit
6811142299mentioned in merge request !189
mentioned in commit
0d900fd72dPreserved 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.