cproudlock fa6b99bf91
Some checks failed
CI / naming (push) Successful in 4s
CI / frontend (push) Successful in 14s
CI / migrations-mysql (push) Failing after 14s
CI / backend (push) Failing after 4m57s
Finish a restore without a browser, from the set that was asked for
Closes the three defects in the imported restore path, at Ben's request. Each
was proven against a real stack before and after: two backup sets with different
data and different instance files, then a restore of the OLDER one, which is the
case that was broken.

A restore no longer depends on a tab staying open. The backup sidecar has no
Flask, so it loads the dump and leaves a sentinel for the api container to run
the migrations. The only thing that ever acted on that sentinel was the poll
loop of the modal that queued the restore, so closing the tab - or letting a
token expire - during the minutes a load takes left the data at the old revision
under new code, every query on a newer column failing, and nothing retrying. A
watcher in the api container now claims and runs it. The endpoint no longer runs
the upgrade at all; it only makes sure something is pending, which is also how a
failed upgrade is retried. That takes Alembic out of the request path, where it
could outrun the gunicorn worker timeout and be killed mid-chain, leaving a
half-applied revision the next attempt trips over.

The claim is a rename, because rename(2) is atomic: several workers and a
browser poll can race the same sentinel and exactly one wins. A failed upgrade
parks itself as .upgrade-failed rather than re-arming, since putting it back
would rerun the same broken chain on every poll forever.

Instance files come from the set being restored. The restic call asked for
'latest' regardless of which set was named, so restoring anything but the newest
paired that set's DATABASE with the NEWEST snapshot's uploads and plugins.json -
a mismatch nothing downstream could detect. Now scoped by the set's own tag,
which backup.sh has always written. The tree is replaced rather than restored
over, so files created after the snapshot are gone afterwards: a restore has to
put the site back to the snapshot, not merge into it. Done as a staged swap
rather than 'restic restore --delete --target /', because that aims a delete
pass at the container root and the cost of getting its filter wrong is the whole
filesystem.

Nothing destructive happens before a copy is taken. The dump carries DROP TABLE
per table with no transaction around it, and the instance tree is replaced
wholesale, so a wrong set or a failure part-way through left nothing to go back
to. restore.sh now writes a pre-restore-<stamp>/ set - dump, instance tarball
and a README saying what it is and how to load it - and refuses to touch
anything if that copy cannot be written.

Two more found while proving the above, both of which stopped the overlay
working at all:

* Every script under scripts/backup/ was committed non-executable, while every
  other .sh in the repo is 755. The compose entrypoints are
  /opt/backup/watch.sh and backup.sh from a read-only bind mount, so the backup
  and watcher containers could not start from a clean checkout on any machine,
  and nothing could fix it at runtime.

* Dockerfile.backup could not build without the corporate CA staged. A plain
  COPY of the gitignored cert fails outright; the trailing-glob form does too,
  because BuildKit fails a COPY whose pattern matches nothing - which is exactly
  the case being handled. Copying the directory and testing for the file inside
  it is the form that works both ways. Verified by building the image with no
  cert present.

Suite 2600 passed / 9 skipped. The finalizer has unit tests covering the atomic
claim, the parked failure and the endpoint no longer running the upgrade.

Scope: product
2026-09-06 17:38:10 -04:00

ShopDB Flask

A modern rewrite of the classic ASP/VBScript ShopDB application using Flask (Python) and Vue 3. This application manages shop floor machines, PCs, printers, applications, and related infrastructure for manufacturing environments.

Overview

ShopDB tracks and manages:

  • Machines - CNC equipment, CMMs, inspection systems, etc.
  • PCs - Shopfloor computers, engineering workstations
  • Printers - Network printers with Zabbix supply integration
  • Network devices - Switches, routers, and the subnet browser
  • Measuring tools - Gage-lab instruments with calibration tracking
  • Applications - Software deployed across the shop floor, with per-PC install tracking
  • Employees - Directory, recognition and training notifications
  • Warranties - Coverage records with Dell warranty lookups
  • USB devices - CMMC check-in/out tracking
  • Knowledge Base - Documentation and troubleshooting guides
  • GE-Enforce manifests - Imaging/software manifest editing and fleet compliance

Tech Stack

Backend:

  • Python 3.14 with Flask
  • SQLAlchemy ORM
  • MySQL 5.7+ database (5.6 works with extra utf8mb4 config; see the DEPLOY wiki page)
  • JWT authentication
  • Plugin architecture for extensibility

Frontend:

  • Vue 3 with Composition API
  • Vue Router for navigation
  • Pinia for state management
  • Vite build system

Project Structure

shopdb-flask/
+-- shopdb/                 # Flask application
|   +-- core/
|   |   +-- api/            # REST API endpoints
|   |   +-- models/         # SQLAlchemy models
|   |   +-- schemas/        # Validation schemas
|   |   `-- services/       # Business logic
|   +-- plugins/            # Plugin system
|   `-- utils/              # Shared utilities
+-- frontend/               # Vue 3 application
|   +-- src/
|   |   +-- api/            # API client
|   |   +-- components/     # Reusable components
|   |   +-- views/          # Page components
|   |   +-- router/         # Route definitions
|   |   `-- stores/         # Pinia stores
|   `-- public/             # Static assets
+-- plugins/                # Bundled and external plugins
+-- migrations/             # Alembic migration chain (flask db upgrade)
+-- scripts/                # Import and utility scripts
`-- tests/                  # Test suite

Naming Conventions

To maintain consistency with the legacy ShopDB database and codebase, the following naming standards apply:

Database

  • Table names: Lowercase, single word, no underscores or dashes
    • Examples: assets, computers, printers, businessunits
  • Column names: Lowercase, single word, no underscores or dashes
    • Examples: assetid, assetnumber, hostname, isactive, createddate
  • Foreign keys: Referenced table name + id
    • Examples: locationid, vendorid, modelnumberid, computertypeid
  • Boolean columns: Prefixed with is or has
    • Examples: isactive, isshopfloor, iscolor, isdhcp, islicenced

Code

  • Python variables: Follow database naming where applicable (lowercase, no underscores for model fields)
  • JavaScript variables: camelCase for local variables, but match API field names from backend
  • Vue components: PascalCase for component names
  • CSS classes: Lowercase with dashes for multi-word classes

API

  • Endpoints: Lowercase, plural nouns
    • Examples: /api/machines, /api/computers, /api/locations
  • Query parameters: Lowercase, single word
    • Examples: ?locationid=5, ?isactive=true, ?assettype=computer

Style Guidelines

  • No emojis in code, comments, documentation, or UI
  • Keep UI functional and professional
  • Dark theme is the default
  • Consistent table layouts across all list views

Setup

Prerequisites

  • Python 3.14
  • Node.js 18+
  • MySQL 5.7+ (5.6 works with extra utf8mb4 config; see the DEPLOY wiki page)

ShopDB Flask uses MySQL as the canonical database. SQLite is used only for the test suite (TestingConfig in shopdb/config.py points at an in-memory SQLite). Do not run dev or production against SQLite.

Distribution

Source lives here. The Windows installer ships as a release asset rather than a file in the repository - it is around 240 MB, well past what a repository takes and well inside what a release asset does. There is no package or image registry; a site installs from that .exe or builds from source.

Fast path (Docker)

The Docker image builds the Vue frontend and serves it from the API container, so a container deploy needs no separate Node build step.

cp .env.example .env
# Edit .env: set SECRET_KEY, JWT_SECRET_KEY, DATABASE_URL, CORS_ORIGINS,
# and the MYSQL_* passwords (see the CONFIG wiki page for every variable).

docker compose up -d --build

# Create the schema and seed the platform data (idempotent, safe to re-run):
docker compose exec api flask db upgrade
docker compose exec api flask seed permissions
docker compose exec api flask seed settings
docker compose exec api flask seed reference-data

Then browse to the site and complete the first-run setup wizard at /setup (it creates the first admin account and captures site identity). To create the admin headlessly instead of using the wizard:

docker compose exec api flask seed admin --username admin --email admin@facility.example.com

Manual path (venv + Node)

# Backend
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# Edit .env with your database credentials and secrets.

export FLASK_APP=shopdb
flask db upgrade
flask plugin upgrade-all      # per-plugin schema (ADR-008)
flask seed permissions
flask seed settings
flask seed reference-data
flask run --port 5001         # MUST be 5001 - the frontend dev server proxies here

# Frontend (separate terminal)
cd frontend
npm install
npm run dev          # dev server on :5173
npm run build        # production build into frontend/dist (served by Flask)

Complete first-run setup at /setup, or run flask seed admin for a headless admin account. The repo ships VS Code config in .vscode/ (F5 debugs the backend; a "Dev site" task runs both servers). A fuller day-one walkthrough, including VS Code and troubleshooting, is the DEVELOPMENT-SETUP page in the project wiki.

To import a site's legacy data, use the HTTP import surface: an admin API token plus the IMPORT-API page in the project wiki drive the whole migration through documented endpoints (X-Import-Mode preserves original timestamps). scripts/site_imports/wjf/ is the reference site's loader, kept as a worked example of the whole sequence.

Which deployment route

Target Use
Windows Server + IIS (how sister sites run) the INSTALL-WINDOWS page in the project wiki - one installer .exe, offline, no manual IIS work. Day 2: the OPERATE-WINDOWS page in the project wiki
Linux / Docker, air-gapped the DEPLOY-AIRGAP page in the project wiki
Linux / Docker, connected the DEPLOY page in the project wiki

For every environment variable and Setting key see the CONFIG page in the project wiki.

What the Windows installer requires

The installer checks all of this before it changes anything and refuses rather than half-installing.

Minimum Notes
Windows Server 2019 (build 10.0.17763) Ships IIS 10.0, which is therefore the earliest IIS supported. Server 2016 is also IIS 10.0 but falls below the build floor and is refused.
Windows client (test boxes) 10 22H2 (build 10.0.19045) or 11 Pro or higher - Home has no IIS at all.
Architecture 64-bit The payload is cp314 win_amd64.
IIS Web Server role installed beforehand Install-WindowsFeature -Name Web-Server -IncludeManagementTools. Needs no internet.
Free disk 5 GB Refused below this. 40 GB is comfortable once uploads and config backups accumulate.
Database bundled MySQL 8.4 LTS, or your own Bring credentials if you use an existing server.

The binding constraint is the operating system rather than IIS: the payload is Python 3.14 plus HttpPlatformHandler and URL Rewrite, and the handler itself runs on older IIS. An older host is untested rather than known-broken.

If you must deploy onto something older, the INSTALL-WINDOWS-IIS page in the project wiki is the manual procedure and has no OS gate - it even documents MySQL 5.6, which is that era of machine. The trade is stated there: it produces a server the installer will not subsequently upgrade.

Configuration

Environment variables (.env):

Variable Description
DATABASE_URL MySQL connection string
SECRET_KEY Flask secret key
JWT_SECRET_KEY JWT signing key
JWT_ACCESS_TOKEN_EXPIRES Access token TTL (seconds)
LOG_LEVEL Logging verbosity

API Documentation

The REST API follows standard conventions:

Method Endpoint Description
GET /api/machines List machines (filterable by type)
GET /api/machines/:id Get machine details
POST /api/machines Create machine
PUT /api/machines/:id Update machine
DELETE /api/machines/:id Soft delete machine

Each asset plugin exposes the same CRUD pattern on its own prefix (/api/computers, /api/printers, /api/network, /api/measuringtools), and cross-cutting asset endpoints live under /api/assets.

Query parameters for list endpoints:

  • page - Page number (default: 1)
  • perpage - Items per page
  • sort - Sort field
  • dir - Sort direction (asc/desc)
  • search - Search term
  • assettype - Filter by asset type (computer, printer, machine, networkdevice, measuringtool)

Where to start

the START-HERE page in the project wiki routes by what you are here to do - standing up a site, deploying the shop-floor tools, writing a plugin, integrating with the API, or diagnosing something. On the published mirror the same page is the wiki's front door.

Plugin System

ShopDB supports plugins for extending functionality. See CONTRIBUTING.md for plugin development guidelines.

The image bundles these plugins; only the ones a site installs are loaded. The current count and each plugin's version and migration head are in the PROJECT-MAP page in the project wiki, which is generated:

  • backups - Machine configuration backups (NTLARS/DNC, CMM, part marker, UDC) with revision history and diffs
  • computers - Shopfloor PCs and workstations, collector fleet ingest
  • employees - Employee directory
  • geenforce - GE-Enforce imaging/software manifests and fleet compliance
  • machines - CNC, CMM, and other shop-floor machines
  • measuringtools - Gage-lab instruments with calibration tracking
  • knowledgebase - Documentation and troubleshooting guides
  • network - Network devices and subnets
  • notifications - Shopfloor notifications and recognition feed
  • printedparts - 3D-printed part catalogue, kiosk issue tracking and stock alerts
  • printers - Extended printer management with Zabbix integration
  • slides - TV/kiosk slideshows
  • tools - Tech Tools: barcode and QR generation laid out for real label stock
  • usb - CMMC USB check-in/out tracking
  • warranty - Warranty records with Dell lookups

Legacy Migration

This project replicates functionality from the classic ASP/VBScript ShopDB site. Key mappings:

Legacy Modern
ASP/VBScript Flask/Python
Classic ADO SQLAlchemy
Server-side HTML Vue 3 SPA
Session auth JWT tokens

License

Internal use only.

Description
Shop Database Flask Application with Vue 3 Frontend
Readme 98 MiB
Languages
Python 52.3%
Vue 19.7%
JavaScript 17.5%
PowerShell 5.5%
C# 2.8%
Other 2%