(c) What a manifest can add
Part 3 of 4 · What you can use: API endpoints, record types, fields and screens
Every kind of thing a manifest can install, from the manifest's own schema (package_manifest.v1.schema.json). How to write each: chapter 7 and the manifest recipe; check yours with python3 tools/manifest/validate.py manifest.json.
Back: (b) Endpoints iVendNext calls on your serviceNext: (d) Screens you can add, and record types
| You can add | Manifest key | What it is | An example |
|---|---|---|---|
| Your addresses | allowed_urls |
The addresses your service is reached at; the retailer sees them at install, and every call your app's points make goes only there. | sample S1 |
| Record types of your own | doctypes |
Your own record types, each with its fields, permissions and Desk form and list. A settings record is one of them with issingle. |
sample S1 |
| Fields on existing records | custom_fields |
A field your app adds to one of the retailer's record types, such as a warranty reference on a sale's line. | sample S2 |
| Changes to how your own fields show | property_setters |
A change to how a field your app added shows on one of the retailer's record types; never a change to the retailer's own fields, and never making a field mandatory, read-only or hidden. | sample S1 |
| Print formats | print_formats |
A printed layout of a record: a receipt, a label, a price list page. | sample S2 |
| Notifications | notifications |
An email or a system message sent when a record changes or on a date. | sample S27 |
| Workspaces | workspaces |
Your app's page in Desk, opened from the App library: its shortcuts, lists and reports. | sample S1 |
| Sale details | sale_attributes |
Extra details carried on a sale, such as a delivery number or a boarding pass. | sample S17 |
| Webhooks | webhooks |
A signed call to your service when a record changes. | sample S2 |
| Reports | reports |
A report on the retailer's records, built from a query you declare, run in Desk. | sample S22 |
| Number cards | number_cards |
A figure on a workspace, such as today's sales. | sample S41 |
| Dashboard charts | dashboard_charts |
A chart on a dashboard or workspace. | sample S41 |
| Dashboards | dashboards |
A page of number cards and charts. | sample S41 |
| List settings | list_settings |
The columns and order a Desk list opens with. | sample S14 |
| Workflows | workflows |
Approval states and the buttons that move a record between them, each limited to a role. | sample S11 |
| Naming rules | naming_rules |
How your records are numbered. | sample S14 |
| Connections links | links |
Your records listed under one of the retailer's, such as pick tasks under a sales order. | sample S16 |
| The event feed | registered_applications |
Your app's event feed, one per app: the record types it follows. The install makes your app's own user with it. | sample S1 |
| Till keys | remote_keys |
A key on the till that calls your service and shows its answer. | sample S1 |
| Sandboxed functions | extension_modules |
A certified WebAssembly module at an extension point that takes one (the check before payment and pricing). | an accepted sample of its contract |
| Extension points | extension_subscriptions |
Your service at one of the till's or Desk's extension points: a check before payment, a capture, a partner page, and the rest of part (b). | sample S16 |
| Desk buttons | desk_actions |
A button on a record's form or a list, which sends the record to your service and shows its answer. | sample S16 |
| Save rules | save_rules |
Rules the retailer's records must meet when saved, applied by iVendNext itself: required fields, limits, sums. | sample S40 |
| Fiscal readers | fiscal_readers |
Fields a fiscal service may read from a sale and write back, such as a signature. | an accepted sample of its contract |
| List marks | list_marks |
A coloured label on a row of a Desk list. | an accepted sample of its contract |
| Register books | register_books |
The books of a regulated-stock register, such as a controlled-drug register. | sample S41 |
| Your app's words | translations |
Your app's words in a customer's language. | an accepted sample of its contract |
| Roles | none: name them where they are used | Each role your manifest names (in its record types' permissions, workflows or Desk buttons) that starts with your prefix is made, empty, by the install, and removed at uninstall; the retailer gives it to people. With an event feed the install also makes your app's own user with the role ⟨PREFIX⟩ Integration. Rights on the retailer's own record types are the retailer's to grant (chapter 7; the app's user). |
sample S11 |
| Settings | doctypes, with "issingle": 1 |
One record of your app's settings, no list, edited by the retailer in Desk and read by your service at /api/resource/⟨type⟩/⟨type⟩ (chapter 7). |
an accepted sample of its contract |
The keys that describe the app itself, not something it adds: manifest_version, app, prefix, version, title, publisher, description.
Back: (b) Endpoints iVendNext calls on your serviceNext: (d) Screens you can add, and record types