spp_case_base: is_current lacks tracking=True — a plan losing current status never reaches the chatter

[kneckinator]

Filed at origin/19.0 (f6213293). From @gonzalesedwin1123's review of #478 (fixes #458) — did not block that PR.

Summary

spp.case.intervention.plan inherits mail.thread (spp_case_base/models/case_intervention_plan.py:10) and tracks most of the fields that matter: name (:18), case_id (:26), start_date (:67), target_end_date (:71), state (:91), approved_by_id (:99), approved_date (:104).

is_current (:36-40) is not tracked:

is_current = fields.Boolean(
    string="Is Current Plan",
    default=True,
    help="Whether this is the current active plan for the case",
)

Impact

A plan losing current status never reaches the chatter, so the audit trail records that a plan was completed or revised but not that it stopped being the case's plan of record. Those are separate facts: after #478 they coincide on the completion path, but they do not on the revision path (action_create_revision writes both, :207-211), they do not for a direct write, and current_plan_id / has_active_plan are non-stored computes (models/case.py:265-270) so neither leaves a trace of its own anywhere.

The field also drives real UI — the "Current Plan" ribbon (views/case_intervention_views.xml:63), the list decoration (views/case_views.xml:223) and the "Current Plans" search filter (:284) — so "why is this plan no longer showing as current?" is a question the chatter should be able to answer and currently cannot.

Now more visible than before #478: completion is by far the most common way a plan stops being current, and it is the transition that previously left the flag alone.

Suggested fix

is_current = fields.Boolean(
    string="Is Current Plan",
    default=True,
    tracking=True,
    help="Whether this is the current active plan for the case",
)

No migration needed — tracking only affects messages written from that point on. Tracking values are posted per write, and both action_complete and action_create_revision set state and is_current in a single write(), so each transition produces one message with both changes rather than two messages.

If the field becomes derived or read-only per #499, this should be revisited alongside it: a stored compute still tracks, but the ordering relative to the triggering write differs.

Tests

• Completing a plan posts a tracking value for is_current (plan.message_ids / mail.tracking.value on the resulting message).
• Creating a revision posts the demotion on the original.