48d3160bc5
The equipment plugin is now the machines plugin, ending the UI-vs-code vocabulary split while the contract is pre-1.0 and nothing external depends on the old names. - plugins/equipment -> plugins/machines: manifest, class, /api/machines, machines.* permissions, registry key (with an auto-migrating load shim for existing installs). - Tables: equipment -> machines (equipmentid -> machineid) and equipmenttypes -> machinetypes, renamed in the plugin's own migration chain (machines0002rename), idempotent for both upgrading and fresh installs. - The legacy core machinetypes lookup actually types the vendor MODELS catalog, so it is renamed losslessly to modeltypes (models.modeltypeid, /api/modeltypes, Model Types settings page) rather than collapsed, freeing the machinetypes name. Core migration 7d17_machines_rename also flips data in place: assettypes row equipment -> machine, auditlog entitytype, identifier_/search_ settings keys, permission rows, and renames alembic_version_equipment. - Frontend: machinesApi/modeltypesApi, item.machine response shape, assettype value compares 'equipment' -> 'machine' (map, search, custom fields, relationships), routes machines.js with plugin gating retagged, /print/machine-badge, Machine Types (subtypes) and Model Types (catalog) settings pages, machines-by-type report id. - Docs swept; ADRs left as history per the authoring rule. Upgrade: flask db upgrade then flask plugin upgrade-all. Verified: dev DB flipped live (262 machines, 35 modeltypes, 95 models retyped, zero equipment tables remain); fresh scratch-MySQL install produces the new names; 341 tests green; naming/style green; frontend builds; live E2E on machines list/detail, PC relationships, map, reports, and both settings pages. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.9 KiB
Plugins
shopdb-flask is a framework. The plugins listed here are the pieces other GE Aerospace facilities can install, build, or skip per ADR-003. Bundled plugins ship in the framework repo. External plugins live in their own repos and drop into <repo>/plugins/<name>/ at install time.
Bundled (ship with the framework)
These plugins are in plugins/ in this repo. Enable per site with flask plugin install <name>.
| Plugin | Tracks | Notes |
|---|---|---|
machines |
Manufacturing machinery: 5-axis mills, lathes, broachers, heat treatment ovens | Manually entered. See ADR-005. Subtype tables for FOCAS / CLM / MTConnect controller protocols (planned). |
computers |
Shop-floor PCs and engineering workstations | Fed by the PXE pipeline collector per ADR-006. |
printers |
Network and shop-floor printers | Optional Zabbix integration for supply tracking. Legacy PrinterData retiring per ADR-001. |
network |
Switches, routers, access points, IDFs as locations | Asset-only; cleanest of the bundled set. |
usb |
USB devices issued to shop-floor users | Lightweight checkout / check-in. |
notifications |
Shop-floor notifications, recognitions, kiosk feed | Used by ShopfloorDashboard.vue. |
measuringtools |
Metrology and inspection instruments: calipers, micrometers, thread/bore/height gages, indicators | Per ADR-005. Calibration lifecycle with derived status. First plugin built on the matured scaffold; its walkthrough is PLUGIN-GUIDE.md. Ships default_enabled: false. |
Building your own
Guides:
- PLUGIN-QUICKSTART.md - generate, customize, install, and test a plugin in 30 minutes using
flask plugin new. - PLUGIN-GUIDE.md - the full narrative walkthrough of building the
measuringtoolsplugin, the exemplar that exercises every current framework feature (models, per-plugin migrations, authz, hooks, frontend integration, tests). - PLUGIN-EXTERNAL-REPO.md - developing a plugin in its own repo per ADR-003: repo layout, symlink dev workflow,
core_versionpinning, and a runnable CI harness (scripts/test-external-plugin.sh) that tests the plugin against a pinned framework ref. - CONTRACT-STABILITY.md - path to contract 1.0: what is settled vs still churning, the bump rules, and how much a sister site can safely build on today.
The contract is locked in ADR-001 and versioned per ADR-002.
Quick path:
flask plugin new cameras --description "Tracks shop-floor surveillance cameras"
# edit plugins/cameras/models/cameras.py with your fields
flask plugin install cameras
Migrations (per-plugin chains)
Each plugin that owns tables carries its own Alembic chain under
plugins/<name>/migrations/, with a per-plugin version table
alembic_version_<name> independent of the core alembic_version. Ownership is
split at a fixed cutover (see ADR-008):
- The core chain (
flask db upgrade) created every table that existed through its head, including the bundled-plugin tables. Each bundled plugin's0001migration is a stamp-only no-op anchor recording that fact. - From the cutover forward, a change to a plugin's schema lands as
plugins/<name>/migrations/versions/000N_*.py, never in the core chain. The core chain is reserved for core tables. - A plugin built AFTER the cutover (e.g.
measuringtools) is different: the core chain never created its tables, so its0001is a REAL baseline that creates them, not a no-op anchor. See PLUGIN-GUIDE.md for the anchor-vs-baseline distinction.
Deploys and upgrades run flask db upgrade then flask plugin upgrade-all.
upgrade-all stamps every plugin anchor and applies any later plugin
migrations; it is idempotent. The registry (instance/plugins.json) records
which revisions each plugin has applied in migrations_applied.
Distribution conventions
For sister-site plugins (per ADR-003):
- Plugin lives in its own git repo:
gitea.proudtech.net/<your-site>/<pluginname> - Adopting site clones or symlinks into their
<repo>/plugins/<name>/ - Plugin manifest declares
core_versionrange matching the framework version they target - Plugin readme explains: what it tracks, who maintains it, where to file issues
Naming policy
Plugin names follow the framework's naming convention (lowercase concatenated, no underscores or dashes; full words preferred over acronyms). See CONTRIBUTING.md. Plugin name collisions across sites are not enforced; the convention recommends prefixing site-specific plugins with the site code (e.g., wjsf-shippingstation) when there is risk of overlap.