fix(spp_drims): show only reachable states on the dispatch status bar

[emjay0921]

Why is this change needed?

action_create_dispatch confirms a request dispatch the moment it creates it, so a dispatch never sits in Draft. Both Draft and Waiting were still drawn as greyed-out steps on the form, inherited from stock.picking — visual clutter, and two states warehouse staff can never reach.

How was the change implemented?

Core renders two status bars for stock.picking, split on picking_type_code:

Bar	statusbar_visible	Shown for
incoming	draft,assigned,done	receipts
non-incoming	draft,confirmed,assigned,done	deliveries, internal transfers

A dispatch is outgoing, so it picks up the second one. Rather than editing that shared statusbar_visible — which would have dropped Draft from every non-incoming transfer in the database — this narrows it to exclude dispatches and adds a third, dispatch-only bar:

Picking	Bar
incoming (incl. DRIMS donation receipt)	draft,assigned,done — untouched
outgoing/internal, not a dispatch	draft,confirmed,assigned,done — unchanged
DRIMS request dispatch	assigned,done

The three conditions are mutually exclusive, so exactly one bar renders per picking. There is a test that evaluates the real invisible expressions against four picking shapes to pin that, rather than pattern-matching the attribute strings.

A correction to the ticket's rationale

The ticket states Waiting is unreachable because "stock is already reserved from the allocation step". That is not the case, and it was worth checking before hiding the state. _allocate_stock_fifo only writes quantity_allocated on the request line; it creates no Odoo reservation. So two requests can allocate the same units before either dispatches, and the second finds nothing to reserve. Reproduced on a dev instance:

request A: quantity_allocated=100     request B: quantity_allocated=100
dispatch A: OP86/OUT/00001  assigned   (Ready)    reserved=100.0
dispatch B: OP86/OUT/00002  confirmed  (Waiting)  reserved=0.0

Hiding Waiting is nevertheless safe, for a reason specific to the widget: getAllItems() filters the selection with value === currentValue || visibleSelection.includes(value) (statusbar_field.js), so an excluded state still renders when it is the current one. Waiting therefore disappears only as a greyed-out future step — a dispatch genuinely short of stock still displays Waiting and stays visible to warehouse staff. That is what makes the AC implementable as written.

Both facts are covered by tests (test_dispatch_is_confirmed_on_creation_never_draft, test_waiting_state_is_reachable_for_a_dispatch) so neither gets "simplified" later on a false assumption.

Worth noting for whoever reviews: unlike x2many create/delete, statusbar_visible genuinely is read from the field tag (statusbar_field.js:372, visibleSelection: attrs.statusbar_visible?...), which is why core sets it that way.

New unit tests

spp_drims/tests/test_dispatch_statusbar.py — 5 tests:

• A dispatch-only bar exists listing just assigned,done, correctly conditioned.
• Core's two bars survive apart from the added exclusion, so receipts, deliveries and internal transfers still show Draft and Waiting (AC 2).
• Exactly one bar applies per picking kind, evaluated for dispatch / plain delivery / donation receipt / internal transfer.
• A dispatch is confirmed on creation and never Draft — the premise for hiding Draft.
• Waiting is reachable via the double-allocation race — the premise for hiding it only as a future step.

Unit tests executed by the author

Full module suite:

0 failed, 0 error(s) of 252 tests

All 5 new tests confirmed executing by name in the log. ./spp lint (ruff, ruff-format, prettier) passes on all three files.

Also verified the combined arch on a fresh database: three status bars, with the conditions above.

How to test manually

demo-scripts/ds-openspp2-op1086-spp_drims-20260803-01.py builds one picking per case on a fresh DB, including a dispatch genuinely stuck in Waiting (via the real allocation race, not a contrived write).

Fixture	Expected bar
DRIMS dispatch, Ready	Ready → Done only
DRIMS dispatch, Waiting	Waiting still visible (it is the current state)
Plain delivery	Draft → Waiting → Ready → Done (unchanged)
DRIMS donation receipt	Draft → Ready → Done (unchanged)
DRIMS internal transfer	Draft → Waiting → Ready → Done (unchanged)

Related links

• OP#1086 — Hide unused Draft and Waiting states from DRIMS dispatch status bar

Notes for the reviewer

readme/HISTORY.md and the manifest version are deliberately untouched — per our convention those land on 19.0 after merge, to avoid conflicts between concurrent PRs on the same module.

This branch is independent of #390 (OP#1087) and #391 (OP#1057). It only touches the <header> region of stock_picking_views.xml, whereas #391 touches the Operations field in the same file, so they occupy different hunks and should merge in either order.

🤖 Generated with Claude Code

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.27%. Comparing base (7fff93b) to head (6575a2f).
⚠️ Report is 1 commits behind head on 19.0.

Additional details and impacted files

@@           Coverage Diff           @@
##             19.0     #392   +/-   ##
=======================================
  Coverage   72.27%   72.27%           
=======================================
  Files        1010     1008    -2     
  Lines       60741    60739    -2     
=======================================
  Hits        43900    43900           
+ Misses      16841    16839    -2     

Flag	Coverage Δ
spp_base_common	91.07% <ø> (ø)
spp_drims	80.86% <ø> (+0.03%)	⬆️
spp_drims_sl_demo	68.57% <ø> (+0.09%)	⬆️
spp_programs	65.27% <ø> (ø)
spp_registry	87.22% <ø> (ø)
spp_security	69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.