T3227 - Golden ticket - New info about survival program for churches in odoo

[danpa32]

The first golden ticket! 😀

The purpose was to add information about survival sponsorship for a supporter. For a church, the information is an aggregation of data using the church data and its members. For a member, it is only his/her data that are used.

Screencast.From.2026-06-17.08-07-47.mp4

[gemini-code-assist]

Code Review

This pull request introduces survival sponsorship reporting and metrics by extending the res.partner model and adding corresponding views. The review feedback focuses on security and performance improvements: specifically, replacing raw SQL queries with Odoo's ORM in res_partner.py to ensure security rules, multi-company filters, and active record filtering are respected, and optimizing member ID iteration in contracts_report.py to reduce recordset instantiation overhead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[greptile-apps]

Confidence Score: 3/5

Merge should wait until the CSP report aggregation handles inactive contracts and refunded invoice flows correctly.

The changes are localized and understandable, but the new report metrics can display materially incorrect impact and donation totals in common operational states.

survival_sponsorship_compassion/models/contracts_report.py

T-Rex Logs

What T-Rex did

• Reproduced the draft CSP previous_countries behavior by running a focused harness that imports the PR's contracts_report.py and exercises the _fetch_sponsorship_stats method with a synthetic draft CSP contract row.
• Verified that refunds stay counted by running a minimal database harness that creates a CSP contract, a paid out_invoice line for 120, and a paid out_refund reversal pointing to that invoice, and then executing the same donation stats SQL shape to observe totals.
• Compared survival report metrics before and after the code changes, and after the update the head computes church metrics count=3, donation=2976.0, moms=4.0, countries KE, RW, TZ; member-only metrics count=1, donation=1488.0, moms=2.0, countries RW; and the status is PASS=True.
• Verified the UI stat button extension is present in head after the change; field present=True, method present=True, view button present=True; church count is 2 with actions resolving contracts [101, 102] and member count is 1 with action resolving [102], excluding inactive and unrelated active CSP contracts.

_{Ran code and verified through T-Rex}

_{Reviews (11): Last reviewed commit: "Please greptil, stop adding things" | Re-trigger Greptile}

[ecino]

Thank you for addressing this Golden Ticket and for the good work! Please check my comments. You need as well to run pre-commit on your end (in your python virtual environment):

pip install pre-commit
pre-commit run -a

[ecino]

👍 LGTM

[NoeBerdoz]

Thanks for your work @danpa32!

Here is my review, there is a few things to fix before we can merge it:

1. The "moms supported for 1 year" calculation:

The spec asks for lifetime donations: "the number of CSP donation … (lifetime)" and "even though some sponsorships already ended". It is confirmed with the calculations done from email Mirco's own examples that takes in account an 18-month sponsorship that
"then stopped" and "a one time donation."

The 12-month window implemented drops those cases. The 1 year parameter here stands for the divider ÷744 which represents 62 CHF (1 mom sponsorship) * 12 (months). It represents one mom for one year denominator.

Analogy: "I've paid 10,000 CHF in rent over the years, rent is 744CHF/year; so I've covered 13.44 years of rent." You sum all the rent you ever paid and divide by the yearly rate. You don't restrict the 10,000 CHF to the last 12 months, but the answer is still expressed "in years," because you divided by a yearly rate.

2. The 62.0 value in monthly_cost

Your intent of declaring "use the product price, fall back to 62 if it's not set" is wrong. Odoo by default puts a default price of 1.0 on a new product. Relying on list_price is the correct direction in my opinion, but you can drop the 62.0 hard value fallback and you need to ensure that the data reflects our business data by seeding the key price in a data file /data/survival_product_template.xml is the great candidate here.

3. The wanted results was presented as decimal, not integer

sr_nb_moms_supported_for_a_year is declared as an Integer, and the compute does int(total / annual). Mirco in his examples wants decimal (ex. 13.44). rounding the count is also not optimal when dealing with <1 values, as 0.X will show 0.

4. Not sure about this one, but survival-sponsorship count looks computed twice

The same number ends up in two fields right? survival_sponsorship_count in res_partner.py and sr_survival_sponsorship_count in contracts_report.py (for the report, via the raw SQL). This it's not an issue point, but more a maintainability consideration, if that definition changes later for whatever business rules reason, it has to be updated in both places, might be worth considering extracting the rule into a single helper that both fields use.

5. Relabeling drops the existing translation

Renaming sr_sponsorship from "Number of sponsorship" to "Number of child sponsorships" may change a translatable string, so the existing fr/de/it translations (if existent) for that label will be lost if the .po files are not updated.

[greptile-apps]

Translations no longer match

The field label now uses the source text Number of child sponsorships, but the updated German/French/Italian PO entries still have msgid "Number of sponsorship". Odoo matches translations by the source msgid, so those edited msgstr values are orphaned and users in those languages will see the new English label instead of the translated text. Please regenerate or update the PO entries for the new source string.

Artifacts

Repro: focused translation lookup script

• Contains supporting evidence from the run (text/x-python; charset=utf-8).

Repro: translation lookup output showing English fallback

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.

[greptile-apps]

Draft countries counted

This branch puts every non-active CSP contract with a csp_country into previous_countries. Draft and waiting contracts can already have a country through their contract line, but they have not impacted that country yet. When support staff prepares a CSP contract that is never paid, the sponsorship report can still show that country under “Countries previously impacted”. Please restrict this to contracts that actually had support activity, such as cancelled/terminated contracts with an activation/start marker.

Artifacts

Repro: focused harness for draft CSP previous_countries

• Contains supporting evidence from the run (text/x-python; charset=utf-8).

Repro: harness execution output showing draft country in previous_countries

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}

[greptile-apps]

Refunds stay counted

The donation total only includes paid out_invoice moves, so refunded or reversed CSP invoices are never subtracted. If a supporter pays a CHF 744 CSP invoice and that invoice is later refunded, the original paid invoice still matches this query and the report still counts one year of support. The total should net out refunds/reversals or exclude reversed invoices so sr_total_donation_for_csp and the moms-supported metric do not stay inflated.

Artifacts

Repro: database harness creating paid CSP invoice and refund then running the donation stats SQL

• Contains supporting evidence from the run (text/x-python; charset=utf-8).

Repro: verbose harness output showing refund fixture rows and unexpected positive total

• Keeps the command output available without making the summary code-heavy.

_{Ran code and verified through T-Rex}

[NoeBerdoz]

Great job @danpa32, thank you very much!