[danpa32]

[STAGING REQUIRED] Must be tested on Stage prior to production merge.

T3523 - Tours & Visit / Muskathlon registration process (re-applied, with T3572 and the demo changes)

Branches T3523-tours-visit-registration-2, based on 18.0:

• compassion-website (website_event_compassion, muskathlon)
• compassion-switzerland (website_switzerland)
• compassion-modules (partner_communication), branch T3523-tours-visit-registration

The PRs of the three repositories go together: merge them into stage together, and into 18.0 together.

• compassion-website: [T3523] Tours & Visit / Muskathlon registration process (re-applied, with T3572 and the demo changes) #445
• compassion-switzerland: [T3523] Tours & Visit / Muskathlon registration process (re-applied, with T3572 and the demo changes) compassion-switzerland#1887
• compassion-modules: [T3523] Preview communication templates on a communication that uses them compassion-modules#2200

It replaces the T3572 PRs to stage (#435, CompassionCH/compassion-switzerland#1869), whose commits are included.

Why a new PR

The first T3523 PRs (#423 in compassion-website, #1856 in compassion-switzerland) were merged into 18.0, then reverted there ("REM T3523"), and kept on stage only. T3572 (#435, #1869) was opened against stage on top of them. Following the staging process, this PR brings the whole feature back to 18.0 as one Draft PR per repository:

1. T3523 as tested on stage, in one commit per repository. It is the content of stage, with its migrations numbered after T3569 (muskathlon) and T3651 (website_switzerland 18.0.1.0.11). The full description of this part is in the first PRs (T3523 tours visit registration #423, #1856).
2. T3572, the protection of the participant documents, flights and forms, and the mails signed by the event responsible: the commits of T3572 protect participant documents #435 and #1869, unchanged. Their description is in those PRs.
3. The changes asked at the demo of the registration process with the business (below).

Nothing else from stage is included.

Changes asked at the demo

Flights: one page per direction, with connection flights

Before, the "Give outbound flight" and "Give return flight" tasks both opened the same page, which held one flight per direction.

• Each direction has its own page: /my/events/<registration>/flight/outbound and /flight/return. The task of each direction opens its page.
• The page lists the flights already given for that direction (company, number, departure, arrival). The participant can add as many connection flights as needed, and remove one.
• The rule "one flight per registration and direction" is dropped (website_event_compassion 18.0.1.6.6 removes the database constraint).
• Removing the last flight of a direction unticks its task (muskathlon and website_switzerland event.flight.unlink()).
• Removing a flight goes through /my/events/flight/<id>/remove, which checks that the flight belongs to the logged-in participant, as the other participant forms do since T3572.
• The task buttons of the registration page used a relative link (../tasks/<task>), which pointed to a page that doesn't exist from the flight pages. The task, "Fundraising tools" and "Edit profile" links are now absolute.
• New texts are translated in French, German and Italian.

Criminal record: moved by hand

Before, the registration moved to Criminal record by itself, which sent the criminal record request.

• Group visit: after paying for the trip, the registration stays in Trip paid.
• Muskathlon: after the documents, the registration stays in Fill documents.
• The person responsible moves the participant to Criminal record by hand, which sends the request as before. Both stages are now "set by hand only" (migrations muskathlon 18.0.1.1.6 and website_switzerland 18.0.1.0.17, since the stage data is noupdate).

Muskathlon tasks already done

A participant who signed the child protection charter for a group visit was asked to sign it again in the Muskathlon, and the charter page only showed "thank you" since the charter was already signed. When a task is created, website_switzerland ticks the tasks whose information the participant already gave (account activated, charter signed, passport, flights, recent criminal record), but it only checked the group visit tasks. It now checks the Muskathlon tasks too.

"Propose sponsoring children" could not be previewed (compassion-modules)

The preview of a communication's mail template took the first communication found, whatever its rule. The group visit template "Propose sponsoring children" uses the trip of the communication's registration, so it failed on a communication of a partner ('res.partner' object has no attribute 'compassion_event_id').

• The preview now takes a communication of a rule that uses the template.
• When no communication uses the template yet, the preview says so ("No communication uses this template yet. Choose one in Record to preview it.") instead of failing. Another communication can still be chosen in Record.
• Translated in French, German and Italian.

Side finding, not changed: the English text of that template is in French.

Deployment

• Upgrade together: website_event_compassion, muskathlon, website_switzerland, report_compassion and partner_communication.
• Do not run --i18n-overwrite on website_switzerland or muskathlon: their .po files still hold old mail bodies. A plain -u is safe.
• Stage already has the first T3523 and T3572: when this branch is merged into stage, the migrations that already ran there are not run again. Only website_event_compassion 18.0.1.6.6, muskathlon 18.0.1.1.6 and website_switzerland 18.0.1.0.17 are new for stage.

Testing

• Automated tests:
  • website_switzerland TestParticipantAccess: flight pages per direction, a participant removes their flight, a participant cannot remove another participant's flight, connection flights kept.
  • website_switzerland TestMuskathlonJourney: the registration waits in Fill documents until moved by hand to Criminal record; a charter signed before is ticked when its task is created.
  • website_switzerland group visit journey: updated to wait in Trip paid. These tests already fail on stage without these changes (new registrations stay in Unconfirmed and never get the "Pay fees" task). This is not caused by this PR and is still to investigate.
  • partner_communication TestTemplatePreview: the preview uses a communication of the template's rule, and says when there is none.
• Manual test:
  • Muskathlon registration in Flights: outbound page, two flights added, one removed, switch to the return page from the task buttons.
  • Registration whose participant had signed the charter for a group visit: the charter task is ticked when the registration reaches Fill documents.
  • Preview of "Propose sponsoring children" from the communication rule.

How to test on stage

1. Merge the three branches into stage and upgrade the modules above.
2. Take a registration in Flights. Open "Give outbound flight": add two flights, remove one. Open "Give return flight" from the task buttons of that page.
3. Pay a group visit trip: the registration stays in Trip paid. Move it to Criminal record: the criminal record request is sent.
4. Fill the documents of a Muskathlon registration: it stays in Fill documents. Move it to Criminal record.
5. Register to a Muskathlon with a participant who signed the charter for another trip: the charter task is already ticked in Fill documents.
6. Open the communication rule "Group visit: propose sponsoring children" and preview its template.

🤖 Generated with Claude Code