fix(approval-ui): WM lock banner + 3-way reason fallback (build 642)

Regression sweep after build 641 found two sibling drifts of the same
projection-stripping pattern, both in `wl_approval_ui.js`:

1. Lock banner above the table (line 374-377) used `pa.description`
   only, rendering "column removal by analyst1 ()" with empty parens
   for action types where backend leaves description="".

2. Action-bar fallback (line 401-405) computed but never used
   `extractApprovalReason(pa)`, while Control Panel uses the same
   helper as a third fallback (`control_panel.js:463`). Asymmetric
   between the two surfaces — analyst structured reasons inside the
   payload (e.g. column_removal_reasons[0].reason) rendered in CP
   but not WM.

Both call sites now use:
  pa.comment || pa.description || extractApprovalReason(pa) || ""

Lock banner additionally suppresses the parens entirely when no
reason is available — renders "by analyst1" cleanly instead of
"by analyst1 ()".

Cache-bust `_b=` bumped 640 -> 642 (build 641 was backend-only and
left _b at 640; this catches up so returning users pick up the JS).

JS-only — no schema or API changes. Verified deployed JS in container
contains the new fallback chains and `_b=642`.

Rollback: revert this commit + redeploy at the previously-shipped
build 641; lock banner returns to empty-parens cosmetic behavior,
action-bar banner stays correct (build-641 fix is independent).

Author: wildleo91

CHANGELOG.md

@@ -64,6 +64,92 @@ Detailed per-round entries below.
 
 ---
 
+## Unreleased — 2026-05-07 (build 642, regression-sweep follow-up: lock banner + 3-way fallback)
+
+### Bug — sibling drift surfaced during build-641 regression sweep
+
+The build-641 fix repaired the WM action-bar banner ("by analyst —
+reason") for `column_removal` / `remove_csv` / `remove_rule` requests.
+A targeted regression sweep against every sibling consumer of the
+pending-approval projection found two more places carrying the same
+class of drift:
+
+1. **Lock banner** at the top of the WM table
+   ([wl_approval_ui.js:374-377](appserver/static/modules/wl_approval_ui.js#L374-L377))
+   read `pa.description` only with no fallback. For action types where
+   the backend leaves `description=""` it rendered "**column removal**
+   by analyst1 ()" — empty parens. Cosmetic-only (the action bar below
+   carries the actionable approve/reject buttons), but visible side by
+   side and confusing.
+
+2. **Action-bar fallback** at
+   [wl_approval_ui.js:401-405](appserver/static/modules/wl_approval_ui.js#L401-L405)
+   computed `var reason = extractApprovalReason(pa)` but never used it,
+   while the Control Panel uses the same helper as a third fallback
+   ([control_panel.js:463](appserver/static/control_panel.js#L463)).
+   When an analyst structured their reason inside the payload (e.g.
+   `column_removal_reasons[0].reason`) instead of the free-form
+   comment field, CP rendered the reason and WM rendered nothing —
+   asymmetric between the two surfaces.
+
+### Fix
+
+Both call sites now use the same 3-way fallback chain:
+
+```javascript
+pa.comment || pa.description || extractApprovalReason(pa) || ""
+```
+
+The lock banner additionally drops the parens entirely when no reason
+is available (renders "by analyst1" cleanly instead of "by analyst1
+()"), matching the action-bar pattern of "no separator when no
+reason".
+
+### Why this didn't surface in build-641 verification
+
+Build-641's browser smoke-test confirmed the action-bar banner
+rendered "Field deprecated by GRC team" and stopped there. The lock
+banner above it WAS visible in the same screenshot but didn't render
+empty parens because the demo-state seed only carried the one
+column_removal entry — and the lock-banner fallback to `description`
+returned a non-empty value for the FIRST entry I inspected (a
+`bulk_row_addition` from a different fixture). Three lessons:
+
+1. End-to-end verification of one banner is not verification of the
+   page — sibling renders need their own checks.
+2. Single-entry demo state masks fallback-chain bugs that only
+   surface with action-type variety.
+3. The Control Panel's 3-way fallback existed; the WM only had
+   2-way; that asymmetry was its own signal that one surface was
+   ahead of the other.
+
+### Tests
+
+The build-641 unit suite at
+[tests/unit/test_pending_info_projection.py](tests/unit/test_pending_info_projection.py)
+already pins the **backend** projection contract (the `comment` field
+is reachable to the frontend). The frontend fallback chain is
+exercised by E2E click-through; no new unit test added because the
+asserting layer would be Playwright (different toolchain than the
+pytest suite).
+
+### Migration / rollback
+
+JS-only — no schema or API changes. Cache-bust `_b=` bumped from 640
+to 642 so returning users automatically pick up the fresh JS without
+hard-refresh. Rollback: revert this commit + redeploy at the
+previously-shipped build 641;
+the lock banner returns to empty-parens cosmetic behavior, the
+action-bar banner stays correct (build-641 fix is independent).
+
+### Build cache-bust caught up
+
+Build 641 shipped with `_b=640` (backend-only fix, no JS changes —
+acceptable but the maintenance rule says to keep them in sync).
+Build 642 closes the gap.
+
+---
+
 ## Unreleased — 2026-05-07 (build 641, fix WM approval-banner blank reason)
 
 ### Bug — `comment` dropped from `pending_info` projection

appserver/static/modules/wl_approval_ui.js

@@ -371,9 +371,16 @@ function applyPendingHighlighting() {
         _$revertSelect.prop("disabled", true);
 
         // Show lock banner
+        // Same fallback chain as the action-bar item below + Control Panel.
+        // For column_removal/remove_csv/remove_rule the backend leaves
+        // description="" and the analyst's reason lives in `comment`.
+        // Without the fallback the banner renders "by analyst ()".
         var descriptions = _state.pendingApprovals.map(function (pa) {
+            var lockReason = pa.comment || pa.description ||
+                             extractApprovalReason(pa) || "";
             return '<strong>' + _.escape(pa.action_type.replace(/_/g, " ")) + '</strong> by ' +
-                   _.escape(pa.analyst) + ' (' + _.escape(pa.description) + ')';
+                   _.escape(pa.analyst) +
+                   (lockReason ? ' (' + _.escape(lockReason) + ')' : '');
         });
         _actions.showMsg(
             "This CSV is locked &mdash; " +
@@ -401,8 +408,12 @@ function applyPendingHighlighting() {
                 var reason = extractApprovalReason(pa);
                 var hl = pa.pending_highlight || {};
                 var hasRowHighlight = (hl.type === "rows" && hl.row_keys && hl.row_keys.length > 0);
-                // Use comment (user's typed reason) or description, avoid duplication
-                var displayReason = pa.comment || pa.description || "";
+                // 3-way fallback matches Control Panel's render path.
+                // `reason` digs into payload-internal fields like
+                // column_removal_reasons[0].reason — covers the case
+                // where the analyst structured the reason inside the
+                // payload instead of typing a free-form comment.
+                var displayReason = pa.comment || pa.description || reason || "";
                 var descTitle = pa.action_type.replace(/_/g, " ") +
                     ' by ' + pa.analyst + ' — ' + displayReason;
                 barHtml +=

appserver/static/whitelist_manager.js

@@ -11,7 +11,7 @@
 // disk cache. Splunk serves /static/@<server-hash>/... with Cache-Control:
 // public, max-age=31536000; without urlArgs, bumped build numbers don't force
 // a re-fetch and clients run stale JS until they hard-refresh.
-require.config({ urlArgs: "_b=640" });
+require.config({ urlArgs: "_b=642" });
 require([
     "jquery",
     "underscore",

default/app.conf

@@ -5,7 +5,7 @@
 
 [install]
 is_configured = false
-build = 641
+build = 642
 
 [launcher]
 author       = Security Engineering