T3389-gift-invoices-counter - #2141
Conversation
nb_invoices was incremented without the matching records while open_invoices() replaced the domain with every gift, unfiltered. Both are replaced by a single _get_open_invoices() override, so counter and list always show the same set.
Confidence Score: 4/5Child Gift invoice retrieval is not safe with the currently available accounting dependency because the new parent-method call raises an exception. The exact override boundary was exercised against the available accounting revision and reproduced the missing-parent exception; the same path completed successfully when run with the companion revision that adds the required API. Files Needing Attention:
 T-Rex LogsWhat T-Rex did
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| build_inv_line_data), so they never show up in the gift contract own | ||
| invoice_line_ids. | ||
| """ | ||
| invoices = super()._get_open_invoices() |
There was a problem hiding this comment.
_get_open_invoices() unconditionally calls super()._get_open_invoices(), but the currently available recurring_contract dependency does not provide that method. Opening or computing invoices for a Child Gift contract therefore raises AttributeError until the companion accounting change is deployed. Deploy and enforce the compatible accounting revision with this module, or retain an implementation that works with the existing dependency.
Artifacts
Focused executable source for the parent-method and gift-contract check
- The authored Python check parses the actual override, checks each dependency revision, and executes the gift-contract super-call boundary; it is the exact source used for the captures.
Captured source and SHA-256 for the focused executable check
- The executed command captured the complete check source and its SHA-256 hash, tying the proof runs to the uploaded script.
Gift-contract execution against the available accounting dependency fails
- The focused check ran against available compassion-accounting revision fcd9a5d and captured the missing parent method plus the resulting AttributeError, confirming the runtime failure.
Gift-contract execution with companion PR 283 parent API succeeds
- The same focused check ran against companion PR [ADD] Webservice for displaying children from the global pool #283 revision c91470b and captured the parent method’s presence plus successful retrieval of one open gift invoice, confirming the required dependency relationship.
There was a problem hiding this comment.
Correct, and intentional : this is a paired change, as stated at the top of the description: PR #2141
cannot work without #283, which introduces _get_open_invoices().
Both PRs carry the same ticket (T3389) and must be merged together.
On the three suggested options:
- Merge/deploy the other PR first : that is the plan, and both descriptions say so.
- Pin the compatible revision in the manifest : not possible: Odoo dependencies are module names
only, with no version constraint, as the comment itself acknowledges. All repositories in this stack
are checked out side by side on branch 18.0 and deployed together, so a cross-repo API addition
consumed by a dependent module is the normal pattern here. - Keep an implementation that works without the parent API (
hasattrguard or fallback) rejected
on purpose. It would silently hide a missing dependency and leave the gift-contract counter wrong
instead of failing loudly. AnAttributeErrorat load time is the correct signal that the stack is
incomplete.
No code change.
2 participants
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_datarattache 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._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 ».open_invoices(). Elle faisaitres["domain"] = [...], ce qui remplaçait le domaine du parent : les factures propres au contrat cadeau disparaissaient de la liste. Et son filtre étaitinvoice_category == "gift"seul, sans aucun filtre d'état ni de paiement — la liste contenait donc aussi les cadeaux payés, annulés et brouillons._get_open_invoices(), qui pour les contratsGajoute (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.dependscomplé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 :
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
sponsorship.giftn'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'optionno_birthday_invoice, le cadeau est créé sans facture et n'apparaît que dans « Gifts ».open_invoices_sponsorship_only/open_invoices_exclude_sponsorshipsont inchangés : ils portent suropen_invoice_ids, qui reste réservé au métier (génération de cadeaux, cascade d'écriture).