T3165 ADD FCP reservations

[ecino]

No description provided.

[gemini-code-assist]

Code Review

This pull request introduces support for FCP Intervention Reservations, adding fields, views, and GMC actions to handle creating, updating, and cancelling reservations, as well as converting them to holds. The code review identified several critical issues: newly created messages in handle_reservation are left unprocessed; potential AttributeError exceptions could occur in reservation_to_hold and intervention_hold_removal_notification due to unsafe dictionary access; overriding write in compassion_reservation.py may lead to duplicate GMC messages; and comparing a Many2one field (category_id) directly to a string in XML attrs will fail.

[greptile-apps]

Confidence Score: 4/5

Safe to merge with one fix: reservation_to_hold() triggers an unintended outgoing hold update every time a reservation converts to a hold.

Adding hold_expiration_date to hold_fields makes reservation_to_hold() unconditionally fire update_hold(), dispatching a spurious outgoing hold-update API call on every incoming reservation-to-hold conversion. Before this PR the trigger was conditional; now it is guaranteed. The rest of the change is correct.

intervention_compassion/models/compassion_intervention.py — specifically the reservation_to_hold() method and its interaction with hold_fields / update_hold().

Important Files Changed

Filename	Overview
intervention_compassion/models/compassion_intervention.py	Adds reservation_id, hold_expiration_date, capacity computed fields, reservation_to_hold(), cancel_reservation(), and hold_sent() override; hold_expiration_date in hold_fields causes an unconditional outgoing update_hold() call when processing the InterventionReservationToHold notification.
intervention_compassion/models/compassion_reservation.py	New model extending compassion.reservation with fcp_intervention type, service_level integer, and handle_reservation override that appends FCP-specific gmc.message records; logic looks correct per the auto_process comment.
intervention_compassion/wizards/hold_wizard.py	Adds action_type (hold/reservation) selection, hold_expiration_date/reservation_id wizard fields, and conditional action routing in make_hold(); hold_sent writes state=on_hold unconditionally for both action types (addressed in previous review thread).
intervention_compassion/data/gmc_action.xml	Adds GMC actions for intervention and FCP reservations (create/update/cancel) plus incoming expired and reservation-to-hold notifications; cancel action mapping reference was fixed relative to earlier review.
intervention_compassion/data/compassion_mapping.xml	Adds mapping records for FCP reservation and intervention reservation CRUD; record id has a typo (intervetion) that is used consistently so it causes no runtime error.
child_compassion/models/compassion_reservation.py	Adds service_level to sync_fields, guards message creation with if action:, renames reservation_id field label; straightforward and correct.

_{Reviews (2): Last reviewed commit: "T3165 ADD FCP reservations" | Re-trigger Greptile}

[greptile-apps]

Incoming notification triggers unconditional outgoing hold update

reservation_to_hold always writes hold_expiration_date: False to the intervention. Because hold_expiration_date is now listed in hold_fields, the write() override sees it in vals and unconditionally sets update_hold = True. After super().write() completes, hold_id is populated from the mapped notification data while reservation_id is False, so update_hold() dispatches a live intervention_update_hold_action message to the Connect API every time this incoming notification is processed. Before this PR, update_hold() was only triggered if the notification payload happened to include ExpirationDate; now it fires unconditionally. The write should use with_context(hold_update=False) the same way hold_sent does in the wizard.