Types, typed custom fields, directed relations and content languages let different inventories use one application without forcing one industry schema.
Media, master data, and stock information on an actual demo record
Scope
What this area changes in the data flow.
A household store and an equipment lab need different fields. Open Inventory combines stable inventory types, custom fields, relations, locations and media instead of hard-coding an industry model. The same structure is available through the UI and API.
Result 01
Add domain-specific types and fields without changing application code
Result 02
Connect containers, rooms, devices, people and projects with explicit relations
Result 03
Maintain larger datasets through search, filters and bulk updates
Included implementation
Individual capabilities and constraints.
These components are part of the MIT-licensed project. Optional providers are identified where they take part in a workflow.
01
Records with complete details
Store quantity, status, SKU, serial number, value, categories, tags, location, notes, priority, GPS or GeoJSON data and ordered media on each record.
02
Custom inventory types
Use bundled types for tools, objects, furniture, vehicles, locations, people, clothing and projects, or define custom types with stable API keys.
03
Typed custom fields
Add short or long text, numbers, booleans, dates, date-times, single or multiple choices, email, URL and dynamic references, including fields on serialized units.
04
Relations and containment
Configurable directed relations connect records. Manual placement and point-in-polygon derivation can represent rooms, cabinets, machines or projects.
05
Localized record content
A canonical language, per-field freshness, terminology guidance and queued regeneration keep generated translations reviewable and consistent.
06
Search, filters and bulk editing
Use the responsive grid or table, filter records, and update shared fields or append tags across a selected set.
Sequence
Start with a small schema and extend it deliberately
A field is useful when it is searched, filtered, validated or automated. Additional structure can be introduced as those requirements become clear.
01
Define inventory types
Use a bundled type or create a custom type with a stable key shared by the UI and API.
02
Add typed fields
Add only the required text, number, choice, date or reference fields for that type.
03
Create explicit relations
Represent containment, responsibility and spatial relationships as directed links rather than free text.
04
Search and update in bulk
Filter records and apply shared fields or additional tags to a selected set in one operation.
Worked example
Concrete records, states and decisions.
The values are mock data, but the workflow and state changes correspond to operations implemented by Open Inventory.
concrete example
Example · Equipment catalog
A measuring device is more than its name
The Measuring device type can add a serial number, calibration date and responsible person. Relations connect accessories and storage without flattening those facts into one notes field.
Type
Measuring device
Custom fields
Calibration · Owner
Relations
Accessory · Location
Real SwiftUI app capture · demo data
Open-source iOS implementation
The same structure is available on iOS.
The native client searches the same records as the web application. Location and other fields can be added while capturing the physical object.
Search by name, SKU, tag or location
Open and edit records with authenticated media requests
Use map, detail and settings screens implemented in SwiftUI
Types and fields are not hidden behind a proprietary vertical model. The MIT-licensed implementation, validated CSV paths and documented API provide several ways to inspect and reuse the data.
