M-Saison - Solde de la saison

Type : écran « Ma saison », carte d'activité du prisme Collecte & passages de M-Accueil. Persona principal : Marie (savoir ce qu'il lui reste à faire) et Samuel (suivre l'avancement d'un ensemble de points). Parcours couverts : complète P5 - Naviguer dans plusieurs sites et passages et P9 - Regrouper les nuits successives par point. Issues : #2356 (écran), #2355 (campagne), #2525 (participations opportunistes), #2610 (filtre campagne dans l'écran, livré) - chantier #2349.

L'écran répond à une seule question, celle qu'un observateur se pose au milieu de sa saison : qu'est-ce qu'il me reste à faire ? Le protocole demande deux passages par an et par point, dans des fenêtres calendaires (règles métier R3 et R4). L'application connaît la règle et la vérifie déjà ; cet écran est ce qui la restitue.

Un état se décrit, une action se fait. La colonne « Reste à faire » est le cœur de l'écran : « Téléverser la nuit du 22/06 » s'exécute, « Prêt à déposer » demande encore un raisonnement. C'est la seule colonne qui transforme un tableau de suivi en plan de travail.

Maquette principale - saison en cours

Annotations

• Sélecteur d'année (groupeAnnee) : la saison courante par défaut ; les saisons antérieures restent consultables en lecture.
• Résumé d'en-tête (lblResume) : les passages attendus ventilés - faits, à refaire, à réaliser - puis l'échéance de la fenêtre du second passage. La somme des trois vaut le total attendu (5 + 1 + 2 = 8 ci-dessus) : un décompte qui ne ferme pas laisse chercher où sont les manquants, ce qu'une proportion seule (« 5 sur 8 ») faisait. Les nuits hors protocole se comptent à côté, jamais dans le total, et la mention disparaît s'il n'y en a aucune. Ce décompte et les lignes du tableau proviennent de la même source : ils ne peuvent pas diverger.
• La campagne est un filtre, pas une colonne (issue #2355). Une ligne du solde est un point, avec ses deux passages, qui peuvent relever de campagnes différentes : une colonne aurait dû en choisir une à afficher. Le filtre retient un point dès qu'au moins un de ses passages relève de la campagne, et le montre en entier - c'est l'état complet du point qui dit ce qu'il reste à y faire. Le sélecteur Campagne (choixCampagne) est posé à côté de celui de l'année. Il n'apparaît que s'il y a une campagne à proposer : coupée la fonctionnalité, ou aucune campagne créée, il est retiré de la mise en page (managed=false) et non simplement masqué - sans quoi il laisserait un trou dans la barre. Sa présence se lie à la liste des campagnes plutôt que de se décider au montage (#3544) : la première campagne peut naître ailleurs - depuis la modale de rattachement d'un passage - et le sélecteur doit alors reparaître au retour sur l'écran, sans redémarrage.
• Deux filtres s'ajoutent aux sélecteurs, sans les remplacer (issue #3103, chantier #3092). Cet écran est le seul tableau de l'application à ne pas prendre la barre à puces du socle, et c'est délibéré : une saison est une année et une campagne, et garder ces deux sélecteurs toujours visibles donne la lecture immédiate « je suis sur telle saison » qu'une puce parmi d'autres ferait perdre. C'est un tableau de bord, pas une table exploratoire. La limite était ailleurs : sur un jeu conséquent, les deux questions qu'on pose à la liste n'avaient aucune réponse directe. Un champ « Chercher un lieu » (champRechercheLieu) retient les points dont le carré, le nom qu'on lui a donné, le code du point ou la commune correspond ; une case « Reste à faire » (caseResteAFaire) ne garde que les points qui ne sont pas à jour - la raison d'être de l'écran. Ces deux filtres ne touchent que la liste des points : le résumé d'en-tête continue de compter la saison entière. Filtrer change ce qu'on regarde, pas ce qu'il y a à faire (ADR 3092). Les deux existent aussi en ligne de commande (solde-saison --lieu, --reste-a-faire), sur la même écriture de la règle.
• Colonnes « Nom du carré » et « Commune » (colNomSite, colCommune, chantier #3151) : le lieu se montre là où il se cherche. Le champ « Chercher un lieu » retenait une ligne sur le nom du carré (#3219) puis sur la commune, et cet écran n'ayant pas de puce « Lieu » - contrairement aux quatre autres tableaux - ces deux valeurs n'apparaissaient nulle part : on trouvait sans voir pourquoi (ADR 3151). Les deux cellules restent vides quand il n'y a rien à dire - un carré sans nom, un point dont la commune n'est pas résolue - comme « Hors protocole » quand aucune nuit opportuniste n'existe. La forme de ces colonnes s'est jouée sur des captures, pas sur un raisonnement. Qualifier « Carré » en « 640380 · Vallon », comme les entrées de puce des autres écrans, paraissait évident : l'aperçu régénéré montrait « 640380 · … ». Il a fallu une colonne dédiée, puis élargir l'aperçu, pour que le nom et « Reste à faire » tiennent ensemble. Le croquis ci-dessus, lui, date d'avant ces deux colonnes.
• Colonne « Hors protocole » (colHorsProtocole, issue #2525) : les nuits opportunistes réalisées sur ce point. Elles ont leur colonne précisément pour ne pas occuper celle d'un passage attendu : les voir en « Passage 1 » se lirait « le passage 1 est fait » alors que la ligne réclame encore de poser l'enregistreur (ligne 3 de la maquette). Les colonnes de passage restent donc sur « Non planifié » tant que le passage du protocole manque réellement, et ces nuits ne comptent pas dans le décompte (R34).
• Colonnes Passage 1 et Passage 2 (colPassage1, colPassage2) : l'état du passage et sa date, ou son absence. Les états et leurs couleurs sont repris du modèle existant ; l'écran ne crée pas un second vocabulaire de statuts, ce qui obligerait l'utilisateur à en apprendre deux.
• Un passage inexploitable compte comme restant à faire : c'est le cas où un décompte naïf induit en erreur, puisque le passage existe en base mais ne vaut rien pour le protocole.
• Colonne « Reste à faire » (colResteAFaire) : le cœur de l'écran. Elle formule une action, pas un état. Elle est vide (« rien ») quand le point est à jour.
• Signalement de fenêtre (lblFenetre) : une ligne indique combien de points ont une fenêtre calendaire proche de la clôture. L'application signale, elle n'alerte pas : elle ne pose pas de rappel et ne planifie pas de sortie terrain.
• Barre de statut : saison courante, travail restant, avancement global.

Variante - aucun passage cette saison

Un observateur qui ouvre l'écran en début de saison, ou qui vient de déclarer ses premiers points, doit y trouver par où commencer plutôt qu'un tableau vide.

Interactions clés

Élément	Action
Double-clic sur une ligne	Ouvre le passage concerné, ou le point s'il n'existe pas encore de passage
Clic sur une pastille d'état	Ouvre le passage correspondant
Changement d'année	Recharge le solde pour la saison choisie, en lecture pour les saisons passées
Survol de « Reste à faire »	Infobulle : la règle de protocole qui fonde cette action (R3 ou R4)
Aucun passage	État vide expliquant par où commencer, avec l'accès direct à l'import

Notes pour l'implémentation

• Les règles restent dans passage/model/ServicePassage : l'écran les consomme, il ne les réimplémente pas. C'est la condition pour que R3 et R4 n'existent pas en deux exemplaires divergents.
• Carte d'accueil via le contrat ActiviteAccueil et le prisme Collecte & passages, sans toucher au chrome (M-Accueil).
• Rafraîchissement : le tableau et le résumé se recalculent quand les données changent. Le défaut déjà signalé sur les compteurs d'accueil (#1376) ne doit pas se reproduire ici. Cette exigence était plus ancienne que le moyen de la tenir : l'écran a d'abord rechargé au retour de navigation, faute de mieux, ce qui laissait passer tout ce qui survenait pendant qu'on le regardait. Il suit désormais le signal de mutation du socle, et l'exigence est tenue au sens propre.
• TableView avec une cellFactory pour les pastilles d'état, réutilisant les couleurs de statut existantes de M-MultiSite.
• Icônes : FontIcon Ikonli, pas d'emoji (règle #700).
• Fonctionnalité optionnelle : l'écran doit rester cohérent quand la campagne est désactivée. Le service la consomme en Optional<ServiceCampagne> ; coupée, aucun point ne relève d'une campagne et le solde reste entier. Le futur sélecteur (#2610) ne doit alors pas apparaître.
• Carrés d'un tiers exclus : le solde ne parle que des carrés de l'observateur. Un carré rattaché à quelqu'un d'autre (R35) sort entièrement du tableau - y participer est une occasion, pas une obligation de protocole.