shopdb-flask/CONTRIBUTING.md

Contributing to ShopDB Flask

Coding Standards

Naming principles

1. Spell it out. If a non-technical user looking at a report would not understand a column at a glance, rename it.
2. No project-specific shorthand. A name either uses a word in full, or uses an acronym from the allowed list below.
3. Consistency beats cleverness. Once a name is committed and used in code, do not rename it for marginal improvement.
4. When unsure, ask: "would a new shop-floor IT person understand this?"

Database

• Table names: lowercase, concatenated, plural. No dashes, no underscores.
  • Good: machines, pctypes, networkdevices, businessunits, auditlogs
  • Bad: machine_types, network-devices, BusinessUnits
• Column names: lowercase, concatenated, singular. No dashes, no underscores.
  • Good: machineid, machinenumber, lastzabbixsync, isactive
  • Bad: machine_id, last_zabbix_sync, IsActive
• Foreign keys: referenced table name (singular) + id.
  • Good: locationid references locations, vendorid references vendors
• Booleans: prefix with is or has.
  • Good: isactive, isshopfloor, hasprinter
• Index names: idx_<table>_<column>. Underscores allowed here only because indexes are infrastructure, not data.
  • Good: idx_machines_locationid

Migrations and deploy ordering

• A model change ships WITH its migration in the same change. Adding or changing a column/table on a SQLAlchemy model without the matching Alembic migration is a broken change, even if it passes tests against a freshly built schema.
• Code and schema must never deploy out of step. A model that references a column its migration has not applied yet makes MySQL raise 1054 Unknown column, which 500s every query on that table (this is not a degraded read - the whole endpoint fails).
• Bringing up a new image MUST run migrations before serving traffic, in order: flask db upgrade (core chain) then flask plugin upgrade-all (per-plugin chains). A rebuilt image with new model code but an un-migrated database will 500 until this runs.
• Core schema lives in migrations/versions/; each plugin owns its own chain under plugins/<name>/migrations/. New schema = a new migration with an idempotent guard and a real downgrade, clean on strict MySQL 8.

Allowed acronyms (closed list, expand by PR)

• Universal: id, url, api, http, https, json, jwt, sql, os, ip, dns, csv, pdf, cors, ttl, uuid, html, css, orm
• Domain (shop floor / IT infra): cmm, cnc, pc, usb, vnc, winrm, ssh, ssl, tls, tcp, udp, smtp, ldap, vlan, sso, dnc, focas, clm, mtconnect

Any acronym not on these lists must be spelled out. Proposing a new acronym is a separate PR that updates this list.

Third-party imports are exempt. Library and stdlib module paths cannot be renamed. from sqlalchemy.orm import ..., import importlib.util, from werkzeug.utils import ... are all fine even if they contain words that would otherwise be banned.

Banned shorthand

cfg, ctx, mgr, req, res, env, util, helper, and any other domain-specific shortening. Spell it out: config, context, manager, request, response, environment, utilities. Note: db as a standalone variable name is banned, but db as a prefix in database or as part of project name shopdb is fine.

Suffix exception. Banned shorthand applies to standalone identifiers. As a suffix where the prefix establishes meaning, it is acceptable:

• printers_bp, auth_bp, network_bp are fine. The prefix names what blueprint, the _bp suffix is conventional for Flask blueprints.
• request_obj is fine when disambiguating from imported request.
• bp alone as a variable name is not fine. Always pair with a meaningful prefix.

Code

Python

• Variables and functions holding a database value: match the column name exactly. No conversion to snake_case.
  • DB column machineid -> Python variable machineid, attribute Machine.machineid, dict key {"machineid": 1}
  • DB column lastzabbixsync -> Python variable lastzabbixsync
• Pure code variables and functions (loop counters, helpers, anything that does not mirror a DB field): snake_case per PEP 8.
  • Good: loop_count, current_user, validate_input()
• Classes: PascalCase. Spell out fully.
  • Good: PrinterData, AssetType, NetworkDevice
• Modules / file names: lowercase. Underscores allowed where it improves readability (PEP 8 permits this for modules).
  • Good: employee_service.py, asset_routes.py

JavaScript / Vue

• Variables: camelCase per JS convention.
  • Good: currentUser, isLoading
• Variables holding API field values: match the API field name exactly. Do NOT convert to camelCase.
  • API returns {"machineid": 1} -> JS response.machineid, NOT response.machineId
  • API returns {"lastzabbixsync": "..."} -> JS device.lastzabbixsync
• Components: PascalCase. Spell out fully.
  • Good: AssetDetail.vue, MachineForm.vue, PrinterList.vue
• CSS classes: lowercase with dashes.
  • Good: asset-detail, machine-form

API

• Endpoints: lowercase, plural nouns. No underscores or dashes.
  • Good: /api/machines, /api/networkdevices, /api/businessunits
• Query parameters: lowercase, concatenated. Match column names where applicable.
  • Good: ?locationid=5, ?isactive=true
• Response keys: match database column names exactly.
  • Good: {"machineid": 1, "lastzabbixsync": "2026-01-12T10:00:00Z"}

Examples

# Good - DB-mirrored fields keep column names; pure code uses snake_case
class PrinterData(db.Model):
    __tablename__ = 'printerdata'

    machineid = db.Column(db.Integer, db.ForeignKey('machines.machineid'))
    lastzabbixsync = db.Column(db.DateTime)
    isnetworkprinter = db.Column(db.Boolean)


def list_printers_by_location(locationid: int) -> list[dict]:
    printers = PrinterData.query.filter_by(locationid=locationid).all()
    result_count = len(printers)
    return [{"machineid": p.machineid, "isnetworkprinter": p.isnetworkprinter} for p in printers]

# Bad - PEP 8-style underscores on DB fields, banned shorthand, project acronym not on allowed list
class PrinterData(db.Model):
    __tablename__ = 'printer_data'

    machine_id = db.Column(db.Integer)
    last_zabbix_sync = db.Column(db.DateTime)
    is_net_prn = db.Column(db.Boolean)


def list_prns_by_loc(loc_id):
    bp_ctx = get_context()
    cfg = load_cfg()
    return PrinterData.query.filter_by(loc_id=loc_id).all()

Style policy (non-naming)

• No emojis in code, comments, documentation, string literals, or UI.
• No em-dashes (U+2014), en-dashes (U+2013), Unicode arrows, or smart quotes anywhere. Plain ASCII only.
• Comments default to none. Add one only when the WHY is non-obvious. Keep comments terse (lite caveman style is fine for inline # and // comments). Docstrings stay normal English.
• Dark theme is default. Keep UI functional and professional.

File structure

• Core models: shopdb/core/models/
• Core API routes: shopdb/core/api/
• Core services: shopdb/core/services/
• Plugin code: plugins/<plugin>/{models,api,services,schemas}/

Plugin development

When creating a new plugin:

1. Create directory plugins/<name>/. Use the scaffold (flask plugin new <name>) when available.
2. Include manifest.json with metadata. This is the single source of truth for plugin name, version, dependencies, api_prefix.
3. Extend BasePlugin class.
4. Follow naming conventions above.
5. Run flask plugin install <name> to install.

See the PLUGIN-QUICKSTART wiki page (when published) for the 30-minute walkthrough.

A plugin must not hold a DB session across external I/O

Rule: finish with the database before you call anything outside the process - an HTTP API (Dell warranty, ServiceNow, Zabbix, Azure/Intune), a subprocess, a file on a network share - and open a fresh session afterwards to write the result.

Why it is a rule and not a preference. The app runs gevent workers, so a request that blocks on a network call does not block its worker, and the call can take minutes without anything complaining. What it DOES hold for those minutes is a pooled database connection. Each worker owns a pool of DB_POOL_SIZE + DB_MAX_OVERFLOW connections (see shopdb/config.py and the arithmetic beside --workers in docker-compose.yml), and hundreds of greenlets can enter the same slow path at once. Drain the pool and every other request in that worker blocks on checkout and then fails - the whole site, every plugin, while the CPU sits idle and MySQL reports itself healthy. That is the worst diagnostic signature there is.

The shape to write:

# Read what you need, then let the session go.
servicetags = [row.servicetag for row in query.all()]
db.session.remove()

results = provider.bulk_lookup(servicetags)   # slow, no connection held

for servicetag, result in results.items():    # new session, short write
    ...
db.session.commit()

Rules of thumb: no requests, urllib, subprocess or network-share access between a query and its commit(); cap every external call with a timeout; and if a sync is inherently long, chunk it so each chunk is its own read / call / write cycle.

Testing

Run tests with:

pytest tests/

Tests are required for:

• New routes (smoke + happy path + 1-2 edge cases)
• New plugin hooks (contract test)
• Schema migrations (before/after data integrity)

Adding or changing an API route

The published contract is generated from the code, so it goes stale the moment a route changes and nobody regenerates it. A stale spec is worse than no spec: it is what a client generator, an agent, or the MCP server in tools/mcp/ will believe.

After adding or changing a route:

python scripts/gen_openapi.py --refresh

That rewrites docs/api-inventory.json and docs/openapi.json from the live app. It fills in what is derived and leaves prose you have written alone, so run it freely and then replace any seeded summary with the reason the route exists.

If it prints review against your route, it could not find a gate on the view. Do not hand-edit the inventory - the next refresh overwrites it. Either gate the view, or, if the route is genuinely public, name it in PUBLIC_ENDPOINTS in tests/test_core/test_public_read_surface.py with the reason. The generator reads that list, so the published contract and the enforced gate cannot disagree.

The api-contract CI job runs the parity gates and then regenerates and fails if anything changed, so a stale spec fails the pull request rather than being discovered months later.

Branches: what belongs on main, and what does not

main is the product every site runs and the publication mirror exports. <site> branches hold work that is not ready for other sites to see. There are two: wj here, and wilm on the corporate GitHub, where the other site develops the .NET endpoint agent.

A site branch is not a fork. Both feed main, and the sooner they do it the cheaper it is. A branch the dev box cannot see is still a branch: wilm is not visible from here because this machine has no GitHub account, which is why fetch-wilm-branch.cmd on the share exists to bring it back for review.

Most work is product. ADR-015 gives site differences three homes on main: a setting with a neutral default, seed data, or a site-namespaced directory (scripts/site_imports/<site>/, which the style gate exempts). That is the only site-specific home in the tree, so a site branch is about TIMING, not locality: things that are not ready yet, rather than things that are permanently ours.

Say which at commit time, with a trailer, because the decision does not survive being deferred - months later it is a list of subject lines and a guess:

git commit -m "Add the thing" -m "Scope: product"   # main should have it
git commit -m "Add the thing" -m "Scope: site"      # this site alone

Then:

tools/wj-status.sh                          # what is unpromoted, and where it belongs
tools/promote-to-main.sh --dry-run <sha>    # what files would reach main
tools/promote-to-main.sh <sha> [<sha> ...]  # oldest first; runs main's gates
tools/git-push.sh main                      # you push, deliberately

Windows equivalents are tools\git-push.cmd and tools\promote-to-main.cmd.

Promotion cherry-picks NAMED commits rather than merging the branch. Merging takes the site work along with the product work, which is how a site branch quietly becomes the product.

The failure to watch for is not what you think. Promoting something site-specific by accident is caught by the ADR-015 gate on the way into main. The real risk is product work sitting on a site branch until bringing it back is a port rather than a merge - one such round trip cost a MySQL dialect fix, a contract violation and a plugin install.

So rebase the site branch on main often, and promote as you go rather than in one batch at the end.

Code review checklist

• No underscores in table or column names
• No banned shorthand or unapproved acronyms in any new identifier
• DB-mirrored Python and JS variables match column names exactly
• API response keys match column names exactly
• No em-dashes, en-dashes, smart quotes, Unicode arrows, or emojis (run grep -rP '[^\x00-\x7F]' --include='*.py' --include='*.vue' --include='*.js' .)
• Plugin follows BasePlugin interface and contract version
• Tests included for new functionality