updated quality for ore

This commit is contained in:
2026-11-12 13:57:23 -07:00
parent 4fbad900a2
commit c8c5e658e2
12 changed files with 376 additions and 25 deletions

View File

@@ -119,18 +119,29 @@ The inventory view can be filtered by category and searched by name/class
name, and sorted by `name` (default), `category`, `quantity` (high to low) or
`updated` (most recently changed first).
Inventory rows store `(user_id, class_name, quantity, notes, visibility)`.
Adding an item that is already present increments its quantity; quantity, notes
and visibility can then be edited or the row removed. Every added item starts
`private`; the Visibility toggle switches it to `available` and back. Responses
are enriched live from the catalog. If a catalog item disappears after a
Inventory rows store `(user_id, class_name, quantity, notes, visibility,
quality)`. Adding an item that is already present increments its quantity;
quantity, notes, visibility and quality can then be edited or the row removed.
Every added item starts `private`; the Visibility toggle switches it to
`available` and back. Responses are enriched live from the catalog.
`quality` is an optional mining/refining value from **1 to 1000**. It is only
accepted for commodities that are actually mineable — ores, minerals and gems
(and their refined/raw/pure variants). Gases, organics, processed goods, crafted
alloys and salvage are excluded. The catalog exposes this as
`quality_applicable`; the UI shows a Quality input only for those commodities.
`null` means the owner has not recorded a quality. On `PATCH`, sending
`"quality": null` clears it, while omitting the field leaves it unchanged. Each
inventory row holds one quality (the schema keeps one row per commodity, so
different quality lots are not separated). If a catalog item disappears after a
dataset refresh, the row is reported with `available: false` instead of being
silently deleted (`available` is about the catalog, `visibility` is the owner's
classification).
The **Available** tab (backed by `GET /api/v1/available`) is public, like the
catalog: it lists every row marked `available` across all accounts with the
item's catalog details, quantity, owner username and last update. Private rows
item's catalog details, quantity, quality (when applicable), owner username and
last update. Private rows
never appear there and inventory notes are never exposed.
Clicking an item name in either **My Inventory** or **Available** opens the same
@@ -188,7 +199,8 @@ so no PostgreSQL server is required for the suite. Production uses PostgreSQL.
Commodities are deduplicated to one catalog entry per name (the 1 SCU container
variant is canonical); quantity lives on the inventory row, so 1 SCU, 8 SCU and
32 SCU crates of the same commodity share a single entry. Refined and unrefined
materials stay separate (`Iron` vs `Iron (Ore)`).
materials stay separate (`Iron` vs `Iron (Ore)`). Quality applies to both the
refined and raw/ore entries and is user-recorded per inventory row.
Tables are created on startup with an idempotent `create_all` and a connection
retry loop, so a fresh volume bootstraps itself and a slow PostgreSQL start does
@@ -212,8 +224,8 @@ GET /api/v1/auth/me -> {user}
GET /api/v1/me/inventory?category=&search=&sort=&page=&page_size=
GET /api/v1/me/inventory/summary
POST /api/v1/me/inventory {class_name, quantity?, notes?}
PATCH /api/v1/me/inventory/{class_name} {quantity?, notes?, visibility?}
POST /api/v1/me/inventory {class_name, quantity?, notes?, quality?}
PATCH /api/v1/me/inventory/{class_name} {quantity?, notes?, visibility?, quality?}
DELETE /api/v1/me/inventory/{class_name}
GET /api/v1/available?category=&search=&sort=&page=&page_size=