Apps you can install
Marketplace
Install what you need. Publish what you build. The catalog is a static host, so anyone can run one.
The bundled catalog
These 22 packages ship with obop (the packages/ directory of the repository, compiled into the program). Administrators install them from Customize, then Marketplace, or with obop modules install-from ID. The five built-in apps (Contacts, Products, CRM, Sales and Invoicing) are not listed here because they are always present. Each name links to its app page.
| App | Package id | Version | Description |
|---|---|---|---|
| Project | projects | 0.2.0 | Projects, milestones and tasks with assignees, deadlines and status flows. Progress is tracked by status, not computed from task effort. |
| Helpdesk | helpdesk | 0.2.0 | Support tickets with priority, severity, service-level targets and an open, in progress, resolved and closed flow. Targets are recorded, not enforced or timed automatically. |
| Fleet | fleet | 0.2.0 | Vehicles, drivers and service history for a small fleet. Tracks status and service records; it does not compute running costs or fuel use. |
| Inventory | inventory | 0.1.0 | Warehouses, stock locations, stock levels and stock moves. Quantities are entered and validated by people; they are not updated automatically by moves. |
| Purchase | purchase | 0.1.0 | Vendors, purchase orders and order lines with a draft, sent, confirmed, received and cancelled flow. Order totals are entered, not summed from the lines. |
| Manufacturing | manufacturing | 0.1.0 | Bills of materials and manufacturing orders with a draft, confirmed, in progress and done flow. Component stock is not consumed automatically. |
| HR | hr | 0.1.0 | Employees, departments and leave requests. Personal data is classified strictly: pay, bank and national id are visible to managers only, and health and union data to the special reader group. |
| Timesheets | timesheets | 0.1.0 | Time spent on project tasks, entered in minutes, with a billable flag and an approval step. Needs the Projects package. |
| Planning | planning | 0.1.0 | Shifts for employees, with roles and reusable templates. A shift has a day and a start and end in minutes since midnight (0 to 1439; 540 is 09:00). A shift with no employee is an open shift. Workflow: open, published, confirmed by the employee. Needs the Human Resources package. |
| Field Service | field_service | 0.1.0 | On-site jobs for customers, done by a technician: scheduled, en route, in progress, done or cancelled. A job records the customer, the site, the technician, the planned day and start (minutes since midnight), the parts used and whether the customer must sign off. Site address and contact details are personal data. Needs the Human Resources and Products packages. |
| Point of Sale | pos | 0.1.0 | Shop tills: a point-of-sale configuration, cash-controlled sessions that are opened and closed, orders with lines, and payment lines per method. A refund and the closing of a session need a human approval from a manager; agents may only propose them. Totals, change and cash differences are entered, not computed. Card numbers must never be stored; keep only the payment provider's reference. Needs the Products package. |
| eCommerce | ecommerce | 0.2.0 | An online shop: categories, product listings with translations, shipping methods, discount codes, web orders with lines and a fulfilment flow of pending, paid, shipped, delivered, cancelled and refunded. When the instance runs with the public site enabled, visitors browse the published listings and place orders without an account; the server prices every order from the published listing and never trusts the browser. There is no payment provider: an order starts as pending and the shop contacts the buyer. Refunds need a human approval from a manager; agents may only propose them. Customer name, email and addresses are personal data and are never public. Needs the Products package. |
| Website | website | 0.2.0 | Content for a public website: pages with a slug and a draft, published, archived flow, navigation menu items, blog posts with a byline and a publish date, translations of both, and the form submissions visitors send in. When the instance runs with the public site enabled it serves the published content to visitors as a server-rendered website with SEO and no login; only the fields marked public are ever visible to them. Publishing makes content public and needs a human approval, agents may only propose it. Senders are personal data and are never public. |
| Email Marketing | email_marketing | 0.1.0 | Mailing lists, the contacts on them with their consent status and date, and campaigns with a draft, scheduled, sent flow. Sending is irreversible and reaches real people, so it needs a human approval from a manager; agents may only propose it. Campaign statistics are numbers entered or imported, not computed. Contacts are personal data: keep consent_status and consent_date accurate and never mail a contact that is not opted_in. |
| Documents | documents | 0.1.0 | A register of business documents: folders, document records with kind, owner, expiry and confidentiality, and a draft, published and archived flow. It stores references, not file contents. |
| Sign | sign | 0.1.0 | Document templates and signature requests with a draft, sent, signed, declined, expired flow. A request names the signer (personal data) and keeps the signature evidence as references. A signed request is immutable by convention only: the platform cannot yet lock a record, so nobody should edit a request once it is signed, and the document_hash records what was signed. Sending and recording a signature need a human approval; agents may only propose them. |
| Subscriptions | subscriptions | 0.1.0 | Recurring plans and customer subscriptions with a trial, active, past due and cancelled flow. It records the next invoice date; it does not create invoices on its own. |
| Dashboards | dashboards | 0.1.0 | Dashboards and their widgets stored as data, for a UI to render. A dashboard has a title and an owner. A widget describes one tile with these fields: kind (kpi, bar, line, pie or table), model_name (the model to read, for example sale_order), measure_field (the field to aggregate; empty for count), aggregate (count or sum; sum needs a number or money measure_field), group_by (field to split by, for bar, line, pie and table; empty for a single kpi value), filter (a JSON object of field names to exact values, for example {"state":"paid"}; empty means all records) and position (order on the dashboard, lowest first). The package only stores the definition; it does not check that the model or fields exist and it computes nothing. |
| Accounting | accounting | 0.1.0 | Chart of accounts, journals, tax rates, journal entries with debit and credit lines, fiscal years and periods, and bank statement lines. Amounts are money fields in minor currency units and tax rates are numbers in basis points (2000 means 20.00 percent). Nothing is computed: balancing of debits and credits, tax amounts and entry numbers are the responsibility of whoever enters them. Posting an entry and closing a period or fiscal year need a human approval and the stricter accounting.approver group; agents may only propose them. |
| Knowledge | knowledge | 0.1.0 | A wiki: articles arranged in a tree through a parent article, with a draft, published, archived flow, a visibility setting and tags. Visibility is a label for the UI and for people to respect; the platform has no row-level permissions yet, so everyone with the Knowledge groups can read every article. |
| Appointments | appointments | 0.1.0 | Bookable resources (people, rooms, equipment) and appointments with a date, start and end time and a status flow. Overlaps are not prevented automatically. |
| Expenses | expenses | 0.1.0 | Employee expense claims with a draft, submitted, approved and paid flow. Paying is a separate permission and needs a human approval; receipts are referenced by note, not stored. |
Every package is checked on install: every field needs a description, a data class and a permission group, and personal data cannot be class none. Packages contain no code.
Install a package
In the web app: Customize, Marketplace, choose an app, Install. Installing needs the administrator group.
From the command line, against a database:
bash
obop modules market # list what is available
obop modules install-from helpdesk # install one
obop modules list # see what is installedPublish your own marketplace
A marketplace is any HTTP or HTTPS host that serves two things:
text
index.json a list of the packages
packages/<id>.toml the obop.toml of each package listedindex.json is an array of objects with id, name, version, description and an optional author:
json
[
{
"id": "assets",
"name": "Assets",
"version": "0.1.0",
"description": "A register of company equipment with a holder and a retire step that needs approval.",
"author": "Example Ltd"
}
]Package ids may contain only lowercase letters, digits and _. Point an instance at your host with the environment variable OBOP_MARKETPLACE_URL=https://example.com/market. The instance shows the bundled catalog first and your host after it; if the same id exists in both, the bundled one wins. Every download is validated exactly like an upload, and responses are limited to 1 MiB.
Package signing and paid listings are not built. Treat a third-party marketplace like any other software source: read the obop.toml before you install it. A package cannot run code or reach the network, which limits what a bad one can do, but it can still declare misleading fields or permissions.
Write a package
A package is one text file. The module manifest reference has a full tutorial, every key and every validation error. Test it without a database:
bash
obop modules check my-package.tomlLimits today
No signing, no ratings, no paid listings, no automatic updates, and no data migrations between versions. Uninstalling keeps the data.