T3491 together donation fixes

[danpa32]

T3491 — Fix failing quality test: TOGETHER donation

Related PR and ticket

CompassionCH/compassion-modules#2166

Linked to T3464 (same quality test, merged).

Failing steps

• Step 6: after the payment, the donor lands on /shop/confirmation instead of /together/donation/confirmation.
• Step 11: the donor gets the thank-you letter of the product instead of "Crowdfunding - Donation successful".
• Step 13: no notice is generated for the participant of the project.

Root causes

Step 6. crowdfunding_compassion/data/website_redirect.xml redirects /shop/confirmation with a 301 website.rewrite. In core (v14 and v18), 301/302 rewrites are only served by ir.http._serve_fallback(), i.e. for URLs matching no route. /shop/confirmation is a real route, so the rewrite never applies. website_event_compassion and my_compassion already override the route for their own orders.

Step 11. "Crowdfunding - Donation successful" is archived in the configuration (send mode "none", since 2025-12-01, same in v14), so the product thank-you letter is the expected communication with the current configuration. Independently, generate_crowdfunding_receipt fails when the rule is active: the templates "Donation successful" and "Donation received" only live in the database (the XML holds a placeholder, noupdate), and the v14 → v18 conversion left t-out="invoice.amount_total | int" (Jinja filter → TypeError), German/French/Italian bodies never converted (raw % set / ${...}, in some even translated Jinja keywords), and wrong subjects.

Step 13. The notice (event.ambassador_config_id) is only created for invoice lines with an event_id. crm_compassion.account_move_line._compute_event() only read the root plan column (account_id) and the crm_compassion.plan_events column; the analytic accounts of TOGETHER and other migrated events are in the DB-only "Legacy" plan, so event_id stayed empty. (Separately, the participant of the project used in the test opted out of donation notices, ambassador_receipt_send_mode = none, as in v14.)

Changes

compassion-website:

• 9adf4b8 — Show the TOGETHER thank-you page after a project donation: /shop/confirmation override redirecting confirmed orders with a participant_id line to /together/donation/confirmation; other orders go to super() (event donations, MyCompassion, standard shop).
• 45ce8af — Repair the TOGETHER donation email templates: post-migration rewriting body and subject of both templates in QWeb for en/de/fr/it, keeping their wording. The participant notice sums only its own lines (a cart can hold donations to several projects); the donor receipt names every project of the invoice.
• 50e7df9 — Keep the TOGETHER donation receipt pending: created with auto_send=False, the donor already receives the product thank-you letter.

How to test

Test in the new Odoo (v18), with a copy of the data (locally stage18_neutralized, or staging crowdfunding.compassion.ch). The fixes are on two branches: T3491-together-donation-fixes (compassion-website) and T3491-event-any-analytic-plan (compassion-modules). Module crowdfunding_compassion must be upgraded (-u crowdfunding_compassion) so that the corrected email texts are installed.

Choose a project whose participant receives donation notices, for example the project linked to the event "Courir pour donner accès à l'eau potable" ("Toilets for all"). The participant of "Vocational Training Burkina Faso" chose not to receive notices, so step 13 can't be tested with that project.

Step 6 – Page after the payment

1. Open the TOGETHER website (staging: https://crowdfunding.compassion.ch; locally, choose "TOGETHER - Compassion" in the website switcher of the backend first).
2. Open the project, click Donate, choose an amount and complete the checkout and the payment.
3. Expected: after the payment, the address bar shows /together/donation/confirmation and the TOGETHER thank-you page is displayed ("Thank you! Your donation helps release children from poverty!"). Before the fix, it was the shop page /shop/confirmation.
4. Check that a normal shop order or an event donation still ends on its usual confirmation page (not affected by the change).

Locally, only the PostFinance payment method is enabled, so the payment itself is easier to test on staging (test payment), or locally after enabling a test payment provider.

Step 13 – Notice to the participant

1. Backend: Events > Crowdfunding > Projects, open the project, click Donations, open your donation.
2. Expected: the donation line has the Event of the project filled in (before the fix it stayed empty).
3. Open the participant (Events > Crowdfunding > Participants, or from the project), open the partner and click Communications.
4. Expected: a communication "Crowdfunding - Donation received" is there, with the subject in the participant's language ("Du hast eine Spende erhalten!", "Vous avez reçu un don !", "Hai ricevuto una donazione!", "You received a donation") and a readable text (amount, donor name unless the donation is anonymous, link to the project).

Two projects in the same cart: donate to two TOGETHER projects in one checkout (e.g. 25 CHF and 30 CHF). Expected: each participant's notice shows only the amount given to their own project (not the total of the order).

The communications are created by background jobs a few seconds after the payment: if nothing appears, check Job Queue > Queue > Jobs (the job runner must be running).

Step 11 – Thank-you letter of the donor

1. Open the donor partner and click Communications.
2. Expected with the current configuration: the thank-you letter of the product (e.g. "Donation - Vocational Training Burkina Faso" or "Donation - Thank You"). "Crowdfunding - Donation successful" is not created, because it is archived since 1 December 2025 (Sponsorship > Communications > Communication Rules, filter archived).
3. Optional, to check the corrected text of "Crowdfunding - Donation successful" (only on a test copy): temporarily unarchive the rule, make a new donation, open the donor's communications. Expected: "Crowdfunding - Donation successful" is created pending (not sent), with a readable text in the donor's language (amount, project name). Archive the rule again afterwards.

[greptile-apps]

Confidence Score: 4/5

[High risk] Fixes donation email templates and payment confirmation routing.

The outstanding German receipt issue should be fixed before merging.

Findings

1.  German receipt cannot render ▶

_{Reviews (2) · Last reviewed commit: "[T3491] Declare the TOGETHER donation ru..."}

[greptile-apps]

German receipt cannot render

If the pending donor receipt is enabled for a German-speaking donor, these expressions pass strip_html=True, but the shared get_snippet method accepts only a snippet name. Rendering raises TypeError, so the receipt cannot be produced. Remove the unsupported argument or use a supported way to strip the returned text.

Artifacts

Source of the snippet contract check

• The authored script extracts the German template expressions and executes the shared method body with a stubbed lookup, showing exactly how the contract was tested.

Contract-compatible snippet calls

• The executed control omits the unsupported keyword and returns snippet text for both names, establishing the working comparison.

PR snippet calls with strip_html

• The executed PR expressions each raise an unexpected-keyword TypeError, supporting finding 1.

_{Ran code and verified through T-Rex}

[danpa32]

False positive: this links to the default branch (14.0), where get_snippet(self, snippet_name) has no strip_html. This PR targets 18.0, where the signature is get_snippet(self, snippet_name, strip_html=False) (partner_communication/models/communication_job.py). The German receipt was rendered with these snippets during testing, and other migrated v18 templates use the same call. No change needed.

[greptile-apps]

You’re right — this was a false positive caused by checking the default (14.0) branch. In v18, get_snippet accepts strip_html=False, so the German template calls are valid. No change is needed.