T3389-FIX-INVOICE_BUTTON

[loris-fab]

⚠️ PR liée : CompassionCH/compassion-accounting#283 — même ticket, même nom de branche. À merger ensemble. Celle-ci dépend de la méthode _get_open_invoices() introduite là-bas ; seule, elle ne fonctionne pas.

Goal

Complément du correctif T3389 pour les contrats Child Gift (type == "G").

Ces contrats ne portent pas leurs factures : quand un cadeau est facturé, build_inv_line_data rattache la ligne de facture au parrainage lié, pas au contrat cadeau. Sans traitement particulier, leur bouton afficherait donc toujours 0.

Ce module compensait, mais à deux endroits différents et avec deux critères différents — d'où un compteur et une liste qui ne pouvaient pas coïncider.

Technical aspect

Deux rustines supprimées, remplacées par une seule surcharge du point d'extension créé dans compassion-accounting.

• Supprimé dans _compute_invoices : contract.nb_invoices += len(gift_invoices). Ce code incrémentait un entier sans que les factures correspondantes existent dans un recordset — le bouton annonçait donc un nombre que rien ne pouvait afficher. Structurellement incompatible avec l'objectif « compteur = liste ».
• Supprimé : la surcharge de open_invoices(). Elle faisait res["domain"] = [...], ce qui remplaçait le domaine du parent : les factures propres au contrat cadeau disparaissaient de la liste. Et son filtre était invoice_category == "gift" seul, sans aucun filtre d'état ni de paiement — la liste contenait donc aussi les cadeaux payés, annulés et brouillons.
• Ajouté : _get_open_invoices(), qui pour les contrats G ajoute (union, pas remplacement) les factures de cadeau du parrainage lié, filtrées par le critère commun _filter_open_invoices(). Compteur et liste consommant tous deux cette méthode, ils ne peuvent plus diverger.
• @api.depends complété : le compteur d'un contrat cadeau dépend des lignes de facture d'un autre contrat (le parrainage). Ce chemin n'était déclaré nulle part, donc l'encaissement d'un cadeau ne rafraîchissait pas le compteur.

Ce qui change pour l'utilisateur

Sur un contrat Child Gift :

	Avant : compteur	Avant : liste	Après : les deux
cadeaux du parrainage, ouverts	✅	✅	✅
cadeaux du parrainage, payés / annulés	✅ / ❌	✅	❌
ses factures propres, postées impayées	❌	❌ jamais visibles	✅

Le seul changement visible côté métier : les cadeaux payés ne sont plus dans « Open invoices ». Ils restent accessibles par le bouton « Gifts » juste à côté, qui n'est pas modifié.

Misc

• ⚠️ Cette branche contient aussi le commit 991953ef du ticket T3399 (« Child picture printing crash »), pas encore mergé dans 18.0. Il n'a aucun rapport avec T3389 — à merger dans le bon ordre, ou à rebaser une fois T3399 parti.
• Un cadeau impayé n'apparaît pas dans « Gifts » : l'enregistrement sponsorship.gift n'est créé qu'au paiement de la facture (invoice_paid → _trigger_gifts). Les deux boutons sont donc complémentaires — facture ouverte avant paiement, cadeau après. Exception : avec l'option no_birthday_invoice, le cadeau est créé sans facture et n'apparaît que dans « Gifts ».
• Le bouton du groupe n'affiche pas les cadeaux d'un contrat cadeau si le parrainage est dans un autre moyen de paiement. Volontaire : le groupe répond à « qu'est-ce qui sera encaissé par ce moyen de paiement ? », et cette facture sera encaissée par celui du parrainage. L'afficher des deux côtés rendrait le recouvrement ambigu.
• Les filtres contextuels open_invoices_sponsorship_only / open_invoices_exclude_sponsorship sont inchangés : ils portent sur open_invoice_ids, qui reste réservé au métier (génération de cadeaux, cascade d'écriture).
• Aucun test automatique n'existe sur ce module ; validation manuelle sur base V18.

[loris-fab]

Remplacée par #2141, qui repart de 18.0 et ne contient que le commit T3389 (celle-ci embarquait aussi le commit du ticket T3399, sans rapport).