drawings: VISUAL's rev is the source of truth; attach it when M-Files holds it Effective or Retired #47

Merged
spencerm merged 1 commits from visual-rev-is-truth into main 2026-10-19 23:21:34 +00:00
Owner

Follows #46.

Why

#46 let a Clerical Supervisor choose the rev VISUAL calls when M-Files has retired it. VISUAL should be the source of truth for the rev, so that choice should not need anyone's approval.

What changes

  • The rev VISUAL calls is attached automatically. This happens when M-Files' Effective rev differs from the rev VISUAL calls and M-Files holds that rev as Effective or Retired. The draft gets no flag and needs no approval, so it can auto-release to the warehouse. The packet page says "Rev V attached as VISUAL calls it - retired in M-Files, which has rev N as Effective".
  • Only Effective or Retired drawings are ever attached. Any other M-Files status (Released, Obsolete and the like), or no document at that rev, still flags rev_mismatch. The note says why, for example "rev 2 is Obsolete in M-Files - not attached". The copy is not even fetched. rev_approve (approve M-Files' Effective rev) stays for that case only.
  • Packets past draft: while VISUAL's rev holds, a newer Effective rev in M-Files raises no flag and no change order. VISUAL moving its rev still runs the existing change-order path.
  • Removed: the use: "called" path in rev-approve and the "Use rev V as VISUAL calls it" button. Packet 168 on the test stack already kept r9 that way. It stays valid, since that rev is now used anyway.

How

  • decide.py: a new row 2a (attach_called), the Called input, and rev_confirmed counts it. The kept_latest logic from #46 is gone.
  • Drawing job: for any packet whose VISUAL rev differs from M-Files' Effective rev, it calls Lookup.revision before deciding. It fetches the copy only when the status is in ATTACHABLE = {effective, retired}, then attaches it with vault.controlled set.
  • No schema change: it reuses drawing_revisions from migration 0009. No MFilesKit change either.

Tests

  • Server: the full suite passed against PostgreSQL 16 (5966 passed, 6 skipped: these need the test domain controller). New decision-row tests cover the retired rev, the already-attached copy, past draft, a hand drawing, no Effective rev, an approved rev winning, and no copy. New job tests cover the Obsolete status and a missing rev staying flagged. The auto-release test now shows the retired-rev packet released to the warehouse.
  • Frontend: 304 passed, with tsc and eslint clean.
  • Not yet run on the test stack. After deploy, the flagged L073 packets whose VISUAL rev is retired in M-Files (for example packet 174, L073-85-1 r11) should attach at their next recheck and auto-release.

Not covered

A pending VISUAL change order on a packet past draft that waits for a rev M-Files has only as Retired still waits. It is staged only when that rev becomes the Effective one. That is rare (VISUAL moving a released job back to an older rev). It can be a follow-up if it matters.

🤖 Generated with Claude Code

Follows #46. ## Why #46 let a Clerical Supervisor choose the rev VISUAL calls when M-Files has retired it. VISUAL should be the source of truth for the rev, so that choice should not need anyone's approval. ## What changes - **The rev VISUAL calls is attached automatically.** This happens when M-Files' Effective rev differs from the rev VISUAL calls and M-Files holds that rev as **Effective or Retired**. The draft gets no flag and needs no approval, so it can auto-release to the warehouse. The packet page says "Rev V attached as VISUAL calls it - retired in M-Files, which has rev N as Effective". - **Only Effective or Retired drawings are ever attached.** Any other M-Files status (Released, Obsolete and the like), or no document at that rev, still flags `rev_mismatch`. The note says why, for example "rev 2 is Obsolete in M-Files - not attached". The copy is not even fetched. `rev_approve` (approve M-Files' Effective rev) stays for that case only. - **Packets past draft:** while VISUAL's rev holds, a newer Effective rev in M-Files raises no flag and no change order. VISUAL moving its rev still runs the existing change-order path. - **Removed:** the `use: "called"` path in `rev-approve` and the "Use rev V as VISUAL calls it" button. Packet 168 on the test stack already kept r9 that way. It stays valid, since that rev is now used anyway. ## How - **`decide.py`:** a new row 2a (`attach_called`), the `Called` input, and `rev_confirmed` counts it. The `kept_latest` logic from #46 is gone. - **Drawing job:** for any packet whose VISUAL rev differs from M-Files' Effective rev, it calls `Lookup.revision` before deciding. It fetches the copy only when the status is in `ATTACHABLE = {effective, retired}`, then attaches it with `vault.controlled` set. - **No schema change:** it reuses `drawing_revisions` from migration 0009. No MFilesKit change either. ## Tests - Server: the full suite passed against PostgreSQL 16 (5966 passed, 6 skipped: these need the test domain controller). New decision-row tests cover the retired rev, the already-attached copy, past draft, a hand drawing, no Effective rev, an approved rev winning, and no copy. New job tests cover the Obsolete status and a missing rev staying flagged. The auto-release test now shows the retired-rev packet released to the warehouse. - Frontend: 304 passed, with tsc and eslint clean. - Not yet run on the test stack. After deploy, the flagged L073 packets whose VISUAL rev is retired in M-Files (for example packet 174, L073-85-1 r11) should attach at their next recheck and auto-release. ## Not covered A pending VISUAL change order on a packet past draft that waits for a rev M-Files has only as Retired still waits. It is staged only when that rev becomes the Effective one. That is rare (VISUAL moving a released job back to an older rev). It can be a follow-up if it matters. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
spencerm added 1 commit 2026-10-19 22:06:21 +00:00
drawings: VISUAL's rev is the source of truth; attach it when M-Files holds it Effective or Retired
ci / frontend (pull_request) Successful in 43s
ci / server (pull_request) Successful in 11m3s
ci / image (pull_request) Skipped
ci / e2e (pull_request) Successful in 3m52s
ca407a2db3
When M-Files' Effective rev differs from the rev VISUAL calls, the drawing
job looks that rev up (MFilesKit DrawingLookup.revision). If M-Files has
it as Effective or Retired, the job copies it into drawing_revisions and
attaches it to the draft with no flag and no Clerical approval, so the
draft can auto-release. Past draft, already attached or with a hand
drawing: unchanged, no flag and no change order.

Any other status, or no document at that rev, still flags rev_mismatch
with a note saying why. Packet Station only ever attaches Effective or
Retired drawings. rev_approve stays for that case only.

This replaces the "Use rev V as VISUAL calls it" choice from #46: the
use=called path in rev-approve and its button are removed. A packet that
already kept the rev that way keeps it, since that rev is now used anyway.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
spencerm merged commit b0f6a09173 into main 2026-10-19 23:21:34 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spencerm/PacketStation#47