Build desktop apps for Odoo.
In an afternoon.

Start here

What is a .vapp?

One zip file. One window. The full Vizum desktop experience for free.

How it works

Why a vapp instead of a native Odoo module?

A native module is the right tool when you need to change Odoo's own core behaviour. For everything else — a department tool, a customer-facing mini-app, a dashboard, an integration — a vapp gets you there in an afternoon, with none of the server risk.

Start here

Quickstart — a TypeScript vApp with sdk-next SDK-next

Scaffold, build and pack a TypeScript vApp with sdk-next, the Vizum developer kit. It contains the typed SDK (@vizum/vapp-types), the UI tokens, charts, forms, the vzm CLI and the templates, as one pnpm workspace. You need Node 22.13+ and pnpm.

1. Scaffold from a template

From the root of the kit (sdk-next/):

node packages/vapp-cli/bin/vzm.mjs new vanilla-ts examples/my-app

A template's manifest.json already declares "min_platform": "5.67", the highest. Lower it only to install on an older platform, and only if your app uses nothing above that version: vzm check names the version each native declaration needs (see Platform capabilities).

2. Build and pack

pnpm install --filter ./examples/my-app...
cd examples/my-app
pnpm run build
pnpm run pack

pnpm run pack runs vzm pack dist and writes <id>.vapp: a zip of your built files plus the manifest.

3. Install

On the desktop, open the dock's apps menu, choose + Install .vapp, pick the file, then Open. An app that asks only for its own private data installs for any user. Anything more (Odoo records, server-side code, routes) needs an administrator's approval.

What the template does

import { connect, model, applyTheme, V } from "@vizum/vapp-types";

interface IResPartner { id: number; name?: string; email?: string }
const ResPartner = model<IResPartner>("res.partner");

await connect();     // the handshake, before any other SDK call
applyTheme();        // follow the desktop's accent and dark mode
const rows = await ResPartner.searchRead([["is_company", "=", true]], ["name", "email"], { limit: 8 });
V.ui.notify(`Loaded ${rows.length} partners`, "success");

Next:

• The toolchain: the vzm CLI, generating typed models from Odoo, and the packages.
• Server-side code: hooks, triggers and guards.
• Quickstart without a build step: three hand-written files.

Start here

The toolchain — vzm, TypeScript, Vite and the packages

Build vApps as visual and maintainable as a modern SaaS app — TypeScript, a typed ORM, a UI kit, charts, forms and maps — without changing how a vApp installs or runs. A compiled vApp is still the same .vapp the platform serves to the sandboxed iframe.

Two ways to build — same installable .vapp

"Compiled" only affects the developer's machine (a Vite build step). The output is the same zip of static files — installed by the store / api_install exactly as before. Hand-written and AI-generated single/multi-file vApps need no build.

TypeScript & a typed ORM

The SDK ships TypeScript types for every namespace, plus a generator that turns live Odoo metadata into typed models — autocomplete, compile-time safety, and far more reliable AI codegen.

// 1. generate typed interfaces from real Odoo fields
$ vzm introspect --from fields.json --out src/models.ts

// 2. use them — searchRead is typed; create() returns a SCALAR id (no number[] footgun)
import { SaleOrder } from "./models";
const rows = await SaleOrder.searchRead(
  [["state", "=", "sale"]], ["name", "amount_total"], { limit: 10 });
const id = await SaleOrder.create({ name: "From my vApp" });  // number, not number[]

The vzm CLI

Preview builds with source maps (feature preview-sourcemap). The Vapp Creator's preview asks the build service for the build's source map, so an error in the built page opens the line of src/… that threw. The map comes back beside the package, never inside it: the .vapp you install is byte-identical to a build without it. See Odoo introspection and preview source maps.

Multi-file — no single huge app.js, no build

A .vapp can hold as many files/folders as you like. The platform serves every file with Access-Control-Allow-Origin: *, so ES-module imports across files (incl. subfolders) work in the sandboxed iframe with no build step — keep big apps tidy either way.

my-app/
  index.html          <!-- <script type="module" src="js/main.js"> -->
  js/main.js          // import { renderHome } from "./views/home.js"
  js/sdk.js           // local model()/connect() — no npm
  js/views/home.js
  css/style.css

The SDK-next packages — the full kit

Nine tree-shaken packages under the @vizum/vapp-* scope. Import only what you use; every one bundles its assets and fetches nothing at runtime (a hard requirement inside the opaque-origin vApp iframe), and every one reads the host --vzm-* design tokens so it follows light/dark mode automatically.

Maps & external data

A vApp iframe can load CORS-enabled external resources directly — verified with MapLibre styles + OpenStreetMap tiles + Nominatim geocoding, no platform change. For APIs that don't send CORS headers, use the server-proxied Vizum.net.fetch.

Offline, PWA & native mobile

A vApp iframe runs on an opaque origin, so localStorage/IndexedDB are blocked inside it — a vApp can't keep its own offline queue. That's exactly why the host (the desktop page, with normal storage) owns the outbox behind Vizum.offline:

// only APPROVED manifest actions can be queued — never arbitrary writes:
//   "actions": [{ "name": "ticket.ack", "model": "helpdesk.ticket", "method": "action_acknowledge" }]
await Vizum.offline.status();                 // { online: boolean }
Vizum.offline.on((s) => render(s.online));    // live connectivity flips
const r = await Vizum.offline.run("ticket.ack", { ids: [42] });
//   online  → runs live now, returns { ok, result }
//   offline → the HOST queues it, returns { id, queued: true }
await Vizum.offline.pending();                // what's waiting in the host outbox
await Vizum.offline.flush();                  // replay on reconnect (also automatic)
Vizum.offline.onFlushed((r) => toast(`synced ${r.sent}`));

Since 5.80 the host also keeps the datasets your manifest declares on the device and queues Vizum.offline.create / write: read, write, and resolve conflicts with no coverage (Offline data; the offline-field-app template). Vizum Solo opens with no network after one online visit, and the Android app sends queued actions, creates and changes with the app closed (sdk-next/docs/offline-pwa-mobile.md). A service worker and install prompt for the desktop are not built; a vApp iframe can't register one.

Example gallery

15 example apps ship with the toolchain — every one verified running in the desktop.

Start here

Quickstart without a build step

Three files, one zip, one click to install.

{
  "schema": 1,
  "id": "com.acme.hello",
  "name": "Hello Vizum",
  "version": "1.0.0",
  "entry": "index.html",
  "icon": "icon.png",
  "window": { "w": 360, "h": 300 },
  "permissions": { "data": "user" }
}

<!DOCTYPE html>
<html><head>
  <meta charset="utf-8">
  <link rel="stylesheet" href="/vizum_apps_platform/static/sdk/vizum-glass.css">
</head>
<body style="padding:16px">
  <div class="vz-card">
    <h2>Hello!</h2>
    <p>Opened <b id="n">…</b> times by you.</p>
    <button id="reset" class="vz-btn">Reset</button>
  </div>
  <script src="/vizum_apps_platform/static/sdk/vizum-sdk.js"></script>
  <script src="app.js"></script>
</body></html>

(async function () {
    await Vizum.connect();                          // handshake with the desktop
    const n = ((await Vizum.data.get("opens")) || 0) + 1;
    await Vizum.data.set("opens", n);               // persisted per user, in Odoo
    document.getElementById("n").textContent = n;
    document.getElementById("reset").onclick = async () => {
        await Vizum.data.set("opens", 0);
        Vizum.ui.notify("Counter reset", "success");
        Vizum.window.close();
    };
})();

Zip it (plus any 256×256 icon.png) and install:

cd hello-vizum/
zip -r ../com.acme.hello.vapp . -x '.*'

On the desktop: dock 🧩 → “+ Install .vapp” → pick the file → Open. Because this manifest only asks for private data, any user can install it instantly — no admin needed.

Start here

Package anatomy

A .vapp is a renamed zip with one required contract: the manifest.

my-app.vapp
├── manifest.json          // REQUIRED — identity + permissions
├── index.html             // REQUIRED — your entry point
├── app.js                 // your code, any structure you like
├── style.css  assets/…    // css, images, fonts — vendor everything
└── icon.png               // REQUIRED — square PNG, 256×256

Concepts

The manifest, field by field

Your app's identity, window preferences and — most importantly — its permission contract.

{
  "schema": 1,
  "id": "com.yourcompany.appname",
  "name": "App Name",
  "version": "1.0.0",
  "min_platform": "5.49",
  "entry": "index.html",
  "icon": "icon.png",
  "window": { "w": 420, "h": 560, "singleton": true },
  "permissions": {
    "data": "user",
    "orm": [
      { "model": "sale.order",
        "ops": ["search", "read"],
        "fields": ["name", "amount_total", "state"],
        "domain": [["user_id", "=", "uid"]] }
    ],
    "ui": ["notify", "openRecord"],
    "events": { "emit": ["myapp.ping"], "listen": ["otherapp.pong"] }
  }
}

Concepts

Permissions & install tiers

Declare exactly what you need. Admins approve exactly what you declared. The server enforces it on every call.

The two install tiers

Write actions ask the user

Every mutating ORM call (create, write, unlink, call: methods other than the grant's read_calls, 5.105) pops a host-rendered confirmation the sandboxed app cannot fake or skip: “AppName wants to create 1 account.move record — Allow / Deny”. Creates, updates and method calls ask once per app + operation + model and are then remembered; deletions ask every time. Users reset an app's remembered grants from Vizum Apps (↺ on the card). Denied calls reject with Error("UserDenied") — handle it gracefully.

An administrator's approval covers the declared actions (5.149)

With action consent (Vizum.supports("action-consent")), the administrator who approves an app version also approves, for the companies they have selected, the create, write, call:, chatter notes, activities and named actions that version declares: users of those companies are not asked for them. What the app may do does not change: the approved grant, Access Manager and the user's own Odoo rights decide that.

• Never covered (the user is asked, and their own 30-day «don't ask again» works as before): every unlink, every mail.post, a method on the fixed list (post, send, validate, confirm, done, cancel, approve, reverse, draft, reconcile, refund, pay, payment, scrap, inventory, delete, create_invoices … as a word of the name, or inside a word of four letters or more: action_postmail, invoice_repost), anything marked "sensitive", a grant on "*", uploads and offline writes.
• "sensitive": true or a list of the grant's own ops on a permissions.orm grant, true on an actions[] entry; needs min_platform 5.149. An app built for it must mark every fixed-list action on a model it does not own: vzm check and the installer refuse with SENSITIVE_NEEDS_PLATFORM, SENSITIVE_INVALID, SENSITIVE_REQUIRED.
• Lifecycle: one approval per app, version, package and company. An update with the same server code and grants carries it (never wider); any other update drops it. Uninstall, disable or a trust change removes it. An administrator withdraws or grants it in Vizum Apps › the app › Manage, and a company keeps asking for everything with Settings › Vizum › App actions.
• The server re-checks every call the desktop ran without asking and refuses a stale one with CONSENT_STALE; the desktop then asks the user and retries once. Each consented action is audited (consent:action, one line per action and hour with a count).

Full reference: sdk-next/docs/action-consent.md.

Your app's own groups

native.groups creates real Odoo groups for your app; access, rules, views and team roles name one as "@name". An app declares up to 24 (SDK 5.118; 8 before, so more than 8 needs min_platform 5.118), and the labels of one app's groups are unique.

On Odoo 19 a heading in Settings › Users is one selection: an administrator picks one group under it. Give each independent role a heading of its own with privilege (SDK 5.118), and keep a chain of groups that imply each other under one:

"groups": [
  { "name": "technician",   "label": "Technician",    "privilege": "Access level" },
  { "name": "admin",        "label": "Administrator", "privilege": "Access level", "implies": ["@technician"] },
  { "name": "role_sales",   "label": "Sales",         "privilege": "Sales role" },
  { "name": "role_support", "label": "Support",       "privilege": "Support role" }
]

Each label becomes a heading named <app name>: <label>; groups without privilege keep the heading named after the app. Odoo 17 and 18 have no headings of this kind and already show groups that are not a chain as checkboxes, so the key changes nothing there. Check for it with Vizum.supports("native-groups-24").

A rule on a user's groups

A record rule can ask whether a user still holds one of your app's roles (SDK 5.125). A Representative reads only the cases of a technician assigned to him who still holds the Distributor role:

"domain": [
  ["x_representative_id", "=", "uid"],
  ["x_technician_id.$groups", "in", {"$group": "@role_distributor"}]
]

$groups is the last hop of a path that ends on a user; {"$group": "@name"} is one of the groups your app declares in native.groups, never an xmlid or an id; the operator is in or not in. Groups that imply the role count. Who holds the group is read at every search, so a role taken away (Vizum.team, the user form, Settings › Groups) is seen by the next search, and a group that no longer exists makes the whole rule match nothing. It needs min_platform 5.125; check for it with Vizum.supports("rule-domain-group").

Vizum.team: your app's users and roles

With permissions.team (privileged, approved by an administrator) and native.team, the managers of your app create and edit the users who play the roles your manifest declares, without an Odoo module. The app sends role names, never groups; the server gives exactly the groups the approved roles name, never an administrative one.

"native": { "team": {
  "managers": ["@admin"],
  "roles": [
    { "name": "tech",     "label": "Technician", "groups": ["base.group_user", "@tech"] },
    { "name": "sales",    "label": "Sales",      "groups": ["base.group_user", "@sales"] },
    { "name": "admin",    "label": "Management", "groups": ["base.group_user", "@admin"], "grant": "admin" },
    { "name": "approver", "label": "Approver",   "groups": ["base.group_user", "@approver"], "grant": "admin" }
  ] } }

The primary role. role is chosen as before 5.116: drop every held role another held role outranks (A outranks B when B's own groups are in what A's own groups imply, and A has more); among the rest, the role declared last wins. roles[0] is therefore not always role. Give every role one marker group of its own and let the markers imply the shared capability groups: a member then plays exactly the roles whose markers they hold.

The trail. Every change writes one row to your app's audit trail: platform:team.create, .update, .roles, .activate, .deactivate, .password, .invite or .remove, with who did it, the target, the roles before and after and whether a password changed, never the password itself. A refused change writes platform:team.refused, kept even though the change was rolled back. Your app cannot write these actions. In Vizum.audit.search a member who is not a manager sees only the team rows about themselves; your app's own rows stay visible as before. Sending roles, declaring grant or calling history needs min_platform 5.116.

Concepts

Version compatibility — write once, run on every Odoo

A .vapp keeps working when the customer upgrades Odoo (17 → 18 → 19 → 20 → …). You don't repackage it. Here's why, and the handful of rules that keep it true.

Why your app survives upgrades

• The SDK is shared, never bundled. Your package does not contain a copy of vizum-sdk.js — it loads the platform's single shared copy. Upgrading the platform upgrades the SDK for every installed app at once; there are no stale copies.
• The window.Vizum contract is version-stable. The transport (postMessage) and every namespace below are the same across Odoo versions. The platform absorbs the Odoo internals.
• Renamed core fields are translated for you. Odoo occasionally renames a field (e.g. res.users.groups_id became group_ids in 19, and 20 keeps it). The orm proxy transparently maps the known renames in both directions, so an app written against either name keeps reading/writing/searching it on any version — the result comes back under the name you asked for.

Checked against the instance itself (feature odoo-introspect). Besides the atlas of Odoo 17–20, the Vapp Creator reads the instance it runs on: every model, the fields the user sees, the methods with the modules that define them (Community, Enterprise or custom) and whether the bridge would run each one. It reads code, never data, and the code it hands over is redacted of credential-looking literals on a best-effort basis. See Odoo introspection.

What the app does to Odoo's views (feature view-inspect). The instance answers, for the IDE apps, each native view a package touches without and with the app, where each field lands, the other modules' views on the same nodes and the findings (VIEW_*), simulated with the installer's own code; nothing is written. See Odoo introspection and view inspection.

Three rules to stay future-proof

1. Never read group fields off res.users directly. Use Vizum.user / Vizum.roles (below) — they speak stable group XMLIDs, which never change between versions.
2. Stick to standard fields. id, name, login, lang, tz, company_id, currency_id, create_date, write_date, display_name are stable everywhere.
3. Branch on the version only if you truly must — Vizum.session.odoo_version gives the running major (17/18/19/20).

Vizum.user — version-safe identity & groups

No permission required (it only ever reveals the current user's own info).

await Vizum.connect();
Vizum.user.id;        // 12        (sync, from the handshake)
Vizum.user.name;      // "Jane Doe"
Vizum.user.isAdmin;   // true if ERP-manager/admin
Vizum.user.isSystem;  // true if in base.group_system

// is the user in an Odoo group? (stable XMLID — works on every version)
if (await Vizum.user.inGroup("sales_team.group_sale_manager")) showApproveButton();

const xmlids = await Vizum.user.groups();  // the user's OWN group XMLIDs
const full   = await Vizum.user.info();    // {id,name,login,isAdmin,isSystem,company,lang,tz}

Vizum.scope — am I per-user or global?

Tells your app which storage scope it runs in, so you can label the UI honestly (“shared with everyone” vs “your data”). Derived from your approved manifest.

const s = await Vizum.scope();
// { data: "user" | "global",        // your Vizum.data / key-value scope
//   tables: { notes: {shared: true} }, // per Vizum.db table
//   install_scope: "user" | "admin",
//   default_access: "all" | "restricted" }
if (s.data === "global") banner("Notes are shared with your whole company.");

Declaring scope is done in the manifest, not at runtime: permissions.data: "global" makes the KV store company-wide (privileged); a tables[].shared: true table gives each row an owner + per-row sharing (Vizum.db.share()), versus the default per-user isolation. See Permissions & tiers and The manifest.

Vizum.roles — declarative app roles

Map your own role names to Odoo groups in the manifest; the platform evaluates them as the real user (stable has_group(xmlid)) so the answer is trustworthy.

"roles": [{"name": "manager", "label": "Approver",
           "groups": ["sales_team.group_sale_manager", "base.group_system"]}]

if (await Vizum.roles.has("manager")) enableApprovals();
await Vizum.roles.mine();   // ["manager", ...] the roles the user has

Concepts

Platform capabilities and min_platform GENERATED

Current platform capability: 5.156.

A vApp declares the capability it needs in its manifest, "min_platform": "x.y". The installer refuses the app on an older platform instead of installing it and letting the feature fail at runtime (often silently: an ignored key, a missing V.* name, a guard that never runs). Set it to the highest row whose feature your app uses; a higher value only locks out instances for nothing.

Versions compare numerically per part: 5.9 < 5.10 < 5.54.

Summary

Details

5.156

AN ADMINISTRATOR CONFIRMS EVERY CHANGE TO A SHARED OAUTH PROVIDER CONFIGURATION (the number is PROVISIONAL, fixed at merge in merge order; 5.155 is the AR app layer + Vizum.motion, #4785). oauth.configure changes one entry shared by every app and connected account of the database: the desktop host shows what the change does and stores it only once an administrator confirms it; the server refuses a new client_id or a removed scope while accounts hold tokens, and any move of a stored custom provider's endpoints (a rotated secret is allowed). Solo and native hosts reject configure. Feature oauth-configure-confirmed.

5.155

AR APP LAYER + MOTION (the number is PROVISIONAL, fixed at merge; design: docs/superpowers/plans/ 2026-10-25-ar-app-layer-motion.md). (1) Vizum.ar.start({layer: "app"}) puts the camera BEHIND the app: the iframe moves above the host's video and becomes transparent, and the app receives the ar:frame event, built by ONE whitelist function from numbers only (corners in video and CSS pixels, a pinhole projection, a field of view that is never null) at up to 30 Hz, with a window of 3 unacknowledged frames. No pixel ever reaches the app. The host chrome (the "using the camera" strip, Close, the border) stays above the app; losing it, a fullscreen, or 5 s of being covered stops the camera. capabilities().ar gains layer and layer_reason. (2) New closed permission permissions.sensors: ["motion"] (min_platform 5.155, a widening on update): Vizum.motion.start / stop / status relays the device's tilt and movement through the HOST (rounded, throttled, one stream per window); the iframe gets no sensor API and no allow= motion token. capabilities().motion reports why it is unusable. Features ar-layer and motion. See sdk-next/docs/ar.md and motion.md.

5.154

VIZUM AR ON THE /vizum/pwa PWA, VIZUM SOLO AND THE NATIVE MENU HOST (the number is PROVISIONAL, fixed at merge). Vizum.ar was served by the desktop only; now the Solo shell (solo_host.js + solo_instance.js: the same page is the browser PWA and what the Android APK loads) and the native menu host serve it too, through the one shared js/ar/ar_bridge.js: same start / stop / overlay / status, same events, same start failure reasons, the same vizum:ready.ar report {usable, camera, granted, reader, reader_kind}. The administrator's zxing-wasm switch is rendered into the runner page (absent = off) and the bundled reader is kept by the PWA's service worker, so a start also works offline after one online start. Feature ar now lists hosts desktop, native, solo. No new grant (media camera). See sdk-next/docs/ar.md.

5.153

A ROLE REMOVAL REACHES AN APP INSIDE THE WRITING TRANSACTION (native.membership[].sync: "narrow"; the number is PROVISIONAL, fixed at merge in merge order; evolution renumbers). An entry that opts in is told the users who LOST its groups from the res.users / res.groups write or unlink itself, as the app's job identity, in a savepoint with a 5 s budget: the app's audience and the role commit or roll back together, so the next search in the same request no longer shows the old audience. A handler that fails or times out aborts the write with an error naming the app; archiving or deleting a user never aborts: it records a row in vizum.app.membership.revoked, audits and notifies, and the bridge and the job runner refuse that person for that app until a handler later succeeds (rows never expire). A settings administrator can switch it off per app (reason required, audited, persistent fail-open banner). Widening stays asynchronous. Feature native-membership-sync. See sdk-next/docs/native-membership.md.

5.152

A SCRIPT'S env.flush_all() WORKS. Module code translated into a vApp calls it (a census reads its own rows with SQL right after writing them); the script env had no such method. It flushes what this transaction already changed, takes no argument, returns None and hands out no cursor. Feature script-env-flush-all.

5.151

VIZUM AR (Vizum.ar): a host-mediated camera view that reads barcodes and QR codes and draws, over each code, a text card the vApp described. Vizum.ar.start / stop / overlay / status and the events ar:codes, ar:tap and ar:state. Same grant as Vizum.vision (permissions.media ["camera"], no new approval; the approval card now says the camera also recognises codes). The video never leaves the host: the app receives code VALUES and sends a value -> card map; cards are plain text. The view never writes to Odoo. The reader is the browser's BarcodeDetector; where it is missing, a vendored zxing-wasm reader runs ONLY if the administrator switched it on (Settings > Vizum Apps, vizum_apps_platform.ar_wasm_engine, OFF by default, legal review pending; the server answers 404 for the engine files while it is off, and never serves bytes that do not match their pinned sha256). Feature ar (desktop). min_platform 5.151; vzm check AR_NEEDS_CAMERA and AR_MIN_PLATFORM. See sdk-next/docs/ar.md.

5.150

AN OFFLINE / UNREACHABLE UNIT IS A UNIT_OFFLINE RESULT, NOT A CLOUD_ERROR. The two cloud codes for "the unit is offline" and "the unit did not answer" resolve to UNIT_OFFLINE (a normal state, logged at INFO); every other cloud error keeps CLOUD_ERROR. Feature net-provider-thermostat-json-offline.

5.149

AN ADMINISTRATOR'S APPROVAL COVERS AN APP VERSION'S DECLARED ACTIONS (action consent, option D, Enrique 2026-10-22). Approving an app version records, per company, a consent covering the create / write / call: / mail.log / activity / named actions it declares (vizum.app.action.consent); the desktop stops asking users for those and flags the call, the server re-checks it (CONSENT_STALE) and audits it (consent:action). Never covered: unlink, mail.post, the fixed list of methods, actions marked "sensitive" (manifest key, needs this capability; SENSITIVE_REQUIRED for an app built for it), uploads and offline writes — the user's own 30-day memory works for them as before. A company can keep asking (res.company.vizum_ask_app_actions). Feature action-consent (desktop). See sdk-next/docs/action-consent.md.

5.148

A DECLARED PROVIDER BRINGS ITS OWN PINNED HOSTS. For an app that declares permissions.providers, the platform reaches the provider's fixed host list itself and never reads the app's permissions.net for it, so no public text or manifest names a vendor host; an app that still lists them keeps working, and declaring a provider grants no V.net.fetch to those hosts. An app that lists none sets min_platform to this capability (vzm check: PROVIDER_HOSTS_FLOOR). Feature net-provider-supplied-hosts; the adapter's constant carries the same number. See sdk-next/docs/net.md.

5.147

thermostat_query ALSO returns the live sensors of the cloud thermostat (current_F, humidity, a fault flag and sensors_at — the epoch of the last successful reading) over the provider's existing device channel, gated on this capability so a vApp tells 'the platform does not know the field' (absent) from 'the sensor read failed' (present, null). The adapter's sensor capability constant and contract feature net-provider-thermostat-json-sensors carry the same number. See sdk-next/docs/net.md.

5.146

A VIEW A VAPP WRITES THROUGH THE ir.ui.view BRIDGE GETS THE CHATTER MARKUP OF THE RUNNING ODOO (the number is PROVISIONAL, fixed at merge in merge order; 5.145 is #4492). 5.144 converts the form chatter at install (native.ui); a view the vApp creates or writes at runtime through the ORM bridge now goes through the same conversion, in the same order as install (chatter, then QWeb directives). A write that names no model or type takes them from the stored view or its parent; an xpath the platform cannot convert is refused as the bridge's normal error (AccessError), and one write to several views that need different markup is refused. Feature ui-chatter-per-version-runtime; ui-chatter-per-version keeps since 5.144. See vizum_app_orm_guard.py _orm_model_guard and sdk-next/docs/server-side.md.

5.145

CLOUD THERMOSTAT OPS. V.net.provider('hvac_cloud', 'thermostat_query'|'thermostat_control', args) read the status and set the setpoint/mode/power of a cloud thermostat: the op is transcoded to a device frame through a SECOND provider session and delivered by the provider's existing device channel. The ops fail closed (UNSUPPORTED_OP) until this capability is assigned; the adapter's capability constant and contract feature net-provider-thermostat-json carry the same number. See sdk-next/docs/net.md.

5.144

NATIVE.UI WRITES THE FORM CHATTER IN THE MARKUP OF THE RUNNING ODOO (the number is PROVISIONAL, fixed at merge in merge order; evolution renumbers). Odoo 17 compiles only <div class="oe_chatter"> and Odoo 18/19/20 only <chatter/> (mail form_compiler.js, selector "div.oe_chatter" vs "chatter"); the other form shows as raw field lists. A view of native.ui written for either goes in with the markup of this Odoo, as <list>/<tree> already does: <div class="oe_chatter"> becomes <chatter/> on 18+, <chatter/> becomes the div with the chatter fields the view's model has (mail.thread: followers and messages; mail.activity.mixin: activities) on 17; the options of those fields and the attributes of <chatter> (open_attachments, reload_on_post/follower/attachment) are carried across, and an inherited view's xpath into the chatter (//chatter / //div[hasclass('oe_chatter')]) follows. A vApp with a chatter runs on 17 to 20 with no min_odoo. No manifest key changes; an older platform leaves the arch as written. Feature ui-chatter-per-version. See models/vizum_app_records.py adapt_chatter_arch and sdk-next/docs/server-side.md.

5.143

SERVER-SIDE GEOCODING: Vizum.map.geocode(query) / V.map.geocode(query) (the number is PROVISIONAL, fixed at merge in merge order; 5.142 is Access Manager 9c; Enrique approved the design 2026-10-21 16:04). No vApp sends a customer address to a third party from the browser: the PLATFORM server resolves the query with the provider the administrator chose in Settings › Vizum › Geocoding — none (the default: the call fails with GEOCODE_NOT_CONFIGURED), a Nominatim base URL (self-hosted or compatible), or a key + URL template for a commercial service (the key stored encrypted, secret_box namespace vizum.geocode). The provider is reached by the pinned transport under the public-only policy (net_allow_private opens private addresses, never cloud metadata). permissions.geocode (a privileged boolean, min_platform 5.143); per-app rate limit (60 a minute and 2,000 a day by default, settable); a cache shared by the instance (provider + normalised query + options, 30 days by default) keyed by a hash of the query (the cached results hold the provider's formatted address); every answer audited in vizum.geocode.audit (app, user, time, provider, the query as SENT, whether it left the instance), kept 180 days. Query 2-200 characters; at most 10 results of scalars {lat, lon, display_name, category, type, importance}. V.map is refused in a declared read call. Feature geocode. See models/vizum_geocode.py, models/geocode_providers.py and sdk-next/docs/geocode.md.

5.142

ACCESS MANAGER 9c: BACKEND UI SWITCHES, SCREEN ONLY (PROVISIONAL, fixed at merge in merge order). vizum.access.profile gains ten ui_* switches (search panel, custom filter, custom group by, saving a favourite, chatter send / log / activity, «Insert in spreadsheet», «Add a property», Archive / Unarchive). session_info carries the member's switches as vzm_access_ui; the web client hides those entries. Each is screen only: Access Manager names the server guard to pair it with, where one exists. Never for an administrator. An open tab keeps the switches it loaded until it is reloaded. Feature access-profile-ui-policy. See static/src/js/access_policy/ui_policy.js and sdk-next/docs/server-side.md (9c).

5.141

ACCESS MANAGER 9b: READ-ONLY EVERYWHERE (PROVISIONAL, fixed at merge in merge order). vizum.access.profile gains readonly_user: its members read what Odoo lets them read and write only their own preferences, Discuss (the channels they are in) and «mark done» on their own activities (D3, measured on 17-20). Two layers: the request's dispatched method must be a read method or a measured D3 entry point (closes a button that writes under sudo()), and Odoo's own access check per line refuses any other write; a vApp the member runs reads Odoo records and writes none. Administrators, the superuser, OdooBot, job users and service users are never members. Feature access-readonly-user. See models/vizum_access_readonly.py and sdk-next/docs/server-side.md (9b).

5.140

ACCESS MANAGER 9a: a restriction profile's time window (PROVISIONAL, fixed at merge in merge order). vizum.access.profile gains starts_at / expires_at (UTC; a missing bound is open) and the platform-owned in_window: outside its window a profile has no members, so every restriction it holds lifts at once and comes back together. A job runs every minute (data/access_window_cron.xml) and re-syncs each profile whose window opened or closed; writing a window takes effect at once; each boundary is logged (window_opened / window_closed). A window that ends while the job is down keeps the restriction (fail closed); one that starts late is said by the app's health check access_windows when the job is more than 2 minutes behind. Feature access-profile-window. See sdk-next/docs/server-side.md (Time windows, 9a).

5.139

ANOTHER APP'S PRIVATE METHOD IS CALLABLE ONLY BY THE SAME VERIFIED PUBLISHER OR A NAMED APP (the number is PROVISIONAL, fixed at merge in merge order; issue #4387, Enrique 2026-10-20). A call:<m> grant used to reach any native method of any other app the person uses, public or not (an approved com.example app drove Remote Metering's rm_rule_save). Now a non-public method of app X is callable by app Y only when (1) both are VERIFIED as published by the same publisher key (publisher_signed_key of a package whose recorded trust still holds; the Store-named key for a store-verified one; never an id prefix; unsigned, sideloaded and unverified packages have none), or (2) X lists Y in native.methods[].callable_by (1-16 app ids, surfaced as permissions.callable_methods, widening re-approves), or (3) the method is public: true. Refused otherwise with an AccessError naming both apps, at call time on every road (bridge, callOn, V.orm.call, the action catalogue, a record method in a script) and at install, update, approval and preview when the owner is installed. Odoo's own methods, overrides and the app's own are unaffected. A vApp that declares callable_by sets min_platform 5.139. Feature native-method-callable-by. See models/vizum_app_methods.py (private_owner), tools/audit_cross_app_private_calls.py and sdk-next/docs/grants.md.

5.138

V.net.provider('hvac_cloud', op, args): a vApp's server side (native methods, hooks, jobs) signs in to an HVAC cloud provider through the platform's adapter. Server-side only; the ops are fixed: login / list_appliances / send_frame / logout. Credentials are read by declared secret name; the session is kept encrypted in vizum.app.provider.session and is never readable by scripts, the iframe, the secrets listing, exports or logs; logout, uninstall and a credential change drop it. Until the supplied-hosts capability the provider's host is named in permissions.net; every HTTP request is metered as one network call; a refused session gets one re-login and one retry. permissions.providers ["hvac_cloud"] carries an approval line and no install floor: apps feature-detect with has_attr(V.net, "provider"). vzm check rules PROVIDER_NOT_DECLARED / UNKNOWN_PROVIDER / MIN_PLATFORM_TOO_LOW -> PROVIDER_FEATURE_DETECTED. Feature net-provider. See sdk-next/docs/net.md.

5.137

native.adopt TAKES UP TO 120 ENTRIES (was 80) AND native.methods UP TO 1500 (was 1000) (the number is PROVISIONAL, fixed at merge). 5.132 raised native.models to 120 and left adopt at 80; a large ported vApp adopts 84 and has 1032 methods. One constant per list in vapp_validation.py (NATIVE_MODELS_MAX also caps adopt; METHODS_MAX), mirrored in vzm check (native.mjs): more than 80 adopt entries or more than 1000 methods sets min_platform 5.137. Feature native-adopt-120 and native-methods-1500. See docs/superpowers/progress/HANDOVER-native-adopt-cap-5137.md.

5.136

UNINSTALLING THE WINDOW MANAGER OR THE PLATFORM IS SAFE (the number is PROVISIONAL, fixed at merge in merge order; Enrique 2026-10-19, «esto tiene que quedar resuelto y funcionando al 100% y probado»). uninstall_hook raises a per-registry flag first, so every registry override answers super() while Odoo removes the module's data (no platform column dropped while its table survives, no model left behind); then it DETACHES the vApps and keeps their data: the automations and server actions that call the platform go dormant, method computes become plain columns, groups named in inherited views are rewritten, native menus are removed, access rows of platform groups go to base.group_system and record rules bound only to them are deactivated; what each app was is written to a signed DETACH LEDGER the module does not own. With vApps installed an interactive uninstall opens a wizard (uninstall them first / detach and keep the data / cancel). A reinstall re-adopts the ledger's apps as needs_approval through the same trust path their install used (a signed app is installed again from the Store). Feature safe-platform-uninstall. See models/platform_leaving.py, platform_detach.py, platform_readopt.py, platform_uninstall_guard.py and sdk-next/docs/platform-uninstall.md.

5.135

GUARDED ORM CALL: expect ON orm.call / callOn / V.orm.call (the number is PROVISIONAL, fixed at merge in merge order; Enrique approved the design 2026-10-18 12:35). expect: {field: value} plus ids makes the call run its native method only while the records still hold those values: in one transaction the platform reads the records as the user, locks the readable rows (SELECT ... FOR UPDATE, ids sorted, 5 s), re-reads the fields as the user and, if every record matches, runs the method holding the locks. Otherwise nothing runs, for any id: STATE_CHANGED (current values of the expected fields only; null for a record missing or unreadable) or BUSY (retryable, the lock wait ran out). Up to 100 ids and 10 stored fields of a comparable type, inside the grant's fields and not hidden from the user. Same grant, ACLs, allowlist and write ceiling as a plain call. It does not make the method idempotent, and a method that commits ends the locks. Feature orm-expect. See models/orm_expect.py and sdk-next/docs/guarded-call.md.

5.134

WEB BLUETOOTH IN A vAPP: permissions.devices accepts "bluetooth" (min_platform 5.134); when the APPROVED manifest lists it the host adds bluetooth * to the app frame's allow (same pattern as serial *; VappHost, Solo's computeAllow), so the standard navigator.bluetooth.requestDevice() works — the browser still shows its own chooser and needs a click. Adding it on an update is a widening (re-approval). No server op. Vizum.supports("devices.bluetooth") is true when the frame is delegated AND the browser has Web Bluetooth (the Android WebView has none).

5.133

ACCESS MANAGER 5d: the field mode hide is offered (access_field_policy.modes.hide.min_platform): a hidden field is also hidden on the platform's own read paths. native.methods / the script library raise an AccessError naming the field when a method reads it by attribute (read / search_read leave it out; a domain, dotted path, groupby or aggregate on it is refused; the REAL user decides, also inside the app's sudo()); the AI Assistant leaves it out and refuses a search or grouping on it; a dashboard shared by its owner hides a field hidden from the owner OR the viewer; the knowledge index never indexes a field any active profile hides or makes unreadable on that model, and reindexes when that set changes. vzm check warns METHOD_READS_FOREIGN_FIELD. Feature access-field-hide. See sdk-next/docs/server-side.md (5d).

5.132

UP TO 120 OWN MODELS PER APP (was 80 since 5.63). A large ported vApp has 81; RULE V: a vApp does what a module does. One constant, vapp_validation.NATIVE_MODELS_MAX (mirrored by NATIVE_MODELS_MAX in sdk-next/packages/vapp-cli/ lib/native.mjs). A vApp with more than 80 models sets min_platform 5.132 (vzm check says so). Feature native-models-120. See docs/superpowers/progress/HANDOVER-native-models-cap-5132.md.

5.131

AN ADMINISTRATOR VIEWS AND SETS AN APP'S JOB USER; AN APP WITH A SERVICE USER RUNS AS IT ONLY (the number is PROVISIONAL, fixed at merge in merge order; requested for Access Manager D1, Enrique 2026-10-18, and by the Assets audit). vizum.app.api_get_app_job_user(key, search) and api_set_app_job_user(key, choice) (administrator only, checked on the server; choice is a user id, "service" or "default"), and Settings > App Permissions > Job user. Refused with the reason: the superuser, archived and portal users, another app's service user, a user outside the app's company, an administrator when no model of the app is admin-only, a user lacking what the app declares it needs (read from native.models[].access; named, never granted). An app that declares a service user (native. service_user, or a field only its server side writes) runs as it and as nobody else: the setter and a direct write of job_user_id refuse any other user; a row that names a person is shown as degraded with a one-click fix. Audited as platform:job_user; every write of the field clears the native runtime cache. The trigger payload gains rec["svc"]: True when env.uid of the write is the app's own service user (read it as rec.get("svc") unless the app declares min_platform 5.131). Features job-user-admin and trigger-svc. See models/vizum_app_job_user.py and sdk-next/docs/server-side.md.

5.130

ACCESS MANAGER 5c: a field a restriction profile hides (hide) or makes unreadable (restrict_read) is hidden from EVERY vApp the member runs, through the bridge's one hidden-field walk (_orm_hidden_scope / _orm_hidden_of, now fed by the profiles too). A hidden field named in a read is left out with no error (D-a, Enrique 2026-10-14; restrict_read keeps Odoo's refusal); a domain, order, groupby, aggregate, having, read_progress_bar or watch hash on it is refused; fields_get / default_get / copy_data / onchange drop it; Vizum.meta.fields omits it and the new Vizum.meta.fieldAccess(model) says which fields are restricted; a feed serves its column as null; the ir.attachment rows holding a hidden binary field's bytes and the mail.tracking.value rows of a hidden field are kept out. Never hidden from apps: access_field_policy.bridge_exempt_fields. Feature access-bridge-field-visibility. See docs/superpowers/plans/2026-10-14-access-manager-bridge-field-visibility.md and sdk-next/docs/server-side.md.

5.129

DIRECT ESP32 DEVICES (the number is PROVISIONAL, fixed at merge in merge order): a device that cannot show a PIN is claimed at the Vizum store's broker and enrols on the instance with a one-time token. (1) Vizum.deviceBroker / V.device_broker (permissions.device_broker, privileged, administrators only, each mutating call confirmed by the person on the host): claim, rearm, unlink, list, rename, link — the instance uuid and token never leave the server, the enrolment token is kept only as its SHA-256; (2) POST /vizum/device/<slug>/_enrol (a route's enrol: {hook}, approved with the route): the device burns its token with one conditional UPDATE and receives a paired-device token minted as PIN pairing mints it; ONE uniform 401 for every refusal; (3) an app with auth "device" json routes and no page serves them (_pair/*, the device page, its worker, manifest and icon stay page-only). A broker device IS a vizum.app.device row of the app (same table, same revocation). An hourly cron cuts the credential of every device the broker reports revoked and delivers the queued confirm / unlink calls (an outbox, so an uninstalled app's unlink still goes out). The same device id is live on ONE app at a time. Features device-broker, device-enrol. See models/vizum_app_device_broker.py and sdk-next/docs/device-broker.md.

5.128

Vizum.schedule: AN APP'S TIMED REMINDERS FIRE AS NOTIFICATIONS WITH THE WINDOW CLOSED (the number is PROVISIONAL, fixed at merge in merge order; Enrique approved the design 2026-10-17 08:25). A schedule lives on the SERVER, per app and user (vizum.app.schedule): at (one ISO instant with its offset) or repeat (an RRULE subset, FREQ=DAILY|WEEKLY + BYDAY + BYHOUR + BYMINUTE, or {days, time}) with an IANA tz; the next fire is computed in UTC with zoneinfo, so a local time survives a DST change. A cron (every minute) turns each due row into a vizum.app.notification (inbox, click action {app, payload}, bus ping), then moves a repeat on or deactivates a one-shot. missed() returns the last 24 h of fired occurrences the app has not acknowledged (cap 20; ack acknowledges). Limits: 50 per app and user, payload 4 KB, set 120 per hour. Always the CURRENT user's. permissions.schedule (a boolean, not privileged) and min_platform 5.128. The administrator lists and clears rows in the backend; the body and payload are not readable through the ORM. Delivery: a Vizum Desktop tab open rings (toast, sound, browser notification when granted) also with the app's window closed; the browser fully closed rings nothing (Web Push and the Android APK are separate, later work). Feature schedule. See models/vizum_app_schedule.py and sdk-next/docs/schedule.md.

5.127

MEMBERSHIP EVENTS: AN APP IS TOLD WHEN USERS GAIN OR LOSE ITS OWN GROUPS (the number is PROVISIONAL, fixed at merge in merge order). native.membership: [{groups: ["@name"], method: "<own model>.<name>"}] with permissions.membership: true: the platform's own res.users / res.groups overrides (create, write, unlink; group commands, in_group_/sel_groups_/role, users / user_ids, implied_ids, archive, Vizum.team) compare the EFFECTIVE members (active, direct or implied) of the subscribed groups a write reaches (a mark in its transaction) with a ledger of what the app was last told, under the membership lock in READ COMMITTED after the commit, write ONE event per subscription (its method) and transaction (a gain and a loss cancel; the losses the writing transaction saw are reported too, so a loss then a re-grant elsewhere is lost then gained), and deliver it to the method, as the app's job identity, in queue order: {event_id, kind: delta, groups: {"@ref": {gained, lost}}, reason, actor_uid, attempt}, strictly per entry (a failed event holds the later ones). Only the app's own groups: an xmlid is refused; each "@group>method" pair is approved (permissions.membership_subs), so an update that adds one waits for the administrator. A deleted subscribed group reports its members lost (group_deleted). A failure never blocks the write: the row stays pending, retried with backoff, audited (platform:membership.refused), the administrators notified after 3 attempts. A reconcile ({kind: reconcile, members}) goes out at install/update and every hour. V.is_member("@ref", uid=None) answers membership from the current transaction. vizum.app._membership_flush() is the test helper (a commit's outbox and delivery, synchronously). A manifest with native.membership or code naming V.is_member declares min_platform 5.127. Feature native-membership. See models/vizum_app_membership.py and sdk-next/docs/native-membership.md.

5.126

NATIVE VIEW NODES, SCREEN ATTRIBUTES AND NEUTRALIZED SCREENS OF THE ACCESS MANAGER (the number is PROVISIONAL, fixed at merge in merge order). vizum.access.node rows hide a button, a notebook page, a search filter or group-by or the chatter, switch off Create / Edit / Delete / Duplicate / Import / Export of a view, or give one field read-only, required, invisible (true or a vetted condition), options and a cosmetic domain, for the members of a restriction profile; the read-only and required modes of the field rows show on screen too, and Create / Edit / Delete go where a model restriction refuses the operation for the member with no domain and no company scope. ONE mechanism: an override of ir.ui.view._postprocess_access_rights, which Odoo runs per user AFTER the view cache on a fresh parse of the cached arch (no platform views, no xpaths; one user's screen never reaches another's), cached per (uid, group set). Administrators and the superuser are never touched. SCREEN ONLY: the server enforcement stays with the operation guard, the field guard and no_read. The field mode hide is stored and applied but refused until the vApp bridge enforces it. NEUTRALIZATION: through the same hook, a member who cannot read a field (restrict_read) never receives a screen that names it. In the member's own copy of the arch a context name becomes False (default_price: standard_price arrives empty), a modifier that names it takes a fixed value (invisible and column_invisible 1, readonly 1, required 0, a decoration False), a domain leaf that names it becomes a constant leaf that selects no more than the leaf did, and the helper field node Odoo adds for the expression is removed. So restrict_read is no longer refused as no_read_dependents for those attributes (the cost on Odoo 19 and 20 with purchase installed), and the catalogue lists what the hook rewrites in neutralized and what still refuses in dependents (options, a group-by in a context, a view attribute that is a field name, a kanban expression). A computed many2one to a currency is no copy of what it depends on (stock_account's company_currency_id), so the cost group is offered with stock_account installed. Feature access-view-nodes. See models/vizum_access_node.py and models/access_neutralize.py. With the cost hidden, on Odoo 19 and 20 a member also creates, duplicates and varies a product (stock_account's create reads the cost: the create runs under the read-only cost lift of access_cost_lift) and opens the manufacturing overview (cost amounts at 0); the cost is offered on 17, 18 and 19 (20: tracked, E1).

5.125

A RECORD RULE COMPARES A USER'S GROUPS WITH ONE OF THE APP'S OWN GROUPS (the number is PROVISIONAL, fixed at merge in merge order). The leaf ["<path>.$groups", "in" | "not in", {"$group": "@name"}] reads «the user at the end of <path> holds this native group of the app»: e.g. a Representative reads only the cases of a technician who still holds the Distributor role. A vApp cannot override res.users / res.groups, so a domain is the only way a role taken away is taken away on every path. $groups is the LAST hop of a path that ends on res.users and compiles to all_group_ids (19/20) or groups_id (17/18, where Odoo writes the implied groups into the user's rows); {"$group": "@name"} compiles to vzm_group('<platform xmlid>'), which ir.rule's evaluation context resolves each time it computes the rule (models/ir_rule_group.py), and the whole domain falls to [(0, '=', 1)] when the group no longer exists. Membership is read in SQL at every search: a revocation is seen by the next search in every worker. Only in / not in; an xmlid, an id or the token anywhere else is refused at validation. Needs min_platform 5.125. Feature rule-domain-group. See models/rule_domain_group.py.

5.124

A WRITE TRIGGER WATCHES THE FIELDS IT NAMES (the number is PROVISIONAL, fixed at merge in merge order). native.script.hooks[].trigger.fields: ["state", ...] becomes the trigger fields of the app's base.automation: Odoo runs the hook only for a write that CHANGES the value of one of them, instead of for every write of the model. Odoo writes a stock move 13-21 times per operation; Location Restrictions' guards ran 28 times per move in a Validate for a change of state (20 CE, 2026-10-15). Absent = every write, as before; only with on write or create_or_write (a create still runs a create_or_write hook; a create or unlink trigger refuses fields); an unknown field refuses the install; an update applies the new list to the existing automation. Feature trigger-fields. See vapp_validation._valid_trigger_fields and vizum_app_schema._trigger_fields.

5.123

native.views[].target: WHICH FORM AN ENTRY EXTENDS (the number is PROVISIONAL, fixed at merge in merge order). A native.views entry went on Odoo's default view of its model and type (default_view: the primary view of lowest priority), which is not always the form people open: res.users resolves to base.view_users_simple_form (the new-user dialog), not Settings > Users (base.view_users_form). A form entry may now say "target": "main": the form the model's main window action opens (the first act_window a menu opens, else the first one; vizum_app_schema._main_form_id), when it is a primary form of the model. When no main form resolves the entry is skipped as no_base_view, which a strict entry refuses. "default" (or no key) is unchanged. The preview's native_views_warnings and the inspector's VIEW_NOT_MAIN_FORM stay silent for an entry with target "main". Needs min_platform 5.123 for "main". Feature native-view-target. See vizum_app_schema._native_view_base_id and vapp_validation._valid_native_view_target.

5.122

AN APP'S COLUMN DERIVED FROM THE COST JOINS THE COST FAMILY (the number is PROVISIONAL, fixed at merge in merge order). A column an app adds to an Odoo model (x_vzm_*, a native field with a formula or a related; a field of an app's own model too) whose depends reach a member of the cost family, directly or through a related or computed field in between (an Odoo field or another app's column), shows the cost like the sale line's margin: the Price List Manager's x_vzm_pricelists_margin is (list_price - standard_price) / list_price. Before this, the validator refused to restrict the cost while such a column existed (no_read_computed) and refused to restrict the column (app_column), so a customer with the app could not hide the cost. Now the column is hidden WITH the cost: the platform finds it in the registry (models/access_cost_columns.py, depends followed transitively; only an app's own manual columns, never a native field: those stay in the explicit table) and gives it, in the same pass that gives the members their groups, the negation of every profile that restricts a member it derives from, so Odoo refuses the member on read, search, group, export and the bridge answers an AccessError, fields_get and the views leave it out, and the app's other columns, rows and calls keep working. The admin never restricts it: it is not in requires_pair, the validator no longer counts it as a copy of the cost, and the catalogue row of every member lists the columns in also_hidden ({model, field, string, app_key, app_name}) while the column's own row says follows_cost_family. The stored value is still computed for everyone (computed as the superuser, measured on 17-20 with a purchase receipt that averages the cost and a sale line): no seam beyond the valuation ones. Feature access-cost-family-apps. See models/access_cost_columns.py, vizum_app_aliases.py (_vzm_apply_field_groups) and vizum_access_catalogue.py (_vzm_cost_joined_rows).

5.121

THE ORM GRANT CLOSES WHAT A SEARCH, A GROUP AND A SORT COULD STILL READ (the number is PROVISIONAL, fixed at merge in merge order). Three keys on a permissions.orm grant: ops may be EMPTY when group_ops carries every op (a placeholder op in ops is granted to every user, and Solo mints a native read ACL for the whole Solo group from any plain call:); create_fields, the field ceiling of a CREATE (and of a copy's defaults) apart from write_fields; and strict_paths, which holds every field reference — domain paths, read_group groupby and aggregates, order, having, name_search — to the fields the grant lists on each model of the path, so a search or a ranking over a column the app may not read stops being a bit-by-bit oracle. Only id is exempt. Also an exact per-app policy for platform models (PLATFORM_APP_OWN_GRANTS) that opens AboveCG's four vizum.* models to the AboveCG Panel and to no other app. A manifest that uses any of the three keys declares min_platform 5.121. Features orm-empty-ops, orm-create-fields, orm-strict-paths.

5.120

THE COST FAMILY: ONE GROUP TO RESTRICT TOGETHER (the number is PROVISIONAL, fixed at merge in merge order). Odoo shows a product's cost through more than standard_price: the sale line keeps it as purchase_price, margin and margin_percent (price - margin = cost), product_margin subtracts it (normal_cost, purchase_gap, expected_margin, expected_margin_rate), the valuation multiplies it by the quantity (value_svl, avg_cost, total_value, and on 19/20 stock.move value, remaining_value, value_manual), Odoo 20 adds project.project.estimated_cost, and the enterprise sale_account_accountant aliases it (unit_cost, total_cost). No depends links most of them to standard_price, so the copy rules of 5.113/5.114 never saw them. The table models/access_cost_family.py lists them with the Odoo source line that proves each; a member is found by presence in the registry, never by version. The validator refuses restrict_read of one member while another stays readable (no_read_cost_family, listing the missing ones), and the catalogue lists the others in requires_pair with via: "cost_family" (a tolerant reader treats any UNKNOWN via as restrict together). Editable seeds (event ticket price, purchase price_unit) and the stock-manager-only valuation layers of 17/18 and landed-cost lines are not members. The manufacturing overview report returns a restricted member its data with the cost amounts at 0 (17, 18; 19 and 20: see 5.126); a restricted cashier opens a POS session (17: the loader drops the cost field) and validates an order (the line cost is stored as the superuser, every line). Feature access-cost-family. See models/vizum_access_catalogue.py (_vzm_cost_family) and vapp_validation.py (no_read_cost_family).

5.119

ONE META CONSENT, TWO RELATED PROVIDERS. Vizum.oauth.connect("facebook", {shared:true, related:["instagram"]}) carries the related provider only inside the signed OAuth state and, after the Facebook Page expansion, materialises each linked Instagram Business account under the existing instagram provider. Both providers must be declared and configured; arbitrary provider pairing is refused. Facebook and Instagram must use the same Meta app ID (client_id): a related consent across two Meta apps is refused at connect. The consent requests the union of both providers' configured scopes (comma- or space-separated, each once). When Facebook connects but no Instagram Business account does, the callback page reports the failure ("Meta authorized Facebook, but returned no linked Instagram Business account") instead of "Connected" and connect() rejects naming Instagram; the Facebook connections are kept. Feature oauth-related-meta.

5.118

UP TO 24 NATIVE GROUPS, AND A HEADING PER GROUP (the number is PROVISIONAL, fixed at merge in merge order). native.groups holds up to 24 groups (8 before: the cap guarded only size, one res.groups row and one xmlid per group); a large field-service vApp declares 15. A group may name its heading in Settings > Users with privilege: "<label>": on Odoo 19 a res.groups.privilege is ONE selection on the user form, so independent roles under the app's single heading could not be held together. Each label becomes a res.groups.privilege «<app name>: <label>» shared by the groups that name it; groups without it keep the app's heading (made only when one needs it). Odoo 17/18 have no privilege and show groups that are not a chain as checkboxes: the key changes nothing there. Two groups of one app with the same label are refused (Odoo 17/18 refused them at install, one category). A vApp with more than 8 groups or a privilege sets min_platform 5.118. Feature native-groups-24. See vapp_validation._valid_native_groups and vizum_app_schema._group_headings.

5.117

THE VALUATION SEAMS CHECK THE PRODUCT AND FORGET THE COST (the number is PROVISIONAL, fixed at merge in merge order). Feature access-valuation-seams-guarded (it completes access-valuation-seams, 5.115). After a seam elevates (the landed-cost leaf, the scope markers compute_landed_cost / button_validate, the landed-cost line onchange) the restricted fields of the products it touched are dropped from the transaction cache, so a member's later read of standard_price in the same request is judged by his own check on Odoo 17 and 18. The landed-cost line onchange does not elevate a virtual line whose product the member may not read, and computing or validating a landed cost with a product the member may not read (a record rule, another company) is refused with an AccessError before anything is computed or written. See models/access_valuation_seams.py.

5.116

VIZUM.TEAM MULTI-ROLE WITH AN AUDIT TRAIL (the number is PROVISIONAL, fixed at merge in merge order). team.save({roles: [...]}) gives a member the FULL set of declared roles (the legacy role: "x" is roles: ["x"], replace semantics); whoami() and members() keep role, the primary role (unchanged rule), and add roles (every held role, manifest order); members({has_role}). Nobody changes their own roles. A role marked grant: "admin" in native.team.roles is given or taken by a settings administrator only, and an account holding one is managed by a settings administrator only. For an account with any group outside the app a manager's save writes only the role groups; its password, login, email, name, phone, active flag and invitation are a settings administrator's. Every change writes one platform:team.* row in vizum.app.audit (actor, target, roles before and after, never a password); a refused write writes platform:team.refused on its own cursor. Managers read the rows with team.history(); in Vizum.audit.search a member who is not a manager sees only the team rows about themselves. Feature team-multi-role. See models/vizum_app_team.py.

5.115

STOCK VALUATION KEEPS WORKING FOR A MEMBER WHO MAY NOT READ THE COST (the number is PROVISIONAL, fixed at merge in merge order). A member of a profile that made standard_price (or a field the valuation reads) unreadable (restrict_read) could not validate a delivery or mark an MO as done on Odoo 18 and 19, validate a landed cost on 19 and 20, or mark a standard-cost MO as done on 20: Odoo's valuation reads the cost AS THE MEMBER. Now, for THAT member only, the valuation computation (_prepare_out_svl_vals, _get_in_svl_vals, _get_price_unit, _set_value, _get_value_from_std_price, _cal_price) runs as the superuser: the value is computed and written, never returned to the member. The landed-cost line no longer shows the member the product's cost (Odoo 17 leaked it, 18 to 20 refused the member): its price is 0 and the member types it. A user who is not a member, the administrator, a cron and any call already run as the superuser get Odoo's own code. The platform depends on none of stock_account, mrp_account or stock_landed_costs: each method is wrapped on the registry class when the model and the method exist. Feature access-valuation-seams. See models/access_valuation_seams.py.

5.114

THE CATALOGUE OFFERS restrict_read WITH ITS PAIR (the number is PROVISIONAL, fixed at merge in merge order). api_access_view_nodes has no profile, so the copies #3960 judges together (product.template. standard_price from product.product.standard_price, image_512 from image_1920) were refused for restrict_read and left out of ok_modes: the Access Manager could not offer «Not readable» for a cost at all. A field whose ONLY obstacle is the pair rule now answers requires_pair: [{model, field, via}] (the closure of its copies and sources, the validator's own) and ok_with_pair_modes: ["restrict_read"]; a pair with a member refused for another reason stays refused, with that member's code and blocked_by. The row path does not change; TEMPORARY no_read_sibling_tracked refuses the four res.partner address fields one compute produces while one is tracked (Odoo 20). Feature access-catalogue-requires-pair. See models/vizum_access_catalogue.py (_vzm_pair_edges, _vzm_pair_group, _vzm_apply_pair).

5.113

NATIVE FIELD no_read OF THE ACCESS MANAGER: NOT READABLE AT ALL (the number is PROVISIONAL, fixed at merge in merge order). A vizum.access.field row with restrict_read appends the profile's group, negated, to the groups Odoo gave the field (a second source of field groups next to the app columns of 5.107, applied by the SAME pass and restored in place when the row goes), so Odoo itself refuses the member on read, search, order, group, export and write, hides the field from fields_get and the views, and refuses the member's create and default_<f>. Administrators and the superuser are never restricted. The refusal is an AccessError on Odoo 18, 19 and 20 also for a member in developer mode (Odoo's error builder crashed on a negated group). The validator refuses the fields Odoo's invoicing and reports read (E2), a field tracked on Odoo 20 (E1), a field another part of a screen names (M9) and an app's own column (Q6). Feature access-field-no-read. See models/vizum_access_no_read.py and vizum_app_aliases.py (_FIELD_RESTRICT, _vzm_apply_field_groups).

5.112

NATIVE FIELD RESTRICTIONS OF THE ACCESS MANAGER: READ-ONLY, REQUIRED, NOT EXPORTABLE (the number is PROVISIONAL, fixed at merge in merge order). vizum.access.field rows (profile, model, field and the booleans restrict_write / restrict_empty / restrict_export) are a second policy source of the operation guard. A read-only field refuses the value the MEMBER'S OWN request sets (create, write, web_save, web_save_multi, import through load, a binary attachment with res_field, the website form, the chatter post and message edit, the composer, and a vApp bridge call made for the member); the writes Odoo makes while it carries out an action the member may do pass. Required refuses a record the member creates without a value and a write that empties it. Not exportable refuses export_data at any level of a path and filters /web/export/get_fields. Feature access-field-restrictions. See models/vizum_access_field.py, vizum_access_field_guard.py and vizum_access_payload.py.

5.111

THE NATIVE VIEW-NODE CATALOGUE OF THE ACCESS MANAGER. vizum.app.api_access_view_nodes(model, view_types) through call: answers, for one Odoo model, the buttons (and whether a blocked operation can refuse them), notebook pages, search filters and group-bys, the chatter and the fields of the COMBINED arch of its primary views, computed as an administrator, and every field's facts with the validator's verdict per field restriction mode (access_field_policy) and the nodes that name the field in a modifier (dependents). Metadata only: no record, arch text, domain or group xmlid. Reserved to the Vizum-signed Access Manager (com.vizumapps.hide_menu, _vizum_verified), an administrator only. Feature access-node-catalogue. See models/vizum_access_catalogue.py.

5.110

WHAT THE SERVER KNOWS ABOUT AN OFFLINE REPLAY (merge order: 5.110). V.offline_replay(): None for a live call; for a call the platform accepted as an offline replay of this user's queued op, {queued, received_at, first_seen_at, attempts, queued_version}, the times on the SERVER's clock (vizum.app.offline.seen, written in its own cursor, purged with the offline ledger). It does NOT prove the device was offline. Travels as an OfflineReplayFacts in the context; a client-sent value is stripped at every entry (models/offline_facts.py). Feature offline-replay-facts.

5.109

ONE IDEMPOTENCY KEY ACROSS AN ONLINE CALL AND ITS DECLARED ACTION (merge order: 5.109). An app with min_platform 5.109 that sends an idempotency key on an online call: gets it ledgered (exactly once), and the ledger answers the same key across the online call: and the declared action whose target is that method (POD: a proof sent online whose answer was lost, re-sent through the offline queue). The match is the method fingerprint (idem_method: model, method, sorted ids, arguments bound to their names); before answering, the calling path runs every check that does not depend on doing it again (grant, approval, consent, domain, READ on the records). Feature idempotency-across-paths.

5.108

BLOCKED OPERATIONS AND THE DEVELOPER-MODE GATE (the number is PROVISIONAL, fixed at merge in merge order; 5.107 native field audience). vizum.access.operation (one row per blocked operation of a restriction profile: copy, import, export, message, note, activity, button, report, server_action, action, view_type) and vizum.access.profile.no_debug. The platform wraps only the declared (model, method) pairs when the registry is ready (_register_hook), refuses the member's DIRECT call with AccessError and lets what Odoo does by itself pass; administrators, the superuser and sudo() are never judged. no_debug clears the session's developer mode for the members (?debug=1|assets|tests). One validator (vapp_validation.access_operation_error, contract access_operation_policy). Admin-only ACL; Hide Menu administers it (grant in PLATFORM_APP_GRANTS). Feature restriction-operations. See models/vizum_access_operation.py and vizum_access_op_guard.py.

5.107

WHAT AN APP ADDS TO ODOO'S MODELS AND VIEWS IS FOR THE APP'S PEOPLE (the number is PROVISIONAL, fixed at merge in merge order; 5.105 read calls, 5.106 restriction profiles). A column an app adds to an Odoo model (native.fields) and every node it injects into an Odoo view (native.views placements and pages, the inserted nodes of an inherited native.ui view) used to be shown to every user: ABC-XYZ's classes in the product.template list, search panel and form, and through read, search and export. Now the field carries the app's audience as its groups (its native.groups, the people and groups an administrator granted the app on the Desktop, in Solo and in the native menu, and the settings administrators), Odoo enforces it everywhere, and the injected nodes carry the same groups. Opt-outs: "visibility": "all" on a field (everyone, as before) or on an inherited native.ui view (its inserted nodes stay everyone's); explicit groups keep exactly those (VZ-SEC-23); an app that replaces an Odoo module (native.replaces) defaults to "all", as the module did (RULE V). Duplicating a record keeps working for a user outside the audience. Changing who may use the app re-tags its views and rebuilds the registry; the upgrade to 19.0.10.150.274 applies it to the apps already installed (one savepoint each, an audit row, a retry at the next start). Feature native-field-audience. See models/vizum_app_native_audience.py.

5.106

RESTRICTION PROFILES AND MODEL RESTRICTIONS (the number is PROVISIONAL, fixed at merge in merge order). vizum.access.profile (who is restricted: users, and the members of groups) and vizum.access.restriction (what they may not do: read / edit / create / delete a model, except records matching a domain, only in some companies). The platform owns one res.groups per profile, kept equal to its targets minus administrators and the superuser, and compiles each restriction into a GLOBAL ir.rule (≤ 19) / a group-less ir.access restriction (20): AND-ed, so it only ever narrows, and it holds over RPC, export and import, not only the web client. One validator (vapp_validation.access_restriction_error, contract access_restriction_policy): never a deny-listed model, vizum.*, ir.* (except ir.filters: create / write / unlink, never read), res.users / res.groups / res.company. Admin-only ACL; Hide Menu is the app that administers it (grant in PLATFORM_APP_GRANTS); uninstalling the app removes its profiles, rules, accesses and groups. Feature restriction-profiles. See models/vizum_access_profile.py.

5.105

READ CALLS RUN READ-ONLY, WITHOUT THE «App action» DIALOG (numbered in merge order; 5.104 is guest links). permissions.orm[].read_calls names the call: methods of a grant that only read — on a vApp native model (x_vzm_*) only, and only an app-defined method (native.methods, not an override nor an inherited Odoo method) is run as one; a name an update adds is a widening (approval). The platform runs a declared read call in a read-only window of the request's transaction (models/read_call.py: SAVEPOINT + SET LOCAL transaction_read_only, the same PostgreSQL switch Odoo 18+'s read-only cursor uses, identical on 17–20), with exactly today's user, grant and sandbox; one that writes, queues a post-commit callback, writes the filestore, sends SMTP (models/read_call_guards.py) or reaches V.net/oauth/ai/vector/ webhooks/identity/commit is refused with READ_CALL_WROTE and audited (platform:read_call_wrote). api_list sends the approved read calls (read_calls) and the desktop does not show the «App action» dialog for them. Needs min_platform 5.105. Feature read-calls.

5.104

GUEST LINKS: auth: "link" routes (numbered in merge order; 5.103 is advisory_lock). An account-less customer opens a link the APP issued from its server code (V.links.issue/reissue/revoke/extend/close/status/list/ledger): a 256-bit token shown once and kept as its SHA-256 only, carried in the URL fragment (/app/<slug>/<page>#token, never in a log or a Referer), exchanged once for an HttpOnly SameSite=Strict guest session scoped to /vizum/link/<slug>/. Expiry 1 h - 90 days (default 30), a grace of up to 30 days the app applies when its job closes, instant revocation, re-issue revokes the old token. Link routes are page, json (64 KB body), file (a declared binary field, signed 10-minute URLs) and upload (a new kind: one declared binary field, link.max_mb <= 25, link.accept image/pdf decided by the bytes, never markup); hooks run as the app's job user with V.link {id, ref, scope, contact_hint, expires_at, verified, route}, never the token. Limits per link (60 calls, 10 uploads a minute), per source (30 failed resolutions per 10 minutes, IPv6 by /64), per app; an optional one-time code (link.verify: "code", V.links.issue_code inside the hook, 6 digits, 10 minutes, 5 attempts); a per-route kill switch and the platform link ledger for administrators (api_guest_links, Vizum Apps Admin > Guest links). Issuing is open to Vizum's own verified apps; any other app needs vizum_apps.guest_links_policy = all or its key in vizum_apps.guest_links_apps. permissions.link_routes is a privileged grant of its own. Browser: Vizum.link.info/call/fileUrl/download/upload/verify on the link page only. Feature link-routes. See models/vizum_app_link.py and sdk-next/docs/link-routes.md.

5.103

A vAPP METHOD SERIALISES ON ITS OWN KEY (capabilities are numbered in merge order). advisory_lock(key, timeout_ms=None) in native.methods and their library is a module's cr.execute("SELECT pg_advisory_xact_lock(...)") (psi_dsd: one sale per user and client reference): a transaction-scoped PostgreSQL advisory lock in the two-int form (-app id, first 4 bytes of sha256(key)) — negative and one per app, so it never meets another app's lock, the platform's (positive namespaces, or the bigint form) or Odoo's (19 ai: positive record ids). Bounded wait: SET LOCAL lock_timeout (default 5000 ms, 0 = do not wait, at most 30000), restored after; a timeout raises LockTimeout (LOCK_TIMEOUT, retryable; the transaction stays usable — the wait runs in a savepoint). Under Odoo's REPEATABLE READ a lock that only waits leaves the waiter on its old snapshot, so the call also touches one row per (app, key) in vizum_app_xact_lock: if the previous holder committed after this transaction's snapshot that write fails to serialize and Odoo replays the request on a fresh one. key: a non-empty str of at most 256 characters. Rows are dropped after a day by the daily autovacuum. A vApp whose methods call it sets min_platform 5.103 (install gate and vzm check). Feature advisory-lock. See models/vapp_xact_lock.py.

5.102

A DECLARED ACTION IS TOLD WHAT ITS METHOD RETURNED (the number is PROVISIONAL, fixed at merge in merge order; 5.101 is native.access). Vizum.actions.run (and a backend task, which runs the same _action_exec) answered {ok, result: true} for anything json.dumps refused: the wizard stock_sms opens on a validate, the return wizard of stock.picking.action_return on Odoo 20, a recordset, a datetime. For an app that declares min_platform 5.102 or later, result takes the 5.98 call: shapes (models/call_result.py, _orm_typed_result): an action dict is {type: "action", action_type, name, res_model, res_id, view_mode, target, context?}, a top-level recordset is {type: "records", model, count, ids} (ids and res_id only inside the app's own read grant), dates and decimals are normalised like a call:, and what is not plain data is refused with ACTION_RESULT_UNSERIALIZABLE (the run is rolled back and audited as failed). null keeps answering true. Apps below 5.102 keep today's result byte for byte. Feature actions-typed-result.

5.101

native.access (the number is PROVISIONAL, fixed at merge in merge order): one of the app's own groups on an Odoo model the app does not own, what a module's ir.model.access row on a shared model does (psi_dsd: read on account.move for its driver group). [{model, group, ops, reason?}]: the group is "@name" only, ops ⊆ read/write/create/unlink, within the app's plain orm grant on the model and each narrowed by a native.rules entry of that same group, a reason for write/create/unlink, never a model of NATIVE_ACCESS_POLICY's deny lists. ≤ 19: an ir.model.access row per entry, narrowed by those rules; Odoo 20: ir.access permissions carrying their domains, never a domain-less one (it would be the whole model, OR-ed with the user's other groups). Folded into native_acl: a new or wider grant re-approves the update, and the preflight lists the grants (permissions.detail.native_access). Feature native-access. See models/vizum_app_native_access.py.

5.100

VIEW INSPECTION FOR THE IDE AND Vizum.ui.openView (C-IDE-2; the number is PROVISIONAL, fixed at merge in merge order). api_view_inspect(source, views, opts) through call: on vizum.app (same gate and keys as 5.99: an administrator's store-verified Vapp Creator or Module Converter) answers, for every native view a package touches (installed app or a package not installed yet), the combined arch without and with the app, each spec's change, where each field lands (placed / skipped / invalid / pending), the other inheriting views and their conflicts, the primary siblings recombined and the findings (VIEW_*), each with its manifest path. The app's specs come from the installer's own functions and enter Odoo's own _combine as in-memory ir.ui.view records: nothing is written (an installed app's _check_xml runs in a savepoint that is always rolled back). api_update_preflight gains views_broken (a native.ui view that would abort the install). Vizum.ui.openView({model, view_type, view_xmlid?, res_id?, label?}) opens a real Odoo view (grant permissions.ui "openView"); an xmlid resolves through the HOST-ONLY api_view_ref (a primary, active view of that model and type the user's groups allow). Solo degrades form/list to its overlays and refuses the other types. Features view-inspect, ui-open-view. See models/vizum_app_view_inspect.py.

5.99

ODOO INTROSPECTION FOR THE CREATOR IDE (C-IDE-1). An administrator's Vapp Creator or Module Converter asks the instance what its Odoo has, through call: on vizum.app: api_odoo_introspect(op, models, parts, opts) with op "signature" (registry + installed modules, edition, Enterprise licensed or not), "index" (every model), "models" (1-50: fields as the user sees them, methods with signature, decorators, defining modules and origin ce/ee/custom/ third_party, the bridge's verdict per method — @api.private refused like Odoo's RPC, VZ-SEC-35 — and the model ACL; 2 MB and a time budget, the rest named in truncated) and "source" (1-20 methods of one model, every definition, Enterprise marked OEEL-1, credential-looking literals redacted). Code only: never a record, a default value, ir.default or a configuration parameter; BROKER_DENY_MODELS by name, vizum.* by name and access. Reserved (first-party, store-verified) to com.vizumapps.vappcreator and com.vizumapps.moduleconverter, which also get call:api_update_preflight. And api_build takes an 8th positional preview_sourcemap: a preview build (install false) hands back its source map, never inside the package. Features odoo-introspect, preview-sourcemap. See models/vizum_app_introspect.py.

5.98

A call: THAT OPENS A WIZARD IS TOLD SO (stock_sms's confirm.stock.sms; any method that returns an ir.actions.* dict). For an app that declares min_platform 5.98 or later: an action dict comes back as {type: "action", action_type, name, res_model, res_id, view_mode, target, context?} (plain scalars only; domain and views are never copied, context only as lang and tz; ids and res_id only for records the app may read), a top-level recordset as {type: "records", model, count, ids}, and a result that is not plain data (a nested recordset, an object, a lazy value, over the size caps) is refused with ACTION_RESULT_UNSERIALIZABLE instead of answered as true. Older apps keep true / the ids list. Feature typed-action-result. See models/call_result.py.

5.97

POLICY RECONCILIATION OF INSTALLED APPS (hardening program B1, models/vizum_app_policy.py). A rule the platform tightens used to judge only the next package. Now the install validator, the permission classification, the ORM clamp and the package trust check judge every installed app again when their code or the trust policy changes, and once a day (resumable, batched, one commit per batch, 60 s per cron run). Outcomes per kind (decisions B1-B4, 2026-10-07): report; reapprove (a permission now privileged: the app keeps running, red, until an administrator approves or disables it); hold ONE unsafe view / route / hook; needs_approval only when an administrator runs the pass; disable only for trust. A pass that would act on more than 5 apps or 20 % of the running ones stops and asks. Every decision leaves a policy:* audit row, the Apps Manager shows a policy health check and a "Re-check apps" button, and an approval is audited (policy:approved). The store re-judges the versions it serves when its gates change and revokes only on an administrator's act for a HIGH finding. Feature policy-reconcile.

5.96

THE SERVER'S OWN METRICS FOR AN ADMINISTRATOR'S APP (Enrique 2026-10-08: «lo que un módulo admin puede leer, un vApp también»). New namespace Vizum.server: info() answers the hosting (docker, podman, odoo.sh, systemd, bare), the scope of the numbers (container, process, or host only behind an administrator's switch that is refused on a shared host), prefork or threaded, the nodes, the workers configuration, the retention and, per metric family (cpu, memory, iops, workers, storage, http, db), true or {ok: false, reason}; metrics({from, to, step, node?, series?}) answers one point per step (60, 300, 900, 3600, 21600 or 86400 s, at most 1,500 points, Unix seconds) of CPU, memory, workers, Odoo's own disk I/O, HTTP rate / mean / p95 / max / concurrency / errors and this database's connections, commits, reads and cache hits, null where there is no data (never 0), the latest disk, filestore and database sizes, and top_apps (the ten apps with the most bridge requests in the range, with their mean duration). Every HTTP request is timed into per-process minute buckets (status class and route kind only: no URL, user or IP) that a per-process thread writes once a minute; one-minute data is kept 48 hours, hourly roll-ups 30 days. Collected only while a ready app holds the approved permissions.server_metrics (a privileged boolean: install_scope "admin" and min_platform 5.96); both methods are base.group_system only. Feature server-metrics.

5.95

DETERMINISTIC OFFLINE VERSIONING (Master Program Batch 4, plan §8). A device offline on app v1 queues creates and writes; the server moves to v2 (or a native module migrates); the device reconnects. Every queued create/write is stamped with the app version and the type of each field it sets (context.vizum_offline.version / .types, the types api_offline("config") now lists per write entry next to app_version). The replay re-checks the op against the server as it is NOW: valid under v2 -> applied; a removed model, a removed or renamed field, a field whose type changed, a removed action -> OfflineStale; offline writes, grant, field ceiling or the user's rights narrowed -> OfflineNarrowed (an AccessError). Both answer OFFLINE_STALE with details.reason (model_removed, field_removed, field_type_changed, action_removed, unstamped, permission_narrowed), never applied with the old meaning and never retried; the host lists them in Sync issues with the values the user entered (discard / keep for export). Each dataset carries sig (its definition: fields and types, domain, order, limit, grant): the device drops a copy whose sig changed and refetches, and the sync token is bound to the field types too. The host learns the installed version on every declaration refresh and a page still running another one gets offline:app_updated {running, installed} and a reload offer. An op without the stamp (version, and types for each field it sets) is refused unstamped before anything runs; ops queued before the upgrade (no version) keep syncing until their app is updated or a field they set changes type (compared with a snapshot taken once). Feature offline-versioned. Offline files and encryption at rest stay GATED (Batch 0 A9).

5.94

SEVERAL PAGES OF ONE APP ON A NATIVE FORM (contador365 puts 36 hr.employee fields on it, and one tab of 30 is not enough). A native.views form entry may carry pages: [{name, label, fields, after_page?, groups?}, ...] (page stays valid as a one-item alias, never both in one entry): at most 4 pages per app per form, 30 fields each and 120 in all, names unique, a field on exactly one page or placed. after_page may also name an EARLIER page of the same entry. All the pages go in the SAME inherited view per (model, type), so uninstall drops them all and an update that renames, removes, adds or reorders pages rebuilds one view. Every 5.91 guarantee holds per page: lxml-built arch, plain-text catalogue-translated labels, a page restricted to a missing group is skipped ALONE (never shown unrestricted), and a form with no notebook gets every page's fields after the main group's last field, in page order. native_views_skipped and strict report and refuse per page (kind "page", field = the page name). Needs min_platform 5.94 (an older platform ignores pages and would show nothing). Feature native-view-pages.

5.93

A NATIVE VIEW PLACEMENT THAT CANNOT BE MADE IS REPORTED, OR REFUSED (Enrique 2026-10-07: «sin estricto, un ancla que falta se salta en silencio»). api_install and api_update_preflight return a NEW key, native_views_skipped: the native.views placements skipped on this database, one {model, view, kind: "place"|"page", field, anchor, position, reason, strict} each, with reason anchor_missing (the form has no such field), anchor_in_subview (only inside an x2many's inline sub-view, which the 5.91 predicate does not count), no_base_view, page_group_missing, page_form_unreadable or page_no_place. Every old key is unchanged; the same list is kept on the installed app (api_installed_detail returns it to administrators only; anyone else gets []). A manifest has ONE native.views entry per (model, type), a second is refused. A native.views entry may carry "strict": true: a placement of that entry that would be skipped refuses the install or update BEFORE anything is written, with an error naming model / view type / field / anchor, and a failed strict update leaves the previous version installed and intact (api_update_preflight lists it in blocking). A page that falls back to the main group of a form with no notebook is not a skip. Default (no key) = skip as before. An app that uses strict sets min_platform 5.93 (an older platform ignores the key and would skip silently).

5.92

A SEARCH THAT ASKS FOR MORE THAN 5,000 RECORDS IS REFUSED, NOT CUT (Batch 22 phase 2 PR 3). Until now an explicit limit above 5,000 on search / search_read was cut to 5,000 without a word: the rows past it were just missing (about 60 calls in 16 shipped apps; those apps now page, Batch 22 PR 3a-c). For an app whose manifest declares min_platform 5.92 or later the bridge raises QUOTA_EXCEEDED with the page size and how to page, and details {kind: "limit_too_large", asked, page: 5000} (the host passes a server QuotaExceeded's details to the app). An app that declares less keeps the old cut, so nothing shipped breaks. vzm check warns about a literal limit above 5,000 (an error from 5.92). Feature search-limit-error. Hardening B8 (2026-10-10), same rule on every path that searches: call:name_search with a limit above 5,000 and the device's offline copy (api_offline("config") .search_limit_error) refuse it too for a 5.92 app; read / read_group keep the value ceiling (resource-governance, no details.kind).

5.91

A NATIVE FORM PAGE OF THE APP'S OWN (Enrique 2026-10-07: fields xpath-ed next to an anchor "don't always look right and break the clean view"). A form entry of native.views may carry page: {name, label, fields, after_page?, groups?}: the listed native.fields of that model go on the app's own tab of the form's notebook (<page name="vzm_<slug>_<name>">, after the page named by after_page when the form has it, else last), restricted to one of the app's groups with groups "@name". The label is plain text (no braces, angle brackets, "t-" or line breaks) and a msgid of the app's catalogue (5.84). At most one page per form; a field is on the page or placed, not both. The page lives in the entry's one inherited view, so uninstall drops it and an update that renames, removes or moves it leaves one view and one page. A form without a notebook gets the fields after the last field of its main group (fail-soft). The arch is built with lxml and vetted like an inherited native.ui view. An app that declares a page sets min_platform 5.91 (an older platform ignores the key and the fields stay off the form); the install gate refuses a page below 5.91, as vzm check does (hardening B8).

5.90

HEAVY WORK GOES TO A QUEUED, CHUNKED BACKGROUND JOB, AND OVER-BUDGET EVENTS ARE TOLD (Batch 22 phase 2 PR 2, Enrique 2026-10-07). Vizum.bulk.export(model, {domain, fields, format, name}) writes the rows to one of the app's files (CSV or JSON lines); Vizum.bulk.rebuild(model, {domain, fields, hook, params}) hands them a chunk at a time to the app's own server hook (logic "script"); status, list and cancel. Jobs run on the CRON worker as the user who asked, through the app's grant (api_orm), in keyset chunks of a quarter of the bridge ceiling, one commit a chunk: ONE job at a time per instance (advisory lock), first come first served, at most 3 waiting per app and 10 per instance (RATE_LIMITED beyond), resumable after a restart. When a bridge read or read_group is refused for its size, or a job fails: a desktop toast to the user (once per app and model an hour), ONE Odoo activity for the administrators per app and kind (at most hourly) on a vizum.app.rgov.event row that counts them, an e-mail only on the administrators' opt-in, and an aggregated daily telemetry count (rgov.*). Settings › Vizum › Resources shows the measured classification and sets the ceiling, the feed concurrency and the e-mail opt-in. Feature bulk-jobs. An app that uses Vizum.bulk sets min_platform 5.90 (models/vizum_app_rgov.py).

5.89

GOVERNED DATA FEEDS AND RESOURCE GOVERNANCE (Batch 22 phase 2, Enrique 2026-10-07). A BI client that refreshes OUTSIDE the vApp (Power BI's service, with its own credential) pages a dataset through GET /vizum/feed/<app>/<feed> instead of Odoo's native /jsonrpc: a per-feed key (shown once, stored as SHA-256, revocable, never the user's password or an API key) opens ONE model, the declared columns and a domain, read as the administrator who issued the key through the app's own ORM grant (record rules apply). Pages are keyset, sized to a quarter of the bridge ceiling (a non-stored computed column counts 4), cut short at a time budget below limit_time_real, streamed a chunk at a time, and at most feed_concurrency pages run at once (1 on odoo.sh/small instances, 2 otherwise): the rest get 429 + Retry-After, first come first served. Vizum.feeds.list/define/rotateKey/revoke/remove behind the new privileged boolean grant permissions.feeds (administrators only; define and rotateKey are confirmed on the host). Features data-feed and resource-governance (the 5.88 ceilings, discoverable). An app that uses Vizum.feeds sets min_platform 5.89 (models/vizum_app_feed.py).

5.88

RECEIPTS PRINT A LOGO, AND APPS CAN ASK FOR A TEST PRINT. A receipt document (5.87) gets an image line: {image: "data:image/png|jpeg;base64,...", align, width, dither, threshold}. The source is a data: URL (at most 96 KB, 4 million pixels; no remote URL, the device page fetches nothing), decoded by the browser on the device page, scaled to the PAIRED PRINTER's dot width (a person picks 58 mm = 384 dots or 80 mm = 576 dots, the default, in the setup panel), reduced to 1 bit (Floyd-Steinberg dither, or a threshold) and sent as ESC/POS GS v 0 raster in bands. At most 2 images a receipt, 800 dots tall each, 64 KB of raster; more is VALIDATION_FAILED, never a hang. The platform's encoder is ESC/POS only (no CPCL), so there is no CPCL graphics path to support. Vizum.device.printTest() prints the platform's fixed test receipt (logo, printer name, paper width, time, a ruler as wide as the paper) with the same device.print grant, rate limit and errors; the setup window's "Test print" is that call. Features device-receipt-image and device-receipt-test. An app that uses either sets min_platform 5.88.

5.87

DEVICE PAGES PRINT RECEIPTS, AND print() IS SUPPORTED. A paired-device page whose route declares device: {"print": true} (a widening: approved with the route, shown on the approval card) gets Vizum.device.printReceipt(doc, opts): the app sends a STRUCTURED document (lines with align/bold/size, QR, barcode, divider, feed, cut — never bytes) and the HOST PAGE builds the ESC/POS stream with the platform's own encoder (vizum_window_manager core/escpos.js, one encoder for every host) and writes it to a printer a person paired AT the device, once, from the page's own setup panel (WebUSB, or Web Serial for a Bluetooth/COM printer; a user gesture is what the browser requires, and the app frame's allow still excludes usb and serial). Bounded (200 lines, 120 characters a line, QR 300 bytes, 32 KB), at most 12 receipts a minute a device. An unpaired printer rejects PRINTER_NOT_PAIRED (the app falls back to print()), a printer that does not take the data PRINTER_UNAVAILABLE (both new error codes, category dependency). Vizum.device.print() is the supported window.print() of a device page: the same grant and rate limit, then the app prints its own view (Chrome started with --kiosk-printing prints it with no dialog; sdk-next/docs/device-routes.md). Features device-receipt and device-print. An app that uses either sets min_platform 5.87 (the install gate and vzm check read device.print).

5.86

OFFLINE: A RECORD DELETED ON THE SERVER IS ITS OWN KIND OF ISSUE. A queued write (or action) on a record that no longer exists answers CONFLICT with details.deleted; the device lists it as reason: "deleted" (with canRecreate) instead of a generic rejection, removes the local row (no ghost), and the user either discards the change or recreates the record (keep_mine: ONE create from what they saw, offered when the app may create the model offline). Vizum.supports("offline-deleted"). Also hardened in the same release, no contract change: a replay runs in the company it was queued under (a company the user lost is a clear refusal), an app waiting for approval holds the queue instead of rejecting it, a write naming a field that left the model is refused before anything is written, relation commands compare against the base correctly, and every replay outcome leaves a platform audit row. An app that handles reason: "deleted" sets min_platform 5.86. sdk-next/docs/offline-data.md.

5.85

A vApp CAN TAKE ITS WINDOW FULL SCREEN. Vizum.ui.fullscreen() / exitFullscreen() (grant "fullscreen" in permissions.ui; exitFullscreen is always allowed) on the desktop and the native Odoo host: the window is painted over the viewport with the dock, the Odoo navbar and the titlebar hidden (a render mode: the window's saved geometry is never touched), and the browser is asked for real fullscreen too, best effort - the click happened inside the sandboxed iframe and only some browsers hand that activation to the host document, so the kiosk layer never needs a gesture. A host Exit button, Escape and the browser's own exit end it (Vizum.ui.onFullscreenChange). Vizum.supports("ui-fullscreen"); Solo and device pages answer {active:false, supported:false} (device pages keep Vizum.device.fullscreen). An app that calls it sets min_platform 5.85 (vzm check). sdk-next/docs/ui-fullscreen.md.

5.84

NATIVE STRINGS FROM THE CATALOGUE. The i18n/<lang>.json an app already ships (5.73, 5.77) now also translates what the app puts in Odoo's own backend: field labels and help, selection options, model labels, groups, menus, window/server actions, view and report arch terms, the translatable values of native.records, a binding's label and a public page's website-menu entry. A key is the plain English text (an existing catalogue works at once) or an optional context key "@native:<ref>" (model, model.field, model.field#help, model.field=value, @group, <record id>.<field>, app, route:<name>; models/vapp_native_i18n.py). The strings are written at install, update, approval and language install/reactivation (and by vizum.app.action_native_i18n_reload) into the jsonb columns Odoo reads, computed from the stored en_US every time; en_US is never written and a missing string stays English. An administrator's own translation of one of these strings is kept (a hash of what the platform last wrote lives on native_i18n_state). The schema compiler now compares and writes the source columns in en_US, so a Spanish installer no longer rewrites them. Not a permission change: a translations-only update still asks for no approval and is audited (i18n:update, i18n:native). Keys do nothing on an older platform, so no min_platform is required. vzm check warns about untranslated native strings and dangling @native: keys (--strict-i18n makes them errors). sdk-next/docs/server-side.md.

5.83

the shared vector scope of a user-scoped app. Vizum.vector.sharedNamespaces() lists the namespaces (name, count, model, dim) the app owns in the SHARED (global) scope, and Vizum.vector.moveScope(ns, {from, to, user_id?, doc_id?, batch?}) moves a namespace's rows between the shared scope and a user's scope WITHOUT re-embedding: the owner of the existing rows changes, so embedding, text, metadata and chunk order are the stored bytes, nothing is embedded and nothing is metered. Administrator or the app's service user only (the store does not record who wrote a shared row, so a plain user cannot be given "the shared rows that are theirs"); user to global is administrator only; batched, re-runnable, never overwrites a row the destination already holds. V.vector.shared_namespaces() (server code) reads the list. An app that calls V.vector.shared_namespaces sets min_platform 5.83. Managed RAG storage lists but cannot move.

5.82

two asks of a paired-device page. (1) Player control: the app cannot reach the YouTube / Vimeo player the PAGE framed for it, so it names the handle embed() returned and the page posts the player's own postMessage command (setVolume 0-100, mute, unmute, play, pause) to that iframe, targetOrigin the provider's exact origin (never "*"), only for players this page created. No new host, no CSP change. Vizum.device.embed(...) handles gain setVolume/mute/unmute/play/pause; feature device-embed-control. (2) Per-device storage, Vizum.device.store get/set/delete/all: a frame with an opaque origin has no localStorage, so a screen's settings (volume) live server side in vizum.app.device.kv, keyed by the paired device (so by app + device), reached only with that device's own token through POST /vizum/device/<slug>/_store: at most 64 keys of at most 4 KB of JSON each (256 KB a device), dropped when the device is revoked. Feature device-store. Device pages only.

5.81

two server-computed facts a guard could not learn, and two limits lifted. (1) The trigger payload carries su: True when the write that fired the trigger ran in a superuser environment (env.su: a vApp method's sudo(), platform-internal code, uid 1), False for the user's own write. sudo() keeps the uid, so uid alone could not tell them apart; it is read from the write's records in base.automation._process, never from the app, and cannot be forged. (2) V.is_service_user(): True when the code runs as the app's own service user (the passwordless job user that jobs, triggers and device routes run as), False for any human. A vApp that reads rec["su"] or names V.is_service_user sets min_platform 5.81 (the install gate refuses it below). (3) A unique of a company_scoped model may list x_company_id, the synthesized company column (a prefix unique per company, one settings row per company); nulls_not_distinct works with it as for any column. A unique that names it sets min_platform 5.81. (4) A job may run with permissions.data "user": the platform writes no shared tick for it, and the job's own V.data is the scope of the user it runs as (the app's service user), never another user's private data; before 5.81 jobs required "global". An app with jobs and data "user" sets min_platform 5.81.

5.80

the offline data layer. A manifest may declare offline {datasets, writes, fallback, max_mb}: named, approved slices of the user's own Odoo data (model, fields, domain with {uid}/{company_ids}/{today±N}, order, limit) that the HOST keeps on the device, and the writes (create / write, with the fields each may touch) that may be queued with no network. The device sends a dataset NAME; the server (api_offline: datasets, config, sync) reads model, fields and domain from the approved snapshot and runs the read as the user, so grants, field ceilings and record rules apply as to a live call. A queued write carries the values the user saw (base) and a queued create or action the computed fields the user saw (expect); a difference answers CONFLICT, and a replay for another user answers OFFLINE_USER_MISMATCH and is kept. The host owns the outbox in IndexedDB (per database and user), applies a queued change to the local copy at once (rollback when the server refuses it), swaps a temporary id (vzm-tmp:...) for the real one when its create replays, syncs on start, on reconnect, on app open and every 15 minutes, hides a copy older than 7 days, and removes the rows (never the queue) on logout or a change of user. Vizum.offline gains datasets, sync, query, readGroup, create, write, conflicts, resolve. A vApp that declares offline sets min_platform 5.80; every actions[].model must be granted or owned. sdk-next/docs/offline-data.md.

5.79

Vizum.identity.confirm: step-up authentication. A vApp asks the HOST to re-confirm the user; the host shows its own dialog (dimming the whole desktop), the user types the account password there and it goes over a dedicated route to the closed model vizum.app.stepup, never through the bridge or to the iframe. The app gets a single-use token (120 s, bound to the user, app, action and session) and spends it in server code with V.identity.consume(token, action), which returns a receipt (id, user, action, meaning, reason, confirmed_at). Not on Solo (UNSUPPORTED_CALL); a device page gets PERMISSION_DENIED. A vApp that names V.identity sets min_platform 5.79 (the install gate refuses it below). sdk-next/docs/identity-step-up.md.

5.78

group_ops. An orm grant may carry group_ops: [{groups, ops}], extra ops (create, write, unlink, call:<method>) for the CALLING user who is in at least one of the groups: "@name" (the app's own native.groups), "<app-key>/@name" (an app in requires) or a real xmlid, never an administrative group. They are computed in _orm_rule, so api_orm, call:, actions and read_group all honour them, and Solo's access group is minted from ops only: a UI app can keep ops read-only for every Solo user and give the owner app's administrators the writes. An op is in ops or in group_ops, not both; moving an op from ops into group_ops narrows (no re-approval), adding one widens. A vApp that uses it sets min_platform 5.78 (the validator and vzm check refuse it below).

5.77

V.tr. The script-hook (trigger guards included), job and native-method sandboxes get V.tr(source, *args, lang=None, **kwargs): the method-side tr() on the app's own i18n catalogue (5.73), interpolated after the lookup, never raising for a missing or malformed translation. Language: lang= when installed, else the call's (a hook: the user whose write fired it), else the language of the user the code runs as; a job runs in its job user's language. A vApp that names V.tr sets min_platform 5.77 (the install gate refuses it below).

5.76

Vizum.app.key. The host already sent the app's key in vizum:ready (app) and the SDK dropped it, so vApps parsed it out of the run URL, which on a multi-database host reads "@<db>" (/vizum/apps/run/@<db>/<key>/...). The SDK now exposes it; vzm check and the store gate warn on code that parses the key from the URL. No server behaviour changes.

5.75

V.sha256. The script-hook, job and native-method sandboxes get V.sha256(data, encoding=None): the SHA-256 hex of a str (UTF-8), bytes or base64 str, at most 32 MiB a call and 256 MiB / 2000 calls a run, charged before the input is decoded. It is an integrity digest, not a signature (package signing is the authenticity check). hashlib stays in the method sandbox for now. A vApp that names V.sha256 sets min_platform 5.75 (the install gate refuses it below).

5.74

NETWORK REACH AND IMAGE FETCH. permissions.net may hold "*": any PUBLIC website (never a private, loopback, link-local, metadata or tunnel address; every hop of a redirect is checked again, the connection is pinned to the address that was verified, and only a short header allowlist is sent), download-only; V.net.fetch_image / Vizum.net.fetchImage fetch ONE image server-side, with a size cap and a deadline for the whole fetch. A host the manifest NAMES reaches ports 80 and 443 only unless the entry says host:port (an app below min_platform 5.74 keeps the old behaviour and is warned). A vApp that uses any of it sets min_platform 5.74.

5.73

SERVER-SIDE TRANSLATIONS. The i18n/<lang>.json files the browser SDK reads also answer tr() in the app's model methods: the install stores them on vizum.app.i18n_catalog (models/vapp_i18n.py), tr() reads the language of the call (context.lang through the bridge, an installed language is just lang; one the instance lacks is kept as vizum_req_lang next to the lang the ORM kept, so the ORM keeps working and a nested with_context(lang=X) still wins), tries es_419 -> es -> msgid and keeps the % formatting. The instance, the Store upload and vzm check refuse a catalogue whose placeholders differ from the msgid's, with markup, or over 512 KB (2 MB together); an update that changes only translations asks no approval and is audited (i18n:update). A vApp that uses it sets min_platform 5.73.

5.72

RESUMABLE CHUNKED UPLOADS. A dropped connection no longer restarts a big Vizum.files.putBlob from zero: POST /vizum/apps/files/<key>/upload/status?token answers {received, next_part, size, sha256, expires_at} behind the same user / app / expiry gate as the other upload routes; the host keeps the token on a network error, sends the same part again with backoff, asks status and goes on from next_part, and when it gives up it aborts explicitly (an abort that cannot reach the server is retried when the network returns) so the quota reservation and the upload slot are freed. Nothing changes for an app: the same Vizum.files.putBlob call. A vApp that wants the guarantee sets min_platform 5.72.

5.71

LARGE APP FILES. Vizum.files.putBlob above 32 MB uploads in parts (begin / part / commit / abort: models/vizum_app_upload.py, the platform reserves the declared size against every quota and verifies size + sha256 before the file reaches the filestore); Vizum.files.getBlob and getRange stream a file out with Range support. permissions.file_limits.max_mb may go up to 512 MB, but a file above 200 MB needs its own administrator approval (permissions.large_files, synthesized) and an app storage cap; the single-request routes (Vizum.files.put, putBlob up to 32 MB, orm.writeBlob) stay at 200 MB. Duplicate app files that an old race left behind are renamed (never deleted) by a one-time migration. A vApp that uses any of it sets min_platform 5.71.

5.70

PAIRED DEVICES AND LARGE FILES. A route may be auth: "device": a screen, kiosk or time clock with no Odoo login pairs with an 8-digit PIN the platform shows and an administrator claims on the desktop; it then holds a hashed, revocable token and reaches only the app's device pages, json and file routes (controllers/device.py, device-routes.md); a device page plays YouTube / Vimeo over the app (Vizum.device.embed, framed by the page, only the providers of device.embeds) and keeps an offline cache (device_sw.js, device_host.js); Vizum.pairedDevices manages the devices from the desktop. permissions.file_limits raises Vizum.files per app (up to 200 MB a file) with a streamed upload — Vizum.files.putBlob, Vizum.orm.writeBlob. A vApp that uses any of it sets min_platform 5.70.

5.69

UPDATES THAT RE-ASK, VERSIONED CONTRACTS, VERIFIED CALLERS, INSTANCE TELEMETRY. An update that changes server code (script hooks and library, model methods, routes, jobs, webhooks, fields with server logic, constraints, automations, native migrations, the evaluated parts of native.ui and manifest actions) sends the app back to needs_approval like a wider grant, and api_update_preflight names each permission and code change (lifecycle.md); Vizum.backend task rows carry status — retrying, expired, dead_letter (reliability.md); provides may name a contract version (name@x.y.z) and requires a contract in a version range (composition.md); a method another app calls through its call: grant reads that app's key with caller_app(), verified by the platform (server-side.md); the instance reports a daily technical profile (edition, active-user band, installed vApps) from 2026-11-04 per Terms 15.4 v1.2, and an administrator can switch the upload off. A vApp that uses versioned contracts, caller_app() or task status sets min_platform 5.69.

5.68

A LARGE CUSTOMER MODULE AS A vAPP (its 1766 tests run on the vApp). In the sandbox: the module's own classes as objects (new_class: public attributes, the program's own methods, a closed list of dunders), its pure modules as the app's library (up to 1 MB / 32 parts with methods; a program of 3 MB / 300k nodes), fields_of(model), with savepoint(): (the only with), base_url(), sign / consteq / verify_legacy (the module's signed links, only for an app that replaces it), format_text, a governed PIL (Image, ImageOps), hashlib, uuid, binascii, pg_errors, clock (time/monotonic), lock_read / fetched_row, with_user / with_env, and fields_get / check_access / has_access on the app's own models; self.env.cr / execute / registry / pool stay unreachable (refused at upload by the platform and the store). An app's methods share one program per process, as a module does. Models: unique entries {fields, nulls_not_distinct, name} (empty values collide; the index named <table>_<name>, as Odoo names the module's constraint), check entries {name, field, op, value} (a PostgreSQL CHECK <table>_<name>), a many2many pair (one relation from two own models), default_get and invalidation by an alias name, order, readonly on any field; native.replaces_min_version (adopt only from a module at its last migration); native.routes kind "file" (a binary behind a link the platform signs: route_file_url / route_file_token / route_file_verify); native.records match (a seeded row whose xmlid is gone is anchored again by its unique fields); the app's groups under a privilege/category named after it; native.adopt on real data: the rows are copied as data, not as events (the app's create/write overrides stay out, its constraints run once over the adopted rows), attachment binaries are shared by reference (no byte read), refs ({id_field, model_field | model_by}) and links to ir.model / ir.model.fields follow the adopted rows; an UPDATE whose requires names an app that is missing or out of range is refused, the installed version stays. A vApp that uses any of it sets min_platform 5.68.

5.67

THE PLATFORM CONTRACT AND SDK RELIABILITY (SDK plan P0–P4). The platform contract reaches apps (Vizum.platform, Vizum.sdk, Vizum.features(), Vizum.supports()); every failed call rejects with a VizumError {code, category, retryable, correlationId}, and Vizum.errors.is / normalize / catalog read them; every call carries a request id; orm.create, actions.run, backend.enqueue and offline.run take an idempotency key, so a retry or an offline replay runs once; the vApp bus no longer fans out across users and apps; packages can be signed (vzm keygen / pack --sign, package-signing.md) and every install verifies them, refusing a modified package; the store can revoke a version and every instance disables it; requires takes version ranges and contracts, Vizum.apps.status() reports them and a required app is not uninstalled by accident (composition.md); an app declares event_contracts and the desktop refuses an emit that breaks them, and Vizum.events.catalog() lists them (events.md); Vizum.apps.health() and api_update_preflight say how an app runs and what an update would change before it is installed (lifecycle.md); the CLI gains a platform emulator (vzm test, vzm dev), vzm diff and agent-ready scaffolds (emulator.md, cli.md); inbound webhooks get a delivery ledger with replay protection, ack/fail (from the browser or a job: V.webhooks) and a dead letter, the bridge a per-app rate limit and metrics, and Vizum.errors.retry (reliability.md); an AI tool declares its risk and side effects, and every host confirms an update or destructive one with the user before the app is reached (ai-tools.md); files carry a sha256, put refuses damaged or disguised bytes and public links expire (files.md); an administrator can give each app an AI-token, network and storage budget (QUOTA_EXCEEDED, reliability.md); a manifest action declares retry and timeout_minutes for its backend tasks (reliability.md). See platform-contract.md. A vApp that uses any of it sets min_platform 5.67.

5.66

A WHOLE ODOO MODULE AS A vAPP (psi_dsd → PSI DSD Core, its 818 tests green on the vApp). native.methods: Python model methods run in the sandbox and installed as real methods of the Odoo class — self/env[...] are governed recordsets (the app's orm grants, ACLs and rules; sudo() lifts ACLs, never the grants), overrides of Odoo methods call super_() (privileged permissions.methods), private helpers are p_x, another app calls them through its own call: grant; computes, defaults, constraints and jobs by method; permissions.private_calls / params / peer_data. native.aliases: the module's field names are real (related) fields of the ORM. native.records / rules / ui (views, actions, menus, reports, the vzm_geo_map widget) / groups.implies. native.replaces: while the named module is installed the app waits (no alias, override, constraint, backend or job on Odoo's models) and adopts — its rows, its columns on Odoo's models, its groups' members (groups[].adopt), and the chatter of each adopted row when the module is uninstalled; then the app goes live by itself. A vApp that uses any of it sets min_platform 5.66.

5.65

Vizum.team COVERS WHAT A USER-PROVISIONING MODULE DID (united_insurance_team). team.whoami() -> {uid, manager, role}; member rows carry phone, last_login, self, role_label and admin (an administrative account holding a role is listed, still untouchable); save takes a phone, reactivates a member the app manages and refuses to change the caller's own role. A role may let its own groups into other apps of the same vendor (role apps: [{key, solo?}], each listed in the privileged permissions.team_apps; restricted desktop access and, with solo, the phone launcher; never removed). native.team.adopt_existing "dedicated" (privileged permissions.team_adopt) takes over, on install/update, the accounts that already play the app's roles and hold nothing else, so its managers can reset their password; an account with any other group keeps only "give or take the role". A vApp that uses any of it sets min_platform 5.65.

5.64

A vAPP CAN TAKE OVER THE DATA OF THE MODULE IT REPLACES. native.adopt: [{model, from, fields: {own field: module field}}] copies every row of an installed module's model into one of the app's own models, once (vizum.app.adopt.map), on each install/update while that model exists: rows first, then the links between adopted models translated through the map (links to shared models keep their ids). Each from must be listed in the privileged grant permissions.adopt (a new one widens); platform, identity and security models and secret fields are refused. The customer uninstalls the module afterwards. A vApp that adopts sets min_platform 5.64.

5.63

THE LAST FIELD SHAPES A MODULE USES. translate: true on a char/text/html field (one value per language, as translate=True in a module); type "json" (fields.Json); a one2many from an own model to a SHARED model whose inverse is a many2one column the app adds to that model in native.fields (created after it, in _apply_shared_one2many); up to 80 own models per app (was 50). Also fixed: an app that added to res.partner a many2one pointing at its own model could not be uninstalled (Odoo reflects the column on res.users as a 'base' field, and dropping the model refused it): such a column is now dropped before the model. A vApp that uses translate, json, a one2many to a shared model or more than 50 models sets min_platform 5.63.

5.62

A SANDBOX FOR REAL LOGIC, WITH A CLOCK. Script hooks may define top-level functions (def, no decorators, no nesting — so no closures) and use while; the app may share code between its hooks in native.script.lib ({name: code}, vetted the same way, run before each hook). In exchange every run has a TIME BUDGET — 30 s, 120 s for a scheduled job — enforced by a check the platform injects into every loop and function body (no signals or threads); a run that exhausts it stops with a clear error. On a 5.61 build a def or a while is refused at install, so a vApp that uses them (or lib) sets min_platform 5.62.

5.61

NATIVE DATA ACROSS VERSIONS. native.migrations: [{to, ops}] run by reconcile on the update that crosses to (vizum.app.native_schema_version remembers the version last reconciled; a first install migrates nothing): rename_field (the column and its data keep living under the new name; the app's views are dropped first and rebuilt), copy (old column into an empty new one, both existing), hook (a script hook of the app, run as its job user with installing=True). Order: renames, new schema, data ops, then the stale columns go. native.seed: [{model, key, rows | file (a .json in the bundle), update?}] upserted by the natural key on every install/update, references {"$ref": "<model>:<key>"} to rows seeded earlier. Uninstall deletes the data, as a native module's uninstall does. A vApp that declares either sets min_platform 5.61.

5.60

Vizum.team: A MANAGER OF THE APP CREATES AND EDITS THE USERS WHO PLAY ITS ROLES. The manifest declares native.team {managers: [group refs], roles: [{name, label, help, groups}]} under the privileged grant permissions.team; api_team (vizum_app_team.py) offers roles / members / save / set_active / remove / set_password / invite. Only a manager (or a settings admin) calls it; a role gives exactly its approved groups and never one that is or implies an administrative group (checked on the implied closure at run time); administrative accounts are never touched; a user the app's team did not create (vizum.app.team.member) can only gain or lose the app's roles. It replaces the per-customer Odoo module apps needed for this (united_insurance_team, psi_dsd's manager_provision_user). A vApp that calls Vizum.team sets min_platform 5.60.

5.59

A vAPP CAN DEFEND A FIELD OF ITS OWN MODELS (closes the 2026-09-01 field-ceiling concern). An own-model field may declare writers (["@server", "@<declared group>", "<group xmlid>"]), server_only: true (= ["@server"]) or computed_by: "<hook>" (a trigger hook of the app on that model computes it; = ["@server"]). The ORM refuses a create/write that sets it unless the caller is a writer — one gate for the iframe, the invoked hooks, the backend and RPC (vizum.app.native.runtime on base). "@server" is the app's SERVICE USER — an internal user with no password, created when the app declares a server writer (or native.service_user), member of base.group_user and of the groups its models grant, made its job user (triggers and jobs run as it), archived at uninstall — or Python running as the superuser/sudo, as for a native module's field only its code writes. Administrators are writers only when listed. Apps that declare none of this keep their job user unchanged. min_platform 5.59.

5.58

WHAT A MODULE'S PYTHON GIVES ITS MODELS, DECLARED. On the app's own models: default (a literal of the field's type, or {"dynamic": today|now|user|company}) and sequence ({prefix, padding}: numbered on create from the app's own ir.sequence), both applied by the platform runtime (vizum.app.native.runtime extends default_get and create on base, acting only on a READY app's x_vzm_ models, from a cached map of the manifests); unique (real PostgreSQL unique indexes, vizum.app.native.unique, refused at install when rows collide); chatter (mail thread + activities, only ever turned on) with tracking on fields. Computed fields on own models: formula (manifest names, dependencies derived), related (from one of the model's many2one) and aggregate ({of: <one2many>, op: sum|count|min|max|avg, field}) — the totals of a document — compiled into platform-owned compute bodies, created in dependency order (Odoo checks a compute's path against the registry at create time). They hold for the vApp, the backend and RPC. A 5.57 build refuses or ignores every one of these keys, so a vApp that uses any of them sets min_platform 5.58.

5.57

A vAPP CAN MODEL A DOCUMENT WITH LINES. On the app's own native models: a one2many names its inverse (a many2one declared on another of the app's own models, pointing back) and compiles to Odoo's relation_field — before, the validator accepted a one2many the compiler could not install. A many2one takes ondelete ("set null", the default; "cascade"; "restrict"), enforced by PostgreSQL's foreign key, and any field but an x2many or a boolean takes required (a required many2one cannot "set null"). A one2many may also sit on a SHARED model to list the app's rows (res.partner -> its orders); there required and cascade are refused — they would act on records other modules own. A version may add, change or drop them: the compiler drops a one2many before its inverse (Odoo refuses the reverse outside a module uninstall), a dropped ondelete returns the field to "set null", and a one2many is never archived (it has no column). The bridge's relational guard already governs the nested commands. On a 5.56 build a one2many dies at install on Odoo's own error and ondelete/required are silently ignored — so a vApp that uses any of them sets min_platform 5.57.

5.56

A HOOK CAN GUARD A DELETION. native.script.hooks[].trigger.on accepts "unlink" (with enforce): a base.automation on_unlink whose action calls the same dispatcher, run BEFORE the deletion — a hook that raises (V.fail) aborts it, for every ORM unlink: the backend, sudo, crons, the app's own Vizum.orm.unlink. Payload: event "unlink", changed [], old = every stored content field as the row is before the deletion (same ceilings), new {}. Every trigger payload gains installing (true while the app's own install/update runs its migrations; the guard still runs and decides). Uninstall is unaffected: the automation is torn down before the model, whose table is dropped, not unlinked. NOT seen by any trigger: deletions PostgreSQL performs itself — a set-null or cascade many2one (every vApp many2one is set null), many2many link rows — so guard the record actually deleted. A vApp that declares on: "unlink" sets min_platform 5.56.

5.55

PUBLIC ROUTE PAGES. A route may declare auth: "public" — a PAGE only (a public json route does not exist), with no groups — at /app/<slug>/<route>, open to anyone, signed in or not, of the company it is served in (the website's company when website is installed, else the public user's; an app of another company answers the identical 404). The page carries the bundle credential and nothing else: NO caps and NO route run-token, so the bridge refuses every call from its iframe; an anonymous visitor's page is Cache-Control: public, max-age=300. Public page names surface as permissions.public_routes, a separate privileged grant (widening → needs_approval) shown on its own approval card with each full URL. Optional website_menu ({text <= 40, sequence}) becomes a website.menu entry per website of the app's company (all websites without one), a recorded website_menu artifact removed when the app leaves ready, drops the route, or is uninstalled; skipped without website. Optional sitemap: true lists the page in the website sitemap (part of the approved descriptor). A vApp that declares a public route sets min_platform 5.55.

5.54

A TRIGGER KNOWS WHO WROTE, WHO OWNS, AND WHAT THE WRITE LEFT. The hook payload gains uid (env.uid of the write — 1 when server code writes as the superuser), owner (the row's create_uid) and new (post-image of the written fields; every stored content field on a create), read with the platform's rights like old and under old's ceilings: the app's read grant, never a field the app hides from the hook identity (VZ-SEC-23), binaries as their size, text over TRIGGER_TEXT_CAP as its length (also in old now). A guard runs as the job user, whose record rules may hide the row it guards; before 5.54 "only the owner may share this" could not be enforced server-side (Vizum Sheets). A hook that reads uid/owner/new sets min_platform 5.54.

5.53

ROUTES A vAPP DECLARES (native.routes), portal and internal only. The platform serves GET /app/<slug>/<route>[/<sub>] (a platform page embedding the app's sandboxed iframe, with the route as its intent — Vizum.route) and POST /app/<slug>/<route> (a json route: CSRF, body <= 64 KB, rate-limited per user/app/route, audited, the declared hook run AS THE VISITOR), plus the GET alias /my/<slug>/… for a portal page and an optional card on the portal home. A route is served only while its exact descriptor is in the approved snapshot (permissions.routes; declaring or editing one needs approval, and the app needs install_scope admin). A portal (share) user reaches the bridge ONLY through the route run-token the dispatcher mints for that app, route and user — and only api_session (minimal) / api_orm / api_run_hook (the route's json hooks, with that route's rate limit, size cap and audit) / api_watch_hash / api_eval_domain / api_route_token_refresh, within the app's grant bounded by the visitor's own rules. auth: public and website_menu are refused by the validator. A vApp that declares routes sets min_platform 5.53.

5.52

Vizum.assistant.kbSearch(query, {catalogs, topK}): passages from the Knowledge (RAG) catalogs for a vApp holding permissions.assistant — the Assistant's own retrieval (hybrid, rerank, CRAG), run as the CALLING user (their scope and per-reader record filter, never the job user), catalogs the user cannot read refused by name, bounded (query 2000 chars, 20 catalogs, top-k 8, 1500 chars per passage) and traced in Knowledge → Trazas as vapp:<key>. A vApp that reads Knowledge this way (Vapp Creator) sets min_platform 5.52.

5.51

AN EXPLICIT COMPANY ON A company_scoped NATIVE MODEL IS HONOURED, AND VETTED ON WRITE. A create used to replace an explicit x_company_id with env.company, and a write was not checked at all (Odoo re-checks record rules after a create, only before a write), so an app could move a row into a company its user is not in, or make it global. Now an explicit x_company_id — on create, write, a nested line update or a copy default — must be one of env.companies (the browser's active companies; the job user's own companies for a hook), else ValidationError; False on a write is refused; a create naming none is still stamped. A vApp that files rows under another of its user's companies without re-writing x_company_id after the create sets min_platform 5.51.

5.50

MENUS HIDDEN PER USER OR PER GROUP. vizum.menu.hide (menu, users, groups, hidden until, why, app_key) is subtracted from ir.ui.menu._visible_menu_ids — the result Odoo's menu service, the command palette and the Vizum desktop all read — with its submenus. Not an ir.rule: Odoo caches visible menus by GROUP SET, so a per-user rule leaks one user's hiding to everyone with the same groups. Administrators are never subject to it, Settings and Apps cannot be hidden, an empty table costs no query, and uninstalling the vApp that created rows (app_key) deletes them. Admin-only ACL. A vApp that manages hidden menus (Hide Menu) sets min_platform 5.50.

5.49

AN APP'S OWN NATIVE MODELS NEED NO ORM GRANT IN THE BROWSER EITHER. The server (_orm_rule) always granted an app its own native models, and the native fields it added to shared models, without permissions.orm; the browser gate of orm/mail/activity/meta still demanded a non-empty permissions.orm, so a vApp whose only data was its own model got PermissionDenied. The host caps now carry a server-computed orm_native (_client_caps). A vApp that calls its own models without declaring an orm grant sets min_platform 5.49.

5.48

MAP TILES THROUGH THE PLATFORM. OpenStreetMap answers a tile request with no Referer with its "Access blocked" PNG, and a vApp iframe (opaque origin) never sends one. The platform now serves /vizum/tiles/<key>/<token>/<exp>/<z>/<x>/<y>.png (the iframe's run capability is the credential — never an open proxy) and /vizum/tiles/<z>/<x>/<y>.png for a signed-in user: it fetches from OSM identified as the tile usage policy asks, caches on disk for at least 7 days, never caches a refusal, and serves with CORS. The SDK exposes Vizum.map.tileUrl(). A vApp that uses it sets min_platform 5.48.

5.47

WORKFLOW CONTEXT KEYS. api_orm (and V.orm in hooks) accepts, besides lang, the two context keys Odoo's web client itself sends to finish a PARTIAL transfer: skip_backorder and picking_ids_not_to_backorder on stock.picking.button_validate — typed, ids restricted to the call's own (ORM_WORKFLOW_CONTEXT). A 5.46 build refuses them, so a vApp that validates partial transfers in-app (with or without a backorder) gates on 5.47 or hands the transfer to the Odoo form.

5.46

RETIRING A COMPUTED FIELD FREEZES IT INSTEAD OF BREAKING RECOMPUTES. A vApp version that stops declaring a formula field used to archive it by rename (<name>__archived_<id>) with its compute still writing the old name: every recompute of its dependencies raised KeyError(<old name>) — on res.partner no contact could be renamed and no user created (measured on dev with CRM Booster 2.1.0). From 5.46 the archive clears compute/depends first and keeps the stored data, and the 5.46 upgrade repairs fields archived before it. A vApp whose new version retires a computed field sets min_platform 5.46, so the installer refuses the update on an instance without the fix.

5.45

THE PGVECTOR GUIDE CAN FINISH THE JOB. Before it, nothing a vApp could call set the RAG storage mode to pgvector: the "RAG pgvector Setup" guide sent the admin to Managed AI, and Managed AI answered "enable it from the guide". vector.pgvActivate({active, force?}) (admin) switches Mode 3 on — refusing when the infrastructure is missing, when stored vectors are not yet in pgvector (they would drop out of search), or out of managed storage — and back to Local. vector.pgvIndex(opts) exposes the existing per-dimension hnsw op, and pgvStatus adds per-dimension counts and the table size for administrators.

5.44

RAG THAT OBEYS ODOO, AND A DOCUMENT REPLACED IN ONE PIECE. (1) vector.search / dump / indexed_docs and rag.list_chunks withhold every passage derived from an Odoo record the CALLER cannot read under record rules, or whose id now names another record (measured: a global sale.order job served order text to a user with no sales access). (2) vector.delete takes {doc_id, keep_gen} (commit a rewrite: retire every chunk of the doc not of that meta.gen) and {doc_id, gen} (roll a failed rewrite back) — a 5.43 build ignores both keys and deletes the WHOLE document, so a vApp that writes generations gates on 5.44. Also: rag jobs prune records deleted at the source, rag.update changes only the keys it is sent (and keeps the owner), and Ollama chat sends num_ctx + think:false.

5.43

COMPARE-AND-SET ON A NATIVE MODEL: orm.write(model, ids, vals, {expect}) in the JS SDK and V.orm.write(model, ids, vals, expect=…) in the script runtime. The rows are locked (SELECT … FOR UPDATE), re-read, and written only if every expected field still holds its value; the call then resolves to {updated, current} instead of Odoo's bare True. Vizum.db has had this since 5.39 — but ONLY for an app's own tables (api_update), so a native Odoo model had nothing and the only way to CLAIM a record was read-then-write. Two clients that read the same value both wrote it: two approvers of one Agent Center proposal both read pending, both wrote executing, both executed. The same shape reaches money — two registers claiming one IoT print job, two terminals redeeming one gift card. A 5.42 build refuses expect as an unsupported keyword (_orm_bind_args fails closed), so a vApp that relies on it gates on 5.43 rather than silently losing the guarantee.

5.42

vizum.migration.run.action_discover(): the migration plan and the source→target field map are built SERVER-SIDE from both live schemas (models/migration_engine/plan.py), and the run exposes discovery_json / include_master / include_vapps / extra_models. Until 5.42 the plan could only be built by the Migration Assistant's own browser code, from the destination's schema alone — a 5.41 build has no action_discover and the call raises, so a vApp that plans this way gates on 5.42.

5.41

db.share(table, id, {users: ["job_user", …]}): the literal "job_user" resolves server-side to the identity the app's jobs/hooks run as (job_user_id, default installer; never superuser/archived/portal). Lets a row reach the app's automations without being public (Agent Center memory, audit P4). A 5.40 build does int("job_user") and raises, so a vApp that shares this way gates on 5.41.

5.40

V.vector.search(namespace, query, opts) / V.vector.namespaces() in server scripts (hooks and jobs): READ-ONLY, through the same api_vector the iframe uses, gated by permissions.vector, metered on its own per-run budget (20). Lets a scheduled agent consult the knowledge base (Agent Center audit P2). A 5.39 script has no V.vector and fails with AttributeError, so a vApp whose hook uses it gates on 5.40.

5.39

Vizum.db compare-and-set: db.update(table, id, values, {expect: {field: value}}) writes ONLY if the row still holds every expected value, under a row lock, and the result says _updated: true|false. It is what lets two approvers race for the same proposal and have exactly one win (Agent Center audit P1, docs/audits/2026-09-25-agentcenter-rule-reach.md). A 5.38 build drops the fourth argument and writes unconditionally, so a vApp that relies on it gates on 5.39.

5.38

Vizum Instances pass: Vizum.instances.pass() -> {token, expiresAt} behind the new boolean grant permissions.instances_api (privileged; gaining it widens). The server asks the Vizum Store (/store/api/v1/instance/assertion) with this database's instance token — which never reaches the iframe — for a 5-minute pass signed with the Store's Ed25519 key: database, Vizum account, acting user by Odoo email. The Vizum Instances API verifies it with the Store's public key, so no key is pasted by hand into each Odoo (decision 2026-09-24). A 5.37 build has no instances namespace: the call is refused, so the vApp gates on 5.38.

5.37

Report Builder 1.0 (native visual editing of Odoo reports, §3.3 of its spec): four small platform changes, all four lines. reports.html(name, ids) -> {html} — the host fetches /report/html/... and inlines same-origin CSS, because the app iframe is an opaque origin that cannot fetch either itself. permissions.reports accepts "<prefix>.*" and "*" (Report Builder's templates are dynamic: vzm_reportbuilder.template_<id>; an exact-name-only allowlist would force re-approving the manifest per saved template) — "*" is privileged. api_orm kwargs.context now accepts ONLY {"lang": "xx"} (reading an arch without translating it); any other key is refused. _apply_bindings skips (log, don't fail) a binding whose model this base does not have installed, and reconcile() retries it on the next version change.

5.36

native.bindings: a manifest may bind the app to the Action menu of a NATIVE model (native.bindings, one entry per {name, model, label, groups}, gated by the native_bindings grant). The platform compiles one ir.actions.server per binding whose only code calls the trusted dispatcher vizum.app._open_binding, which opens the app with the selected records as Vizum.intent {binding, model, ids}. min_platform 5.36: an older build has no whitelist under native, so bindings is silently ignored — the app installs and the Action-menu entry never appears, which is the silent no-op that makes it a capability. 2026-09-12, still 5.36: a binding may add target: "window" | "modal" (modal = ActionDialog over the record). NOT a bump on purpose: _valid_native_bindings ignores unknown keys, so a 5.36 build installs a manifest that declares target and opens it in a window — a graceful degradation the author can see, not a silent no-op.

5.35

assistant.send accepts the CALLING APP's model / reasoning effort / knowledge base ({model, effort, namespace}). vizum.assistant.pref is per-USER, so before this a vertical vapp's administrator could not fix the AI behaviour for their crew: two technicians in the same app got different models. All three are REQUESTS — the server still caps effort at the user's vizum.ai.policy ceiling and filters the model through it, so an app can never exceed the policy. The forced namespace IS a hard filter over what the model asks for. min_platform 5.35: on an older build the three fields are silently dropped and the app's setting reaches nobody — a silent no-op, which is why it is a capability and not a soft add.

5.34

an AI call may carry ref, an opaque attribution tag naming which of the app's OWN internal consumers spent the tokens (Agent Center names the agent). The host pops it before the provider ever sees it and records it on the same audit row as the charge, so Managed AI can break an app's spend down one level with nothing to reconcile. An app that sends ref MUST declare min_platform 5.34: on an older build the field is not recognised as the host's and is forwarded into the provider request, which rejects the unknown field — so the app installs happily and every AI call fails.

5.33

V.db — the app's own Vizum.db TABLES reached from a server-side script. The store was browser-only: V wired orm/net/oauth/files/ai/data/json, so a SCHEDULED job could not read the very tables its app's UI writes. An app whose cron acts on app-owned state (an automation registry, a retry queue, a schedule) therefore had to mirror that state into a V.data collection and hand-sync two stores for one fact. V.db routes to api_db, the same permission-gated dispatcher the iframe uses, so the manifest schema, the declared rules and indexes, the admin-authored write gate and the acting-user row scoping all still apply. An app whose job reads its own tables MUST declare min_platform 5.33 — on an older build V.db is simply absent and the hook dies with a NameError on its first tick, having installed happily.

5.32

enforcing, delta-aware script triggers. A trigger hook may declare trigger.enforce, which makes the platform REFUSE the triggering write when the hook cannot run instead of proceeding unguarded; and every trigger hook's rec now carries the write's own change set (event, changed, old). Both are load-bearing for a guard: without enforce an archived job user silently disarms it, and without changed it can only assert properties of the post-image, every one of which the caller can satisfy by writing more fields in the same call. An app that relies on either MUST declare min_platform 5.32 — on an older build enforce is ignored and changed is absent, so the guard would install and then quietly not guard.

5.29

native.groups: the schema compiler creates real res.groups for a manifest's declared roles (stable xmlid), so access/rules can reference "@name" instead of every vApp with roles needing a hand-written Odoo addon just to get a group to bind to.

5.28

V.commit() in the JOB runtime + one savepoint/commit PER APP in the job cron. A job POSTs to Instagram (irreversible) and then writes remote_id (undoable). They used to share ONE transaction spanning every job of every app, so any later failure rolled the bookkeeping back while the post stayed published — and the next tick posted it AGAIN.

5.27

Vizum.files.publicUrl — an unguessable but PUBLIC https link to one of the app's own files (permissions.files_public). Instagram has NO byte upload: you hand Meta a URL and Meta downloads it. Without this a social vApp can generate an image and then has no way to put it on the post. revokePublic kills the link once the network has taken it.

5.26

the SOCIAL OAuth rail: shared (brand) connections usable by every user AND by the unattended jobs (permissions.oauth_shared + V.oauth in the script runtime), many accounts per provider (account_ref), PKCE + provider client-auth styles (X, TikTok), Meta's long-lived page-token dance, and a refresh cron so a token cannot lapse overnight and kill the 09:00 post.

5.25

Vizum.ai.image — image GENERATION for vapps (managed mode only). Metered PER IMAGE, not per token, so it needs its own permissions.ai_image on top of permissions.ai.

5.24

Vizum.devices.location — HOST-mediated one-shot GPS fix (devices:["location"]). navigator.geolocation is auto-denied inside the opaque-origin iframe (same reason the mic is host-mediated), so the host asks on its real origin and only {lat,lng,accuracy,ts} crosses.

5.21

Vizum.ui.openUrl — the host opens an external http(s) URL in a new tab. A sandboxed, opaque-origin iframe CANNOT window.open (it returns null and nothing happens), so any vapp that sends the user to Stripe, an OAuth consent screen or a doc link needs this. All shipped.

5.20

server-side vApp code: a manifest jobs[].script runs a native.script.hooks entry as job_user_id, with V.net / V.ai / V.data / V.json (and, from 5.33, V.db) and the time helpers (V.now_odoo, V.add_minutes, V.minutes_between, V.clock). An app that must answer a webhook with nobody's browser open declares min_platform 5.20 — on an older platform its job would install happily and then silently never run.

5.5

Vizum.audio (transcription — local Whisper default / managed metered-per-minute gateway).

5.4

Vizum.ocr (OCR — local Tesseract default / managed metered-per-page gateway)

5.3

AI tools — manifest ai_tools + Vizum.ai.tools.handle (client-handled) + Vizum.ui.openApp(key, payload)

5.2

Vizum.docs (raw-document store for RAG re-indexing) + Vizum.vector.pgv* (Mode-3 local-pgvector setup)

5.1

Vizum.domain (Visual Domain Builder)

5.0

Vizum.vector / Vizum.embed / Vizum.sessions

Concepts

The platform contract — versions, feature detection, stability and errors GENERATED

Everything a vApp can rely on — which API exists, what it needs, since which capability, how stable it is and how it fails — comes from ONE machine-readable file, vizum-platform-contract.json (served at /vizum_apps_platform/static/sdk/vizum-platform-contract.json and shipped inside @vizum/vapp-cli), which the platform, the SDK, the vzm CLI and this page are all built from. A coding agent should read that file (or run vzm context) rather than this page.

Contract 1 · capability 5.156 · SDK 5.156.0 · api version 1 · manifest schema 1.

Using it

await Vizum.connect();

// Which platform, which host — informational; never branch on `build`.
console.log(Vizum.platform.capability, Vizum.platform.host, Vizum.sdk.version);

// Feature-detect before using something newer than your min_platform, or that only
// some hosts serve. On a platform older than 5.67 supports() itself is absent.
const can = (n) => typeof Vizum.supports === "function" && Vizum.supports(n);
if (can("realtime")) { Vizum.realtime.channel("board").on("changed", reload); }
else { Vizum.refresh.on(reload); }                 // Solo has no realtime receive

// Branch on the error's code or category, never on its text.
try {
    await Vizum.orm.write("x_vzm_board", [id], vals, { expect: { x_rev: rev } });
} catch (e) {
    if (Vizum.errors.is(e, "CONFLICT")) { await reloadAndMerge(); }
    else if (e.retryable) { scheduleRetry(); }       // network, timeout, rate limit
    else { Vizum.ui.notify(e.message, "danger"); Vizum.errors.capture(e); }
}

Six versions, six meanings

Gate an app on capability (min_platform) or on a feature (Vizum.supports(...)), never on the platform build or the Odoo version.

Stability policy

Error catalogue

Every failed call rejects with an Error carrying code, category, retryable, correlationId and details (see Vizum.errors). message keeps the text it always had, so code that reads e.message keeps working; new code should test e.code.

Request ids, retries and idempotency

Every call carries a request id (the SDK mints it). It reaches the server, which records it on the audit rows the call produces, and it comes back on a failure as VizumError.correlationId — one id names the call from the iframe to the server's trail (Vizum.audit.search({request_id})). An AI call stores it on its charge too (vizum.ai.usage.request_id, 5.69): a billed charge names the call that caused it. It stays on the instance — it is not sent to the Store with the charge.

The same id follows the work the call starts (Batch 5): a backend task (backend.enqueue) and a bulk job (bulk.export / bulk.rebuild) store it and run with it, so the audit rows of their run, the tasks and jobs they queue in turn, and the resource events they cause carry it as well. The idempotency record of a keyed call keeps the id of the call that claimed the key. Work that starts without a call starts its own id: an inbound webhook delivery (hook-…), a scheduled job run (job-<name>-…), a task or bulk job queued from server code with none (task-…, bulk-…). A host mints one (h…) for a call from an SDK older than 5.67, which sent none, so every failed call carries correlationId.

Show e.correlationId wherever your app reports a failure the user may take to support: the administrator looks it up and sees the whole chain (below). It is a label, not a credential — the platform never decides access with it, and an id the app sends is only format-checked (8–64 of A-Z a-z 0-9 _ -).

Names, so one thing is never two: correlationId on a VizumError is the value stored as request_id on the server's rows (and the request_id filter of Vizum.audit.search). A job run's id is its *operation id* and plays the same role for the work the run does.

What Vizum.audit.search returns depends on who asks. Every line the app logged (Vizum.audit.log) and every ai:, action: or job: line reaches every user of the app. The platform's reserved lines are not the app's diary: an identity. or platform: line (a step-up confirmation, an offline replay, a resource event) is about one user, and a member of the app reads only their own; trust: and policy: lines are about the installation. The app's managers — a Settings administrator, or a manager of the app's approved team (native.team.managers) — read every line. A member tracing their own call by request_id finds all of its lines.

Support: from a correlation id to the rows. An administrator calls vizum.app.correlation_lookup(<id>) (JSON-RPC, or env["vizum.app"] in an Odoo shell). It returns {request_id, rows, truncated}: every row that names the id, oldest first, across webhook deliveries, audit rows, idempotency claims, backend tasks, bulk jobs, AI charges and resource events, each with its model (the ledger), id, app, user, at and a few fields of its own (a task's state and last_error, a delivery's status, a bulk job's or resource event's target_model, …). A resource event row counts many occurrences and keeps the latest id; each occurrence that came from a call is also an audit row (platform:rgov.<kind>) under its own id. Administrators only; it only reads; at most 50 rows per ledger (truncated says when there were more). The server log names the same id on a failed task attempt, a failed bulk job and a failed job run ([request_id=…]).

Whether a call may be repeated depends on what it does. The rule is explicit per operation:

A key is 8-128 characters of A-Z a-z 0-9 _ . : - (crypto.randomUUID() works), scoped to the app and the user, and lives 8 days; a key an offline replay claimed lives 30 days, because a queue waits as long as it must (an update awaiting approval, an expired session). Only a success is remembered: a call that failed did not happen, and a retry with the same key runs it. A key reused for different arguments rejects with IDEMPOTENCY_MISMATCH instead of returning another operation's result. VizumError.retryable says when repeating the same call can help (lost connection, timeout, rate limit); repeat a write that is not idempotent only with its key.

One key across the online call and its declared action (5.109, feature idempotency-across-paths). An app that sends something online with orm.callOn(model, ids, method, args, {idempotencyKey}) and, when the answer is lost, queues the same thing as the declared action whose target is that method (offline.run(action, {ids, ...params}, {idempotencyKey}), or actions.run) sends ONE operation: the second path answers the stored result in its own shape ({ok, result} for an action, the bare result for a call) and runs nothing. They match on the model, the method, the records and the arguments bound to their names by the method's own signature ([payload] and {payload} are the same call of def m(self, payload=None)); a method that takes *args or **kwargs, or another app's method, never matches across paths. Before answering, the second path runs its own checks except the one that needs doing it again: the grant (call:), the action's approval and groups, the online path's consent (the «App action» answer, unless it is a declared read call or a method of the app's own model), the grant's domain, and READ on the records — a user who lost WRITE on a record still gets the answer of what they already did; one who lost READ gets the refusal. The same key with other records or arguments is IDEMPOTENCY_MISMATCH.

const key = crypto.randomUUID();                 // one key per business operation
async function save() {
    try { return await Vizum.orm.create("x_vzm_order", vals, { idempotencyKey: key }); }
    catch (e) { if (e.retryable) { return save(); } throw e; }   // safe: same key
}

Permissions

Every grant a manifest can hold, from the same registry the installer's risk tier is checked against (tools/store_risk_tier_matches_contract_test.py). Privileged grants make the app wait for an administrator at install, and the store for a human reviewer; an update that ADDS one is re-approved. *Derived* grants are not written by the author: the validator builds them from another manifest section.

Host features

Vizum.capabilities().features lists what the host the app runs in serves. Detect a feature before relying on it; not every host serves every feature.

API reference

since is set where a capability introduced the member; a member without one predates the capability notes and is available on every supported platform. Permission is what the host gate and the server enforce for the bridge namespace behind the member.

Top level

Vizum._t, Vizum.app (since 5.76), Vizum.capabilities, Vizum.connect, Vizum.env, Vizum.features (since 5.67), Vizum.intent, Vizum.isMobile, Vizum.model, Vizum.onClose (since 5.7), Vizum.onPause (since 5.7), Vizum.onResume (since 5.7), Vizum.onVisibility (since 5.7), Vizum.platform (since 5.67), Vizum.query, Vizum.route, Vizum.scope, Vizum.sdk (since 5.67), Vizum.session, Vizum.supports (since 5.67), Vizum.theme

Signatures (from vizum-sdk.d.ts):

• _t(key: string, ...params: any[]): string — i18n/<lang>.json lookup in the iframe, %s filled in order.
• readonly app: { readonly key: string | null } — SDK 5.76 — this app's own key, sent by the host in the handshake: key is set once connect() resolves (null before, and on a host older than 5.76).
• capabilities(): Vizum.Capabilities
• connect(): Promise<{ caps: Vizum.Caps; theme: any; session: Vizum.Session | null; intent: any; mobile: boolean }>
• env: { mobile: boolean } — SDK v3 runtime environment.
• features(): string[] — SDK 5.67 — the feature ids this host serves (a copy of capabilities().features).
• readonly intent: any
• readonly isMobile: boolean — True on a phone-sized desktop (mirrors env.mobile).
• model<T = Record<string, any>>(name: string): { readonly name: string; search(domain?: Vizum.Domain, opts?: object): Promise<number[]>; searchRead(domain?: Vizum.Domain, fields?: (keyof T & string)[], opts?: object): Promise<Array<Partial<T> & { id: number }>… — A per-model accessor — the no-build equivalent of @vizum/vapp-types' model<T>().
• onClose(cb: (event: Vizum.CloseEvent) => void): Vizum.Subscription — One-shot dispose signal posted just before teardown.
• onPause(cb: (event: Vizum.VisibilityEvent) => void): Vizum.Subscription — Sugar over onVisibility, fired only on the hidden edge (visible === false).
• onResume(cb: (event: Vizum.VisibilityEvent) => void): Vizum.Subscription — Sugar over onVisibility, fired only on the visible edge (visible === true).
• onVisibility(cb: (event: Vizum.VisibilityEvent) => void): Vizum.Subscription — SDK v5.7 lifecycle events (opt-in, advisory; no manifest grant).
• readonly platform: Vizum.PlatformInfo — SDK 5.67 — the platform, its versions and its host (sdk-next/docs/platform-contract.md).
• query(model: string): Vizum.Query — SDK v4 fluent query builder (also Vizum.orm.query).
• readonly route: Vizum.Route | null — SDK 5.53 — the declared route (native.routes) this app was opened on, from a route page (/app/<slug>/<route>[/<sub>] or its /my/<slug>/… alias); null anywhere else.
• scope(): Promise<Vizum.Scope> — SDK 4.1 — what storage scope this app runs in.
• readonly sdk: Vizum.SdkInfo — SDK 5.67 — the runtime SDK's own version and api version.
• readonly session: Vizum.Session | null
• supports(name: string): boolean — SDK 5.67 — true when this platform AND this host serve name: a feature id ("realtime") or an SDK member ("files.publicUrl", "phone").
• readonly theme: { accent: string; dark: boolean }

actions

stability stable · permission: permissions.actions (non-empty)

Members: Vizum.actions.list, Vizum.actions.run

Bridge ops: list, run

• list(): Promise<Array<{ name: string; label: string; model: string; groups: string[] }>>
• run(name: string, params: { ids: number[]; [k: string]: any }, opts?: Vizum.Idempotent): Promise<{ ok: boolean; result: Vizum.ActionRunResult }> — SDK 5.102 (supports("actions-typed-result"), app min_platform 5.102 or later): result takes the shapes of a call: (5.98) — a {@link Vizum.OrmActionResult} when the method opened a wizard or a form (stock_sms's c…

activity

stability stable · permission: permissions.orm (or own native models)

Members: Vizum.activity.done, Vizum.activity.list, Vizum.activity.schedule

Bridge ops: done, list, schedule

• done(model: string, id: number, activityId: number, feedback?: string): Promise<boolean>
• list(model: string, id: number): Promise<Array<{ id: number; summary: string; note: string; date_deadline: string | null; user: [number, string]; type: string; overdue: boolean }>>
• schedule(model: string, id: number, opts: { summary?: string; note?: string; date_deadline?: string; user_id?: number; type?: string }): Promise<{ id: number }>

ai

stability stable · permission: permissions.ai; storeAccount also store_account; billing/byok/instance settings also ai_admin; image also ai_image

Members: Vizum.ai.account, Vizum.ai.appPermissions, Vizum.ai.billing, Vizum.ai.byokFallback, Vizum.ai.byokSet, Vizum.ai.byokStatus, Vizum.ai.chat, Vizum.ai.complete, Vizum.ai.embed, Vizum.ai.getInstanceSettings, Vizum.ai.image (since 5.25), Vizum.ai.managedModels, Vizum.ai.models, Vizum.ai.ragMigrate, Vizum.ai.rerank, Vizum.ai.setAllowedModels, Vizum.ai.setDefaultModel, Vizum.ai.setInstanceSettings, Vizum.ai.storeAccount, Vizum.ai.tools, Vizum.ai.usageByApp, Vizum.ai.usageByUser, Vizum.ai.usageHasRefs

Bridge ops: account, appPermissions, billing, byokFallback, byokSet, byokStatus, chat, complete, embed, getInstanceSettings, image, managedModels, models, ragMigrate, rerank, setAllowedModels, setDefaultModel, setInstanceSettings, storeAccount, usageByApp, usageByUser, usageHasRefs

• account(): Promise<{ mode: string; account_type: string; balance: number; currency: string; trial: { active: boolean; remaining: number; expiry: string | null }; subscription_state: string; subscription_cancel_at?: string | null; data_purge_at?: string | null… — SDK v5.8 admin surface — base.group_system only; others get AccessError.
• appPermissions(payload: { keys: string[] }): Promise<{ rows: Array<{ key: string; name: string; data: string; logic: string | null; ai: boolean; ai_image: boolean; vector: string | null; orm: Array<{ model: string; ops: string[]; write_fields: string[] | null… — Admin only.
• billing(payload: { op: "topup" | "subscribe" | "portal" | "plans"; amount?: number; plan_id?: number }): Promise<{ url?: string; id?: string; plans?: any[] }> — SDK v5.8 admin surface — create or fetch a Stripe Checkout / portal / plans session.
• byokFallback(payload: { value: boolean }): Promise<{ ok: boolean }>
• byokSet(payload: { provider: string; key: string }): Promise<{ ok: boolean }>
• byokStatus(): Promise<{ providers: Array<{ provider: string; has_key: boolean }>; ai_byok_fallback: boolean }> — SDK v5.15 admin — read whether this instance BYOKs (bring your own key) to the Vizum store, per provider (booleans only — the key is never returned).
• chat(payload: { messages?: AiMessage[]; prompt?: string; system?: string; model?: string; max_tokens?: number; temperature?: number; tools?: any[]; /** Extended reasoning budget. Today only the anthropic branch * ('_apply_effort') applies it: raises 'max_toke…
• complete(prompt: string, opts?: { model?: string; system?: string; max_tokens?: number; temperature?: number }): Promise<string>
• embed(input: string | string[], opts?: { model?: string }): Promise<{ vectors: number[][]; model: string }>
• getInstanceSettings(): Promise<VizumAiInstanceSettings> — SDK v5.14 admin surface — instance-wide AI parameters.
• image(payload: { prompt: string; n?: number; size?: string } ): Promise<{ images: string[]; model: string | null; mime: string }> — SDK 5.25 — image GENERATION.
• managedModels(): Promise<{ models: Array<{ id: string; provider: string; model: string; label: string; enabled: boolean }>; all_enabled: boolean; default_model_id: string | null; mode: string; editable: boolean }> — SDK v5.9 admin surface — managed-MODEL selection: the models the owner offers this instance + which are enabled.
• models(): Promise<Array<{ id: string; label: string; provider: string }>>
• ragMigrate(opts?: { dryRun?: boolean }): Promise<{ migrated: number; skipped: Record<string, number>; namespaces: string[] }> — SDK v5.15 admin — local → managed RAG migration.
• rerank(query: string, documents: string[], opts?: { topN?: number; model?: string } ): Promise<{ results: Array<{ index: number; score: number }>; model: string | null }> — SDK v5 listwise reranker (provider-agnostic — runs on the chat model, no Cohere/Jina key).
• setAllowedModels(payload: { model_ids: string[] }): Promise<{ models: Array<{ id: string; provider: string; model: string; label: string; enabled: boolean }>; all_enabled: boolean; default_model_id: string | null; mode: string; editable: boolean }> — Admin: enable a subset of the owner's offered models (clamped to the owner ceiling).
• setDefaultModel(payload: { model_id: string | number }): Promise<{ models: Array<{ id: string; provider: string; model: string; label: string; enabled: boolean }>; all_enabled: boolean; default_model_id: string | null; mode: string; editable: boolean }> — SDK v5.13 admin — the default CHAT model for no-model managed calls (e.g.
• setInstanceSettings(payload: Partial<Pick<VizumAiInstanceSettings, "assistantMaxTokens" | "assistantTimeBudget" | "generalMaxTokens">>): Promise<VizumAiInstanceSettings> — SDK v5.14 — persist any subset of the instance AI parameters (clamped server-side) and return the fresh snapshot.
• storeAccount(payload: { op: "status" } | { op: "logout" } | { op: "login"; email: string; password: string } | { op: "signup"; name: string; email: string; password: string } ): Promise<{ linked: boolean; email?: string; name?: string; can_buy?: boolean; offl… — SDK v5.22 — link / unlink / inspect the Vizum store account from inside the app.
• tools: { handle(name: string, handler: (values: Record<string, any>) => any): void; } — SDK v5.3 — AI TOOLS: let the AI Assistant DRIVE your app.
• usageByApp(payload?: { days?: number }): Promise<{ rows: Array<{ app_id: number | null; key: string | null; name: string; calls: number; tokens_in: number; tokens_out: number; charge: number; /** Prompt caching, aggregated: 'cache_hit_ratio' = cache_read / to… — refs is the app's own Vizum.ai.chat({..., ref}) breakdown — empty when the app never tags a call.
• usageByUser(): Promise<{ rows: Array<{ user_id: number | null; name: string; login: string | null; spend: number; calls: number; tool_calls: number; by_kind: Array<{ kind: string; charge: number; calls: number }> }> }> — SDK v5.8 admin surface — per-user spend + call rollup.
• usageHasRefs(payload?: { days?: number }): Promise<{ available: boolean }> — Admin: cheap yes/no — does any app tag its spend with ref (no 90-day fold)?

apps

stability stable · permission: none (open targets checked against permissions.apps)

Members: Vizum.apps.find, Vizum.apps.health (since 5.67), Vizum.apps.installed, Vizum.apps.open, Vizum.apps.provides, Vizum.apps.requires, Vizum.apps.status (since 5.67)

Bridge ops: find, health, installed, open, provides, requires, status

• find(contract: string): Promise<Array<{ key: string; name: string; version: string; ready: boolean; provides: string[] }>>
• health(): Promise<{ status: "healthy" | "degraded" | "failing"; lifecycle: "running" | "blocked" | "pending_approval" | "disabled" | "withdrawn"; /** 5.97 — 'policy': the platform's rules tightened after this version was installed */ checks: Array<{ name: "st… — 5.67 — how this app is doing: approval state, dependencies, its own runtime errors and failed background tasks over the last 24 h.
• installed(): Promise<Array<{ key: string; name: string; version: string; ready: boolean; provides: string[] }>>
• open(key: string, payload?: any): Promise<boolean>
• provides(): Promise<string[]>
• requires(): Promise<Array<Vizum.DependencyRow & { key: string; installed: boolean; ready: boolean }>>
• status(): Promise<{ state: "ok" | "degraded" | "blocked"; dependencies: Vizum.DependencyRow[] }> — 5.67 — whether everything this app requires is ready.

ar

stability stable · since 5.151 · hosts: desktop, native, solo · permission: permissions.media ['camera']

Members: Vizum.ar.on, Vizum.ar.overlay, Vizum.ar.setFov (since 5.155), Vizum.ar.start, Vizum.ar.status, Vizum.ar.stop

Bridge ops: overlay, setFov, start, status, stop

• on(name: "state", cb: (e: { state: "started" | "stopped" | "denied" | "unsupported" | "error"; engine?: string; reason?: string }) => void): Vizum.Subscription
• overlay(cards: Record<string, Vizum.ArCard | null>, options?: { replace?: boolean }): Promise<{ ok: true; count: number; refused?: number; invalid?: number } | { ok: false; reason: "not_running" }> — Set the cards: { [codeValue]: Card | null } (null removes).
• setFov(opts: { h: number }): Promise<{ ok: true; h: number } | { ok: false; reason: "invalid" }> — SDK 5.155: your own estimate of the HORIZONTAL field of view in degrees (20..140), kept for the window's session; the next frame events carry it with fov.source: "estimated".
• start(opts?: Vizum.ArStartOptions): Promise<{ ok: true; engine: "native" | "wasm" } | { ok: false; reason: "denied" | "unsupported" | "busy" | "stopped"; detail?: string }> — Open the view.
• status(): Promise<{ running: boolean; engine?: "native" | "wasm"; visible: string[]; layer?: "app"; dropped?: number }>
• stop(): Promise<{ ok: true }> — Close the view and release the camera.

assistant

stability stable · permission: permissions.assistant

Members: Vizum.assistant.cancel, Vizum.assistant.confirm, Vizum.assistant.contexts, Vizum.assistant.delete, Vizum.assistant.deleteProject, Vizum.assistant.history, Vizum.assistant.kbInfo, Vizum.assistant.kbSearch (since 5.52), Vizum.assistant.models, Vizum.assistant.newSession, Vizum.assistant.projects, Vizum.assistant.rate, Vizum.assistant.reject, Vizum.assistant.rename, Vizum.assistant.saveProject, Vizum.assistant.send, Vizum.assistant.sessions, Vizum.assistant.setContext, Vizum.assistant.setEffort, Vizum.assistant.setModel, Vizum.assistant.setSessionProject, Vizum.assistant.sourceDoc, Vizum.assistant.thumb, Vizum.assistant.upload

Bridge ops: cancel, confirm, contexts, delete, deleteProject, history, kbInfo, kbSearch, models, newSession, projects, rate, reject, rename, saveProject, send, sessions, setContext, setEffort, setModel, setSessionProject, sourceDoc, thumb, upload

• cancel(sessionId: number): Promise<{ ok: boolean }> — Ask the in-flight turn on this session to abort at its next step.
• confirm(sessionId: number, actionId: number): Promise<Record<string, any>>
• contexts(): Promise<{ available: Array<{ id: number; name: string; industry?: string; section?: string; summary?: string }>; current: number; current_name?: string; locals: Array<{ name: string }> }> — The user's available pre-contextualizations (personas) + their current pick + the applicable LOCAL contexts.
• delete(sessionId: number): Promise<{ ok: boolean }>
• deleteProject(id: number): Promise<{ ok: boolean }>
• history(sessionId: number): Promise<Array<Record<string, any>>>
• kbInfo(): Promise<{ docs: number; namespaces: string[]; names: string[]; tags: string[]; categories: string[] }> — SDK 5.19 — a CHEAP snapshot of the user's Knowledge Base (no LLM): how many documents are actually indexed, the namespaces, and the tag/category vocab.
• kbSearch(query: string, opts?: { catalogs?: string[]; topK?: number }): Promise<{ ok: boolean; catalogs?: string[]; note?: string; error?: { code: string; message?: string }; passages?: Array<{ source: string; text: string; score: number; kind?: string; categ… — SDK 5.52 — passages from the Knowledge (RAG) catalogs THIS user can read, with their sources: the Assistant's own retrieval (hybrid search, rerank), run as the calling user.
• models(): Promise<{ configured: boolean; models: Array<{ id: string; provider: string; model: string; label: string; vision: boolean }>; chosen: string | false }>
• newSession(title?: string, projectId?: number): Promise<{ id: number }>
• projects(): Promise<Array<{ id: number; name: string; persona_id: number; persona_name: string; instructions: string; session_count: number }>> — Per-user chat folders, each with an attached persona.
• rate(sessionId: number, messageId: number | string, rating: "up" | "down"): Promise<{ ok: boolean; message_id?: number; rating?: "up" | "down" }> — SDK 5.19 (active learning, still evolving) — thumbs up/down on ONE assistant message (its id comes from history()/send()'s message_id — a numeric Odoo id, a numeric string also works, the server coerces with int()).
• reject(sessionId: number, actionId: number): Promise<Record<string, any>>
• rename(sessionId: number, title: string): Promise<{ ok: boolean }>
• saveProject(vals: { id?: number; name: string; persona_id?: number; instructions?: string; sequence?: number; active?: boolean }): Promise<Record<string, any>> — Create/update a project.
• send(sessionId: number, text: string, opts?: { /** Multimodal input (SDK v5.11) — attachments from upload(). */ attachments?: Array<{ id: string; route?: string }>; /** SDK v5.19 — the editor document the user is viewing (live-edit awareness). */ active_doc?:…
• sessions(): Promise<Array<Record<string, any>>>
• setContext(id?: number): Promise<{ ok: boolean; context_id: number }> — Pick one of YOUR allowed global contexts (or 0/null to clear).
• setEffort(effort?: "auto" | AiEffort): Promise<{ ok: boolean; effort: string }> — Pick your reasoning EFFORT (extended thinking for Claude & thinking-capable models).
• setModel(model?: string): Promise<{ ok: boolean; model: string }> — Pick the model for YOUR chats (one of your allowed models; ""/null = automatic).
• setSessionProject(sessionId: number, projectId?: number): Promise<{ ok: boolean; project_id: number | false }> — Move a chat into a project (0/null = out of any project).
• sourceDoc(namespace: string, docId: string): Promise<{ ok: boolean; doc?: { doc_id: string; name: string; content_type: string; size: number; data: string } }> — SDK v5.2 — fetch a cited Knowledge SOURCE document for in-chat preview.
• thumb(attachmentId: string): Promise<{ ok: boolean; mime?: string; name?: string; data?: string | null }> — A small image preview for an uploaded attachment (history re-render).
• upload(sessionId: number, data: string, name?: string, mime?: string): Promise<{ attachment_id: string; mime: string; name: string; size: number; session_id: number }> — SDK v5.11 — store an uploaded file (base64) as a session-scoped attachment; keeps bytes OUT of the chat text.

audio

stability stable · since 5.5 · permission: recordClip/recordStop/micLevel: permissions.media ['microphone']; transcribe/status: permissions.audio

Members: Vizum.audio.micLevel, Vizum.audio.recordClip (since 5.10), Vizum.audio.recordStop, Vizum.audio.status, Vizum.audio.transcribe, Vizum.audio.transcribeBatch

Bridge ops: micLevel, recordClip, recordStop, status, transcribe

• micLevel(): Promise<{ level: number; ready: boolean }> — Instantaneous RMS mic level (0..~1) — for a live meter / dead-mic detection.
• recordClip(ms: number | { ms?: number }): Promise<{ b64: string; mime: string; size: number }> — Record ~ms of audio from the mic in-browser -> a clip.
• recordStop(): Promise<{ ok: boolean }> — Release the microphone acquired by recordClip().
• status(): Promise<{ mode: "local" | "managed"; provider: string; available: boolean; credits_per_min?: number | null }> — Which engine is live + a cost hint.
• transcribe(input: File | Blob | string | { data: string; content_type?: string } | { namespace: string; doc_id: string }, opts?: { mode?: "local" | "managed"; language?: string; translate?: boolean; model?: string; onProgress?: (p: { stage?: string; duration?… — input: a File | Blob | base64 string | {data,content_type} | {namespace,doc_id}.
• transcribeBatch(inputs: Array<File | Blob | string>, opts?: { mode?: "local" | "managed"; language?: string; translate?: boolean; model?: string; onProgress?: (p: { item: number; total: number }) => void } ): Promise<{ results: Array<Vizum.AudioResult | { err… — Batch transcribe; per-item progress via opts.onProgress.

audit

stability stable · permission: none (app-scoped); activity: permissions.audit server-side

Members: Vizum.audit.activity, Vizum.audit.log, Vizum.audit.search

Bridge ops: activity, log, search

• activity(query?: { model?: string; res_id?: number; action?: "create" | "write" | "unlink"; user_id?: number; source?: "vapp" | "native"; date_from?: string; date_to?: string; limit?: number; offset?: number }): Promise<Array<{ id: number; ts: string; user: [… — SDK v5: the old->new CHANGE trail the platform captures for the app's declared native.audit models.
• log(action: string, payload?: Record<string, any>): Promise<{ id: number; ts: string }>
• search(query?: { action?: string; user_id?: number; ok?: boolean; date_from?: string; date_to?: string; limit?: number; offset?: number }): Promise<Array<{ id: number; ts: string; user: [number, string]; action: string; payload: Record<string, any>; ok: boole…

backend

stability stable · permission: permissions.actions (non-empty)

Members: Vizum.backend.approve, Vizum.backend.cancel, Vizum.backend.enqueue, Vizum.backend.list, Vizum.backend.progress, Vizum.backend.status

Bridge ops: approve, cancel, enqueue, get, list, progress

• approve(id: number | string): Promise<any>
• cancel(id: number | string): Promise<any>
• enqueue(action: string, params?: Record<string, any>, opts?: Vizum.Idempotent): Promise<{ id: number | string; [k: string]: any }> — SDK 5.67 idempotencyKey: one task per key, however often it is retried.
• list(q?: Record<string, any>): Promise<Vizum.BackendTask[]>
• progress(id: number | string, vals?: { done?: number; total?: number; cursor?: any; /** Report a percentage directly when 'total' isn't known/tracked this call — * used ONLY when 'total' is absent; 'done'/'total' take priority when both are * given. */ progre… — A RUNNING action reports {done,total,cursor?} between batches for a live progress bar + resumable cursor, and gets back {cancel_requested} so it can stop cleanly on a cooperative cancel().
• status(id: number | string): Promise<Vizum.BackendTask>

bulk

stability stable · since 5.90 · hosts: desktop, native, solo · permission: permissions.orm (search + read on the model, as the calling user); rebuild also permissions.logic "script"

Members: Vizum.bulk.cancel (since 5.90), Vizum.bulk.export (since 5.90), Vizum.bulk.list (since 5.90), Vizum.bulk.rebuild (since 5.90), Vizum.bulk.status (since 5.90)

Bridge ops: cancel, export, list, rebuild, status

• cancel(id: number): Promise<Vizum.BulkJob> — A queued job is cancelled at once; a running one stops at its next chunk.
• export(model: string, spec: { fields: string[]; domain?: unknown[]; format?: "csv" | "jsonl"; name?: string }): Promise<Vizum.BulkJob>
• list(): Promise<Vizum.BulkJob[]>
• rebuild(model: string, spec: { fields: string[]; domain?: unknown[]; hook: string; params?: Record<string, unknown> }): Promise<Vizum.BulkJob> — Needs permissions.logic "script": hook receives {rows, chunk, last, job: {id, params}}.
• status(id: number): Promise<Vizum.BulkJob>

cutover

stability stable · permission: permissions.cutover (+ administrator)

Members: Vizum.cutover.adopt, Vizum.cutover.release

Bridge ops: adopt, release

• adopt(p?: { app_key?: string; source_db?: string; version?: string; [k: string]: any }): Promise<any>
• release(p?: { app_key?: string; source_db?: string; version?: string; [k: string]: any }): Promise<any>

data

stability stable · permission: none (scope from permissions.data)

Members: Vizum.data.collection, Vizum.data.del, Vizum.data.get, Vizum.data.list, Vizum.data.set, Vizum.data.subscribe

Bridge ops: collection, del, get, list, set, subscribe

• collection<T = any>(name: string): Vizum.Collection<T>
• del(k: string): Promise<boolean>
• get(k: string): Promise<any>
• list(): Promise<string[]>
• set(k: string, v: any): Promise<boolean>
• subscribe(k: string, cb: () => void): Promise<boolean>

db

stability stable · permission: permissions.tables; meta_tables/meta_fields/query_app: permissions.db_cross_read; owner_query: row ACL

Members: Vizum.db.count, Vizum.db.delete, Vizum.db.get, Vizum.db.insert, Vizum.db.insertMany, Vizum.db.insert_many, Vizum.db.meta, Vizum.db.ownerQuery, Vizum.db.queryApp, Vizum.db.search, Vizum.db.share, Vizum.db.update

Bridge ops: count, delete, get, insert, insert_many, meta_fields, meta_tables, owner_query, query_app, search, share, update

• count(table: string, domain?: any[][]): Promise<number>
• delete(table: string, id: string): Promise<boolean>
• get(table: string, id: string): Promise<Record<string, any> | null>
• insert(table: string, values: Record<string, any>): Promise<Record<string, any>>
• insertMany(table: string, rows: Array<Record<string, any>>): Promise<Array<Record<string, any>>> — Bulk insert in one round-trip; returns the created rows (with ids).
• insert_many(table: string, rows: Array<Record<string, any>>): Promise<Array<Record<string, any>>>
• meta: { tables(): Promise<Array<Record<string, any>>>; fields(appKey: string, table: string): Promise<Array<Record<string, any>>>; } — Cross-app Vizum.db read (Phase 4) — PRIVILEGED, READ-ONLY, ACL-bounded.
• ownerQuery(table: string, rowId: string, widgetId: string): Promise<any[]> — Run-as-owner render of a SHARED row's owner-persisted widget query.
• queryApp(appKey: string, table: string, spec?: Record<string, any>): Promise<any>
• search(table: string, domain?: any[][], opts?: { order?: string; limit?: number; offset?: number; scope?: "mine" | "shared" }): Promise<Array<Record<string, any>>>
• share(table: string, id: string, opts: { users?: Array<number | "job_user">; visibility?: "private" | "shared" | "public" }): Promise<any> — 5.41: users may include "job_user" — the identity this app's jobs run as, resolved server-side (never the superuser, an archived or a portal user).
• update(table: string, id: string, values: Record<string, any>, opts?: { expect?: Record<string, any> }): Promise<Record<string, any> & { _updated?: boolean }> — 5.39: opts.expect = compare-and-set — written only if the row still holds those values (row lock); the result then carries _updated: true | false.

dev

stability stable · client-side only (no bridge op)

Members: Vizum.dev.logs

• logs(q?: Record<string, any>): Promise<any[]>

device

stability stable · hosts: device · permission: an auth "device" page (native.routes); print, printReceipt and printTest also need device.print: true on that page's route

Members: Vizum.device.blobUrl (since 5.70), Vizum.device.cache (since 5.70), Vizum.device.call (since 5.70), Vizum.device.embed (since 5.70), Vizum.device.embeds (since 5.70), Vizum.device.fileUrls (since 5.70), Vizum.device.fullscreen (since 5.70), Vizum.device.info (since 5.70), Vizum.device.onReload (since 5.70), Vizum.device.print (since 5.87), Vizum.device.printReceipt (since 5.87), Vizum.device.printTest (since 5.88), Vizum.device.store (since 5.82)

Bridge ops: blobUrl, cache, call, embed, embedMute, embedPause, embedPlay, embedRemove, embedSetVolume, embedUnmute, embedUpdate, embeds, fileUrls, fullscreen, info, onReload, print, printReceipt, printTest, storeAll, storeDelete, storeGet, storeSet

• blobUrl(url: string): Promise<string | null> — An object URL for url, served from the offline cache when the network is gone.
• cache(urls: string[]): Promise<{ cached: number; bytes: number }> — Pre-fetch URLs into the offline cache (LRU, the page's device.cache_mb).
• call(route: string, payload?: Record<string, any>): Promise<any> — Run the app's device json route route (its hook sees V.device).
• embed(opts: Vizum.DeviceEmbedOptions): Promise<Vizum.DeviceEmbedHandle> — A YouTube / Vimeo player laid over this app by the platform page (a player nested in the sandboxed app frame does not play).
• embeds(): Promise<number> — Remove every player this app opened; resolves with how many.
• fileUrls(route: string, ids: number[]): Promise<Record<string, string>> — Signed URLs (24 h) for records of the device file route route, keyed by id.
• fullscreen(): Promise<boolean> — Ask the platform page to go fullscreen.
• info(): Promise<Vizum.DeviceInfo> — This device: id, name, the record it is linked to, the page it was paired on.
• onReload(cb: () => void): () => void — The administrator pressed "Reload screen".
• print(): Promise<true> — SDK 5.87 (Vizum.supports("device-print"), route device.print: true) — the supported window.print() of a device page: same grant and rate limit, then this frame prints its own view (style it with @media print).
• printReceipt(doc: Vizum.ReceiptLine[] | { lines: Vizum.ReceiptLine[] }, opts?: { cut?: boolean; feed?: number; columns?: number }): Promise<true> — SDK 5.87 (Vizum.supports("device-receipt"), route device.print: true, min_platform 5.87) — print a receipt on the ESC/POS printer a person paired at this screen.
• printTest(): Promise<true> — SDK 5.88 (Vizum.supports("device-receipt-test"), route device.print: true, min_platform 5.88) — print the platform's fixed test receipt (logo, printer name, paper width, time, a ruler as wide as the paper) on the pa…
• store: Vizum.DeviceStore — SDK 5.82 — per-device key/value storage (the app frame has no localStorage).

deviceBroker

stability stable · since 5.129 · hosts: desktop, native · permission: permissions.device_broker (a privileged boolean, install_scope admin, min_platform 5.129). Administrators only; each mutating call is confirmed on the host

Members: Vizum.deviceBroker.claim (since 5.129), Vizum.deviceBroker.link (since 5.129), Vizum.deviceBroker.list (since 5.129), Vizum.deviceBroker.rearm (since 5.129), Vizum.deviceBroker.rename (since 5.129), Vizum.deviceBroker.unlink (since 5.129)

Bridge ops: claim, link, list, rearm, rename, unlink

• claim(o: { device_id: string; code: string; name?: string; link?: number | null }): Promise<Vizum.BrokerDevice>
• link(id: number, recordId: number | null): Promise<Vizum.BrokerDevice>
• list(): Promise<Vizum.BrokerDevice[]>
• rearm(id: number): Promise<Vizum.BrokerDevice> — A lost response: a new enrolment code; the previous one dies.
• rename(id: number, name: string): Promise<Vizum.BrokerDevice>
• unlink(id: number): Promise<Vizum.BrokerDevice> — The device's token is cut first, then the store is told (queued if it is unreachable).

devices

stability stable · permission: permissions.devices: print | scan | location

Members: Vizum.devices.bluetoothSupported (since 5.134), Vizum.devices.location (since 5.24), Vizum.devices.onScan, Vizum.devices.print, Vizum.devices.printReceipt, Vizum.devices.readTag, Vizum.devices.scan, Vizum.devices.serialSupported

Bridge ops: location, onScan, print, printReceipt, readTag, scan

• bluetoothSupported(): boolean — SDK 5.134 — whether Web Bluetooth (the standard navigator.bluetooth) works in this app's frame: the host delegated it (declare permissions.devices ["bluetooth"] and min_platform 5.134) AND the browser has it.
• location(opts?: { timeout?: number; maximumAge?: number; highAccuracy?: boolean }): Promise<{ lat: number; lng: number; accuracy: number; ts: number }> — SDK 5.24 (grant devices:["location"]) — one-shot GPS fix, HOST-mediated (geolocation is auto-denied in the opaque-origin iframe).
• onScan(cb: (scan: { type: "nfc" | "rfid"; value: string }) => void): Promise<boolean> — NFC taps + RFID/barcode reader scans captured by the desktop (grant devices:["scan"]).
• print(title: string, lines: string[]): Promise<boolean> — Host-rendered text printing (scriptless).
• printReceipt(lines: Array<string | { text: string; align?: "left" | "center" | "right"; bold?: boolean; size?: "normal" | "double"; underline?: boolean }>, opts?: { cut?: boolean; [k: string]: any }): Promise<boolean> — Send an ESC/POS receipt to the user's default paired printer (grant devices:["print"]).
• readTag(opts?: { timeout?: number }): Promise<{ ok: boolean; type?: "nfc" | "rfid"; value?: string; cancelled?: boolean; degraded?: boolean }> — One-shot ACTIVE NFC/RFID read — "read a tag now", the active twin of onScan (grant devices:["scan"], no new token).
• scan(opts?: Record<string, any>): Promise<{ ok: boolean; text?: string; format?: string; cancelled?: boolean }> — One-shot barcode/QR scan on the native host — the phone camera, or the hardware laser on a rugged PDA (grant devices:["scan"], same grant as onScan/readTag).
• serialSupported(): boolean — Whether navigator.serial is available (declare permissions.devices ["serial"]).

docs

stability stable · client-side only (no bridge op)

Members: Vizum.docs.del, Vizum.docs.get, Vizum.docs.list, Vizum.docs.put

• del(namespace: string, sel: { doc_id?: string } | { all: true }): Promise<{ deleted: number }> — Delete by id or all in the namespace.
• get(namespace: string, docId: string): Promise<{ doc_id: string; name: string; content_type: string; size: number; data: string } | null> — Fetch one document (with its base64 data), or null.
• list(namespace?: string): Promise<Array<{ doc_id: string; name: string; namespace: string; content_type: string; size: number; at: string }>> — List stored documents (metadata only — no bytes).
• put(namespace: string, doc: { doc_id: string; name?: string; content_type?: string; data: string }): Promise<{ doc_id: string; size: number }> — Store/replace a source document.

domain

stability stable · client-side only (no bridge op)

Members: Vizum.domain.compile, Vizum.domain.mount, Vizum.domain.open, Vizum.domain.parse, Vizum.domain.summarize

• compile(ast: any): Promise<Vizum.Domain> — Pure helper: AST -> Odoo domain array.
• mount(elOrId: HTMLElement | string, opts: DomainBuilderOpts): Promise<DomainController> — Mount an inline builder into a container (element or element id).
• open(opts: DomainBuilderOpts): Promise<Vizum.Domain | null> — Open a modal builder; resolves to a domain array, or null if cancelled.
• parse(domain: Vizum.Domain | string): Promise<any> — Pure helper: Odoo domain (array or string) -> editable AST.
• summarize(domain: Vizum.Domain | string, opts?: { model?: string; fields?: DomainField[] }): Promise<string> — Human-readable one-liner for a domain (filter chips / previews).

editable

stability stable · since 5.19 · permission: permissions.editable

Members: Vizum.editable.active, Vizum.editable.apply, Vizum.editable.clear, Vizum.editable.onApply, Vizum.editable.publish

Bridge ops: active, apply, clear, publish

• active(): Promise<{ app_key: string; doc_id: string; title?: string; snapshot: string; tools: Array<{ op: string; args?: any; desc?: string }> } | null>
• apply(appKey: string, docId: string, ops: any[]): Promise<{ ok: boolean }>
• clear(): Promise<{ ok: boolean }>
• onApply(cb: (ops: any[], docId: string) => void): () => void
• publish(reg: { doc_id: string; title?: string; snapshot: string; tools?: Array<{ op: string; args?: any; desc?: string }> }): Promise<{ ok: boolean }>

errors

stability stable · client-side only (no bridge op)

Members: Vizum.errors.capture, Vizum.errors.catalog (since 5.67), Vizum.errors.is (since 5.67), Vizum.errors.normalize (since 5.67), Vizum.errors.retry (since 5.67)

• readonly _count: number — Internal rate-limit counter (capped at 20 per session) — read-only, not something a vApp should set.
• capture(err: any, ctx?: Record<string, any>): Promise<boolean>
• catalog(): Record<Vizum.ErrorCode, { category: Vizum.ErrorCategory; retryable: boolean; legacy: string[]; server: string[] }> — SDK 5.67 — the error catalogue this SDK was built with.
• is(err: unknown, codeOrCategory: Vizum.ErrorCode | Vizum.ErrorCategory): boolean — SDK 5.67 — is(err, "CONFLICT") or is(err, "network"): a code or a category.
• normalize(err: unknown): Vizum.VizumError — SDK 5.67 — any failure (a rejected call, an Error, a string, a resolved {ok: false, error} value) as a VizumError.
• retry<T>(fn: (attempt: number) => Promise<T>, opts?: { retries?: number; baseMs?: number; maxMs?: number }): Promise<T> — SDK 5.67 — retry fn while it fails with a retryable error, with exponential backoff (defaults: retries 3, baseMs 250, maxMs 4000); any other error rejects at once.

events

stability stable · permission: permissions.events.emit / .listen (built-in host events need none)

Members: Vizum.events.catalog (since 5.67), Vizum.events.emit, Vizum.events.on

Bridge ops: catalog, emit:<name>, listen:<name>

• catalog(): Promise<Array<{ name: string; version: number; description: string; schema: Record<string, unknown>; producer: string }>> — 5.67 — the event contracts installed apps declare.
• emit(name: string, payload?: any): Promise<boolean> — Rejects with VALIDATION_FAILED (5.67) when the payload does not match the event's contract in this app's manifest event_contracts.
• on(name: string, cb: (payload: any, meta: Vizum.EventMeta | null) => void): Promise<boolean> — meta (5.67): who emitted the event and the contract version it follows; null for host events and events without a contract's producer.

feeds

stability stable · since 5.89 · hosts: desktop, native, solo · permission: permissions.feeds (privileged; base.group_system for every method)

Members: Vizum.feeds.define (since 5.89), Vizum.feeds.list (since 5.89), Vizum.feeds.remove (since 5.89), Vizum.feeds.revoke (since 5.89), Vizum.feeds.rotateKey (since 5.89)

Bridge ops: define, list, remove, revoke, rotateKey

• define(name: string, spec: { model: string; fields: string[]; domain?: unknown[]; label?: string }): Promise<Vizum.DataFeed & { cost: Vizum.DataFeedCost }> — Create or update a feed: one model, scalar and many2one columns, a domain.
• list(): Promise<Vizum.DataFeed[]>
• remove(name: string): Promise<true> — Delete the feed and its key.
• revoke(name: string): Promise<Vizum.DataFeed> — Kill the feed's key (the definition stays).
• rotateKey(name: string): Promise<Vizum.DataFeed & { secret: string }> — Issue a NEW key, returned ONCE as secret; the previous key dies at once.

files

stability stable · permission: none (app-scoped); publicUrl/revokePublic: permissions.files_public

Members: Vizum.files.del, Vizum.files.download, Vizum.files.get, Vizum.files.getBlob (since 5.71), Vizum.files.getRange (since 5.71), Vizum.files.list, Vizum.files.publicUrl (since 5.27), Vizum.files.put, Vizum.files.putBlob (since 5.70), Vizum.files.revokePublic (since 5.27)

Bridge ops: del, download, get, getBlob, getRange, list, publicUrl, put, putBlob, revokePublic

• del(name: string): Promise<boolean>
• download(filename: string, data: Blob | ArrayBuffer | Uint8Array | string, contentType?: string): Promise<boolean> — Save a file to the user's disk.
• get(name: string): Promise<{ name: string; b64: string; mimetype: string; size: number; sha256?: string }>
• getBlob(name: string): Promise<Blob> — SDK 5.71 — the stored file as a Blob, streamed (no base64).
• getRange(name: string, offset: number, length: number): Promise<Uint8Array> — SDK 5.71 — length bytes (at most 32 MB) from offset.
• list(): Promise<Array<{ name: string; size: number; mimetype: string; sha256?: string | null }>> — sha256 is null for a file stored before 5.67 until it is next read.
• publicUrl(name: string, opts?: { expires_in?: number }): Promise<{ name: string; url: string; size: number; mimetype: string; expires_at?: string }> — 5.67: the link expires — opts.expires_in seconds, 60 ..
• put(name: string, b64: string, opts?: { sha256?: string }): Promise<{ name: string; size: number; mimetype?: string; sha256?: string }> — 5.67: the bytes must be what the name says (a .png that is not an image is refused, VALIDATION_FAILED); opts.sha256 — the checksum the app computed — refuses a file damaged on the way.
• putBlob(name: string, blob: Blob, opts?: { sha256?: string; onProgress?: (p: { phase: "hash" | "upload"; sent: number; total: number }) => void }): Promise<{ name: string; size: number; mimetype: string; sha256: string }> — SDK 5.70 — a Blob or File streamed by the host (no base64): past 16 MB, up to permissions.file_limits.max_mb (ceiling 200).
• revokePublic(name: string): Promise<boolean> — Invalidate every public link previously minted for this file.

format

stability stable · client-side only (no bridge op)

Members: Vizum.format.date, Vizum.format.datetime, Vizum.format.money, Vizum.format.number

• date(d: Date | string): string
• datetime(d: Date | string): string
• money(n: number | string): string
• number(n: number | string, decimals?: number): string

help

stability stable · client-side only (no bridge op)

Members: Vizum.help.button, Vizum.help.show

• button(title: string, sections: Array<{ h?: string; p?: string; rows?: [string, string][] }>): HTMLButtonElement
• show(title: string, sections: Array<{ h?: string; p?: string; rows?: [string, string][] }>): void

identity

stability stable · since 5.79 · hosts: desktop, native · permission: none (like ui.confirm): the host asks the user for the account password in its own dialog; the password never reaches the app. A vApp that names Vizum.identity sets min_platform 5.79

Members: Vizum.identity.confirm (since 5.79)

Bridge ops: confirm

• confirm(opts: Vizum.ConfirmRequest): Promise<Vizum.ConfirmResult> — Ask the HOST to re-confirm the user.

import

stability stable · client-side only (no bridge op)

Members: Vizum.import.csv, Vizum.import.open, Vizum.import.pick, Vizum.import.xlsx

• csv(text: string): { columns: string[]; rows: Array<Record<string, any>> } — Parse CSV text (auto-detects , ; tab; full quote handling).
• open(opts?: { accept?: string; requiredColumns?: string[] }): Promise<{ columns: string[]; rows: Array<Record<string, any>>; filename: string }> — Picker + parse in one call; validates opts.requiredColumns.
• pick(accept?: string): Promise<File> — Native file picker; resolves with the chosen File (rejects Error("UserDenied")/Error("NoFile")).
• xlsx(arrayBuffer: ArrayBuffer): Promise<{ columns: string[]; rows: Array<Record<string, any>> }> — Parse an .xlsx ArrayBuffer (native ZIP + inflate + sharedStrings reader).

instances

stability stable · since 5.38 · permission: permissions.instances_api

Members: Vizum.instances.pass (since 5.38)

Bridge ops: pass

• pass(): Promise<{ token: string; expiresAt: number }>

jobs

stability stable · permission: none (the app's own manifest jobs)

Members: Vizum.jobs.list, Vizum.jobs.logs, Vizum.jobs.runNow, Vizum.jobs.status

Bridge ops: list, logs, run_now, status

• list(): Promise<any[]>
• logs(name: string): Promise<any[]>
• runNow(name: string): Promise<any>
• status(name: string): Promise<any>

license

stability stable · permission: none

Members: Vizum.license.current, Vizum.license.openUpgrade, Vizum.license.require

Bridge ops: current, openUpgrade

• current(): Promise<{ licensed: boolean; [k: string]: any }>
• openUpgrade(): Promise<boolean>
• require(): Promise<{ licensed: boolean; [k: string]: any }> — Throws Error("LicenseRequired") AND opens the store when unlicensed.

link

stability stable · since 5.104 · hosts: link · permission: an auth "link" page (native.routes, permissions.link_routes); the routes it calls are this app's auth "link" routes

Members: Vizum.link.call (since 5.104), Vizum.link.close (since 5.104), Vizum.link.download (since 5.104), Vizum.link.fileUrl (since 5.104), Vizum.link.info (since 5.104), Vizum.link.upload (since 5.104), Vizum.link.verify (since 5.104)

Bridge ops: call, close, download, fileUrl, info, upload, verify

• call<T = any>(route: string, body?: { [k: string]: any }): Promise<T> — Run the app's link json route route (its hook sees V.link and V.share).
• close(): Promise<true> — End this visit (the guest session); the link stays valid.
• download(route: string, id: number, opts?: { field?: string }): Promise<true> — The page downloads the record's file (this frame cannot).
• fileUrl(route: string, id: number, opts?: { field?: string }): Promise<string> — A 10-minute URL of a link file route's record (for an img or a video).
• info(): Promise<Vizum.ShareInfo> — The share this page serves ({@link Vizum.ShareInfo}, kind: "link").
• upload<T = any>(route: string, file: Blob, opts?: Vizum.LinkUploadOptions): Promise<T> — Send one file to a link upload route; resolves the hook's result.
• verify(code: string): Promise<true> — The 6-digit code the app sent (V.links.issue_code in a hook).

mail

stability stable · permission: permissions.orm (or own native models)

Members: Vizum.mail.log, Vizum.mail.post

Bridge ops: log, post

• log(model: string, id: number, body: string): Promise<{ id: number }>
• post(model: string, id: number, body: string, opts?: { subject?: string }): Promise<{ id: number }>

map

stability stable · permission: permissions.geocode (a privileged boolean; min_platform 5.143). The platform server resolves the query with the provider the administrator chose

Members: Vizum.map.geocode (since 5.143), Vizum.map.tileUrl (since 5.48)

Bridge ops: geocode

• geocode(query: string, opts?: Vizum.GeocodeOptions): Promise<Vizum.GeocodeResult[]> — SDK 5.143 — resolve an address on the PLATFORM server (never a browser network call), with the geocoding provider the administrator chose in Settings › Vizum › Geocoding.
• tileUrl(): string

media

stability stable · permission: permissions.rag or permissions.audio

Members: Vizum.media.cancel, Vizum.media.ingest, Vizum.media.jobs, Vizum.media.result, Vizum.media.runNow, Vizum.media.status, Vizum.media.upload

Bridge ops: cancel, ingest, list, result, run_now, status, upload_chunk, upload_finish, upload_init

• cancel(id: number): Promise<{ ok: boolean }>
• ingest(cfg: { source_type: string; source_ref: string; web_url?: string; name?: string; namespace: string; language?: string; max_minutes?: number; scope_kind?: "user" | "group" | "global"; [k: string]: any }): Promise<{ id: number; state: string }>
• jobs(): Promise<Array<Record<string, any>>>
• result(id: number): Promise<{ transcript?: { text: string; segments: any[] }; [k: string]: any }> — -> the transcript once state === 'done'.
• runNow(id: number): Promise<Record<string, any>>
• status(id: number): Promise<{ state: string; progress?: number; duration_s?: number; chunks_indexed?: number; [k: string]: any }>
• upload(file: File | Blob, cfg?: { name?: string; language?: string; translate?: boolean; max_minutes?: number; doc_id?: string; index_rag?: boolean; namespace?: string; scope_kind?: "user" | "group" | "global"; window_seconds?: number; onProgress?: (p: { phas… — SDK v5.21 — chunked upload of a LOCAL GB file → async server transcription.

meta

stability stable · permission: permissions.orm (or own native models)

Members: Vizum.meta.fieldAccess (since 5.130), Vizum.meta.fields, Vizum.meta.models, Vizum.meta.selection

Bridge ops: fields, models, selection, fieldAccess

• fieldAccess(model: string): Promise<{ model: string; hidden: string[]; no_read: string[]; readonly: string[]; required: string[]; not_exportable: string[]; rev: string }> — 5c — what this user's access restrictions (Access Manager profiles, the manifest's field groups) do to model's fields.
• fields(model: string): Promise<Array<{ name: string; label: string; type: string; required: boolean; readonly: boolean; selection: Array<[string, string]> | null; relation: string | null }>>
• models(): Promise<Array<{ model: string; label: string; ops: string[]; fields: string[] | null }>>
• selection(modelDotField: string): Promise<Array<[string, string]>>

motion

stability stable · since 5.155 · hosts: desktop, native, solo · permission: permissions.sensors ['motion']

Members: Vizum.motion.on, Vizum.motion.start, Vizum.motion.status, Vizum.motion.stop

Bridge ops: start, status, stop

• on(name: "state", cb: (e: { state: "stopped" | "no_events"; reason?: string }) => void): Vizum.Subscription
• start(opts?: { rate?: number }): Promise<{ ok: true; rate: number } | { ok: false; reason: "unsupported" | "insecure_context" | "denied" | "busy" | "stopped" | "hidden" | "background" }> — rate 10..60 Hz.
• status(): Promise<{ running: boolean; rate: number | null } & Vizum.MotionAvailability>
• stop(): Promise<{ ok: true }>

net

stability stable · permission: permissions.net (host allowlist)

Members: Vizum.net.fetch, Vizum.net.fetchImage (since 5.74)

Bridge ops: fetch, fetchImage

• fetch(url: string, opts?: { method?: string; headers?: Record<string, string>; body?: any; timeout?: number }): Promise<{ status: number; ok: boolean; headers: Record<string, string>; binary: boolean; body: string; json?: any }> — Headers / URL / string bodies may carry $secret:name placeholders — substituted server-side, the value never reaches the browser.
• fetchImage(url: string, opts?: { max_bytes?: number; timeout?: number }): Promise<{ content_type: "image/png" | "image/jpeg" | "image/gif" | "image/webp"; size: number; sha256: string; base64: string }> — SDK 5.74 — download ONE image server-side.

notifications

stability stable · permission: none (app + user scoped)

Members: Vizum.notifications.clear, Vizum.notifications.count, Vizum.notifications.create, Vizum.notifications.list, Vizum.notifications.markRead

Bridge ops: clear, count, create, list, mark_read

• clear(): Promise<boolean>
• count(unread?: boolean): Promise<number>
• create(n: { title: string; body?: string; priority?: "low" | "normal" | "high"; user_id?: number; action?: Record<string, any> }): Promise<AppNotification>
• list(query?: { unread?: boolean; limit?: number; offset?: number }): Promise<AppNotification[]>
• markRead(ids: number[], value?: boolean): Promise<boolean>

oauth

stability stable · permission: permissions.oauth

Members: Vizum.oauth.accounts, Vizum.oauth.configure, Vizum.oauth.configured, Vizum.oauth.connect, Vizum.oauth.connected, Vizum.oauth.disconnect, Vizum.oauth.fetch, Vizum.oauth.status

Bridge ops: configure, connect, disconnect, fetch, status

• accounts(provider: string): Promise<Array<{ account_ref: string; name: string; shared: boolean; expired: boolean }>> — SDK 5.26 — the accounts of one provider (see status().accounts).
• configure(provider: string, conf: { client_id: string; client_secret: string; scopes: string; auth_url?: string; token_url?: string; api_base?: string; }): Promise<{ ok: boolean; configured: boolean; unchanged?: boolean }> — Admin-only: store the provider's client_id/secret/scopes in the DB registry.
• configured(provider: string): Promise<boolean> — True once an admin has configured the provider's client_id/secret/scopes.
• connect(provider: string, opts?: { shared?: boolean; related?: string[] } ): Promise<{ provider: string; connected: boolean }> — Host-opened consent popup; resolves when the provider round-trip lands.
• connected(provider: string): Promise<boolean>
• disconnect(provider: string, account?: string | null): Promise<boolean> — account = "" for the caller's own connection, or a page/business id.
• fetch(provider: string, path: string, opts?: { method?: string; headers?: Record<string, string>; body?: any }): Promise<{ status: number; ok: boolean; headers: Record<string, string>; binary: boolean; body: string; json?: any }> — Proxied call to the provider's api_base with the user's token injected.
• status(): Promise<Array<{ provider: string; configured: boolean; connected: boolean; /** SDK 5.26 — the accounts this caller can act as. A brand with five Facebook * pages is FIVE entries, not one boolean. 'expired' = the token lapsed and * cannot be refreshe…

ocr

stability stable · since 5.4 · permission: permissions.ocr

Members: Vizum.ocr.recognize, Vizum.ocr.recognizeBatch, Vizum.ocr.scan, Vizum.ocr.status

Bridge ops: recognize, status

• recognize(input: File | Blob | string | { data: string; content_type?: string } | { namespace: string; doc_id: string }, opts?: { want?: "text" | "blocks" | "tables"; languages?: string[]; mode?: "local" | "managed"; pages?: string; dpi?: number; preprocess?:… — input: a File | Blob | base64 string | {data,content_type} | {namespace,doc_id}.
• recognizeBatch(inputs: Array<File | Blob | string>, opts?: { want?: "text" | "blocks" | "tables"; languages?: string[]; onProgress?: (p: { item: number; total: number }) => void } ): Promise<{ results: Array<Vizum.OcrResult | { error: string }>; pages_total: … — Batch recognise; per-item progress via opts.onProgress.
• scan(opts?: { want?: "text" | "blocks" | "tables"; languages?: string[]; camera?: boolean; mode?: "local" | "managed"; pages?: string; dpi?: number; preprocess?: boolean; model?: string; onProgress?: (p: { page: number; total: number }) => void } ): Promise<V… — Quick capture UI (file, or the device camera with camera: true) → an OcrResult, or null if cancelled.
• status(): Promise<{ mode: "local" | "managed"; provider: string; languages?: string[]; available: boolean; credits_per_page?: number | null }> — Which engine is live + a cost hint.

offline

stability stable · permission: status/pending: none; run/flush: permissions.actions; datasets/sync/query/readGroup/conflicts/resolve: permissions.offline.datasets; create/write: permissions.offline.writes (5.80)

Members: Vizum.offline.conflicts (since 5.80), Vizum.offline.create (since 5.80), Vizum.offline.datasets (since 5.80), Vizum.offline.flush, Vizum.offline.on, Vizum.offline.onAppUpdated (since 5.95), Vizum.offline.onConflict (since 5.80), Vizum.offline.onFlushed, Vizum.offline.onSync (since 5.80), Vizum.offline.pending, Vizum.offline.query (since 5.80), Vizum.offline.readGroup (since 5.80), Vizum.offline.resolve (since 5.80), Vizum.offline.run, Vizum.offline.status, Vizum.offline.sync (since 5.80), Vizum.offline.write (since 5.80)

Bridge ops: conflicts, create, datasets, flush, pending, query, readGroup, resolve, run, status, sync, write

• conflicts(): Promise<Vizum.OfflineConflict[]> — SDK 5.80 — the changes the server refused as a conflict and that wait for a decision.
• create(model: string, vals: Record<string, any>, opts?: Vizum.Idempotent & { expect?: Record<string, any> }): Promise<{ id: string; queued: true; opId: string }> — SDK 5.80 — queue a create (a model in offline.writes with op create).
• datasets(): Promise<Vizum.OfflineDataset[]> — SDK 5.80 — the datasets the manifest's offline.datasets declares, with what the device holds of each.
• flush(): Promise<{ sent: number; failed: Array<{ id: string; error: string }>; remaining: number }>
• on(cb: (s: { online: boolean }) => void): void
• onAppUpdated(cb: (u: { running: string | null; installed: string }) => void): { stop(): void } — SDK 5.95 — the version installed on the server is not the one this page runs (learned when the device reconnects and syncs).
• onConflict(cb: (c: Vizum.OfflineConflict) => void): { stop(): void } — SDK 5.80 — a queued change came back as a conflict.
• onFlushed(cb: (r: { sent: number; remaining: number }) => void): void
• onSync(cb: (r: Vizum.OfflineSyncResult) => void): { stop(): void } — SDK 5.80 — a dataset finished syncing.
• pending(): Promise<Array<{ id: string; action: string; params: object; ts: number }>>
• query(name: string, opts?: Vizum.OfflineQuery): Promise<Vizum.OfflineQueryResult> — SDK 5.80 — read a dataset from the device: domain (= != < <= > >= in not in like ilike =like =ilike, & | !), order, limit, offset, fields.
• readGroup(name: string, opts: Vizum.OfflineReadGroup): Promise<Array<Record<string, any>>> — SDK 5.80 — a read_group over a dataset, on the device: one or two groupby fields (date fields with :day|week|month|quarter|year), aggregates field:count|sum|avg|min|max.
• resolve(id: number, choice: "keep_mine" | "keep_server" | "discard"): Promise<{ resolved: boolean; choice: string }> — SDK 5.80 — settle one: keep_mine sends it again over the server's values, keep_server drops it and shows the server's values, discard drops it.
• run(action: string, params?: { ids?: number[]; [k: string]: any }, opts?: Vizum.Idempotent): Promise<{ ok: boolean; result: any } | { id: string; queued: true }>
• status(): Promise<{ online: boolean }>
• sync(name?: string): Promise<{ datasets: Vizum.OfflineSyncResult[] }> — SDK 5.80 — bring one dataset (or all) up to date now.
• write(model: string, ids: Array<number | string>, vals: Record<string, any>, opts?: Vizum.Idempotent): Promise<{ queued: true; opId: string; opIds: string[] }> — SDK 5.80 — queue a write (a model in offline.writes with op write).

orm

stability stable · permission: permissions.orm (or own native models); per-model ops, fields, domain

Members: Vizum.orm.call, Vizum.orm.callOn, Vizum.orm.create, Vizum.orm.live, Vizum.orm.query, Vizum.orm.read, Vizum.orm.readGroup, Vizum.orm.search, Vizum.orm.searchCount, Vizum.orm.searchRead, Vizum.orm.unlink, Vizum.orm.watch, Vizum.orm.write, Vizum.orm.writeBlob (since 5.70)

• call(model: string, method: string, args?: any[], opts?: { context?: Vizum.OrmContext; ids?: number[] } & Vizum.Idempotent & Vizum.Guarded): Promise<any> — opts.context: see {@link Vizum.OrmContext}.
• callOn(model: string, ids: number[], method: string, args?: any[], opts?: { context?: Vizum.OrmContext } & Vizum.Idempotent & Vizum.Guarded): Promise<any> — opts.context: see {@link Vizum.OrmContext}.
• create(model: string, vals: object, opts?: { context?: Vizum.OrmContext } & Vizum.Idempotent): Promise<number[]> — SDK 5.67 idempotencyKey: a retry with the same key never creates a second record.
• live(renderFn: () => any, opts?: { interval?: number; debounce?: number; models?: string[] }): { refresh(): void; stop(): void } — SDK v5.4 — LIVE DATA the easy way.
• query(model: string): Vizum.Query
• read(model: string, ids: number[], fields?: string[]): Promise<any[]>
• readGroup(model: string, domain: Vizum.Domain, groupby: string[], aggregates: string[], opts?: { limit?: number; offset?: number; order?: string }): Promise<any[]>
• search(model: string, domain?: Vizum.Domain, opts?: object): Promise<number[]>
• searchCount(model: string, domain?: Vizum.Domain): Promise<number>
• searchRead(model: string, domain?: Vizum.Domain, fields?: string[], opts?: object): Promise<any[]>
• unlink(model: string, ids: number[]): Promise<boolean>
• watch(model: string, domain: Vizum.Domain, cb: (h: { count: number; max_write: string | null }) => void, opts?: { interval?: number }): Vizum.Watcher
• write(model: string, ids: number | number[], vals: object, opts?: { expect?: Record<string, unknown>, context?: Vizum.OrmContext }): Promise<boolean | { updated: boolean; current: Record<string, unknown> }> — With opts.expect ({field: value}, SDK 5.43) this is a COMPARE-AND-SET on a NATIVE model: the rows are locked, re-read, and written only if every expected field still holds its value — and it resolves to `{updated, cur…
• writeBlob(model: string, id: number, field: string, blob: Blob): Promise<{ id: number; field: string; size: number; sha256: string }> — SDK 5.70 — stream a file into a binary field of one record (what a device file route plays); checked like write(model, [id], {[field]: base64}).

pairedDevices

stability stable · hosts: desktop, native, solo · permission: native.routes with auth "device" (permissions.device_routes); changes need base.group_system

Members: Vizum.pairedDevices.claim (since 5.70), Vizum.pairedDevices.link (since 5.70), Vizum.pairedDevices.list (since 5.70), Vizum.pairedDevices.reload (since 5.70), Vizum.pairedDevices.rename (since 5.70), Vizum.pairedDevices.revoke (since 5.70)

Bridge ops: claim, link, list, reload, rename, revoke

• claim(pin: string, opts: { name: string; link?: number | null }): Promise<Vizum.PairedDevice> — Claim the PIN a device page shows; the device receives its token on its next poll.
• link(id: number, link: number | null): Promise<Vizum.PairedDevice>
• list(): Promise<Vizum.PairedDevice[]>
• reload(id: number): Promise<Vizum.PairedDevice> — The screen reloads on its next heartbeat.
• rename(id: number, name: string): Promise<Vizum.PairedDevice>
• revoke(id: number): Promise<{ ok: true }> — Unpair: the device's token dies now and the page returns to the PIN screen.

perf

stability stable · permission: none (sessions: administrator)

Members: Vizum.perf.desktop, Vizum.perf.ping, Vizum.perf.sessions

Bridge ops: desktop, ping, sessions

• desktop(): Promise<{ windows: { total: number; open: number; minimized: number; vapps: number; actions: number; byKind: Record<string, number>; activeId: number | null }; memory: { heapMB: number; totalMB: number; limitMB: number; pct: number } | null; fps: n… — This browser tab's live runtime: windows open, JS heap, sampled FPS, desktop state.
• ping(): Promise<{ latencyMs: number; server: { ts: string; uid: number } }> — Round-trip latency (ms) of a cheap server call — a proxy for how busy the Odoo server is (server CPU/RAM are not exposed to apps).
• sessions(): Promise<{ supported: boolean; online_users: number | null; online_mine: number; sessions_total: number | null; sessions_mine: number | null; sessions_note?: string }> — ADMIN only: active-session counts across the instance.

permissions

stability stable · permission: none

Members: Vizum.permissions.explain, Vizum.permissions.raw

Bridge ops: explain, raw

• explain(): Promise<Array<{ capability: string; detail: string; risk: "low" | "medium" | "high" }>>
• raw(): Promise<Record<string, any>>

phone

stability stable · since 5.31 · hosts: desktop · permission: permissions.media ['microphone']

Members: Vizum.phone.answer, Vizum.phone.dial, Vizum.phone.dtmf, Vizum.phone.hangup, Vizum.phone.mute, Vizum.phone.onState, Vizum.phone.register, Vizum.phone.state, Vizum.phone.unregister

Bridge ops: answer, dial, dtmf, hangup, mute, register, state, unregister

• answer(): Promise<any> — Answer what is ringing.
• dial(opts?: Record<string, any>): Promise<any>
• dtmf(digits: string): Promise<any>
• hangup(): Promise<any> — Ends a live call, and REJECTS one that never got answered — a BYE on an unestablished session is ignored and the caller keeps ringing.
• mute(on?: boolean): Promise<any>
• onState(cb: (state: string) => void): () => void — "registered" | "registration" | "ringing" | "dialing" | "answered" | "ended" | "mute" | "audio_blocked" | "transport_down"
• register(ticket?: Record<string, any>): Promise<any>
• state(): Promise<any>
• unregister(): Promise<any>

rag

stability stable · permission: permissions.rag

Members: Vizum.rag.create, Vizum.rag.estimate, Vizum.rag.feedback, Vizum.rag.fields, Vizum.rag.groups, Vizum.rag.indexDoc, Vizum.rag.jobs, Vizum.rag.listChunks, Vizum.rag.models, Vizum.rag.remove, Vizum.rag.runNow, Vizum.rag.update

Bridge ops: create, delete, estimate, feedback, fields, groups, index_doc, list, list_chunks, models, run_now, update

• create(cfg: { name: string; model_name: string; domain?: Vizum.Domain; namespace: string; field_names: string[]; scope_kind?: "user" | "group" | "global"; interval_number?: number; interval_type?: "minutes" | "hours" | "days"; max_per_run?: number; [k: string…
• estimate(cfgOrId: number | Record<string, any>): Promise<{ ok: boolean; pending: number; this_run: number; est_chunks: number; per_record: number; note?: string }> — Estimate a SAVED job (pass its id) or an ad-hoc config object.
• feedback(cfg: { ns?: string; namespace?: string; docIds?: string | string[]; doc_ids?: string | string[]; rating: "good" | "ok" | "bad"; q?: string; question?: string; a?: string; answer?: string }): Promise<{ ok: boolean }> — SDK 5.19 (active learning, still evolving) — rate an answer/its sources good | ok | bad, tagged with the doc_id(s) it was grounded in.
• fields(model: string): Promise<Array<Record<string, any>>> — A model's text+binary fields.
• groups(): Promise<Array<Record<string, any>>> — Admin — groups eligible for shared-scope jobs.
• indexDoc(cfg: { namespace: string; doc_id: string; name?: string; content_type?: string; scope?: string }): Promise<{ ok: boolean; doc_id: string; chunks: number; kinds: { text: number; table: number; image: number } }> — SDK v5.19 — MULTIMODAL index of an already-uploaded document (its bytes stored via Vizum.docs).
• jobs(): Promise<Array<Record<string, any>>>
• listChunks(cfg: Record<string, any>): Promise<Array<Record<string, any>>>
• models(): Promise<Array<Record<string, any>>> — Indexable models.
• remove(id: number): Promise<{ deleted: boolean }>
• runNow(id: number): Promise<Record<string, any>>
• update(cfg: { id: number; [k: string]: any }): Promise<Record<string, any>>

realtime

stability stable · permission: none (app-scoped)

Members: Vizum.realtime.channel

Bridge ops: publish, subscribe, unsubscribe

• channel(name: string): RealtimeChannel

refresh

stability stable · client-side only (no bridge op)

Members: Vizum.refresh.on

• on(cb: () => void, opts?: { interval?: number; debounce?: number; models?: string[] }): { refresh(): void; stop(): void }

reports

stability stable · permission: permissions.reports (per report name)

Members: Vizum.reports.data, Vizum.reports.download, Vizum.reports.html

Bridge ops: data, download, html

• data(reportName: string, ids: number[]): Promise<{ b64: string; size: number }> — SDK v3: the PDF as bytes for re-upload (e.g.
• download(reportName: string, ids: number[], filename?: string): Promise<boolean>
• html(reportName: string, ids: number[]): Promise<{ html: string }> — Report Builder 1.0: a self-contained HTML string (same-origin CSS already inlined, <script> stripped) — for a live preview inside the app; the app iframe cannot fetch /report/html/...

roles

stability stable · permission: none

Members: Vizum.roles.has, Vizum.roles.list, Vizum.roles.mine

Bridge ops: has, list, mine

• has(name: string): Promise<boolean>
• list(): Promise<Array<{ name: string; label: string; active: boolean }>>
• mine(): Promise<string[]>

schedule

stability stable · since 5.128 · hosts: desktop, native · permission: permissions.schedule (a boolean, not privileged; min_platform 5.128). Always the current user's, this app's

Members: Vizum.schedule.ack (since 5.128), Vizum.schedule.clear (since 5.128), Vizum.schedule.list (since 5.128), Vizum.schedule.missed (since 5.128), Vizum.schedule.set (since 5.128)

Bridge ops: ack, clear, list, missed, set

• ack(ids: number[]): Promise<number> — Acknowledge missed occurrences by fire_id; resolves how many were marked.
• clear(id: string): Promise<boolean> — Remove the schedule id; resolves false when there was none.
• list(): Promise<Vizum.Schedule[]> — This app's schedules for the current user (at most 50).
• missed(): Promise<Vizum.ScheduleMissed[]> — Occurrences fired in the last 24 hours that the app has not acknowledged (at most 20, oldest first).
• set(s: Vizum.ScheduleSpec): Promise<Vizum.Schedule> — Create or replace the schedule id.

scope

stability stable · permission: none

Bridge ops: get

script

stability stable · permission: permissions.logic = 'script'

Members: Vizum.script.run

Bridge ops: run

• run(name: string, payload?: Record<string, any>): Promise<any>

secrets

stability stable · permission: permissions.secrets

Members: Vizum.secrets.configure, Vizum.secrets.exists, Vizum.secrets.names

Bridge ops: configure, names

• configure(name: string): Promise<{ name: string; configured: boolean }> — Host-rendered dialog where an ADMIN types the value (rejects Error("UserDenied") on cancel).
• exists(name: string): Promise<boolean>
• names(): Promise<Array<{ name: string; configured: boolean }>> — Every manifest-declared secret + whether an admin configured it.

server

stability stable · since 5.96 · hosts: desktop, native · permission: permissions.server_metrics (privileged; install_scope admin; base.group_system for every method)

Members: Vizum.server.info (since 5.96), Vizum.server.metrics (since 5.96)

Bridge ops: info, metrics

• info(): Promise<Vizum.ServerInfo> — Hosting, scope, worker configuration, retention and which metrics this hosting can read.
• metrics(query: Vizum.ServerMetricsQuery): Promise<Vizum.ServerMetrics> — The series between from and to, one point per step seconds (at most 1,500 points; a longer range is refused with VALIDATION_FAILED naming the smallest step that fits).

sessions

stability stable · permission: permissions.sessions (+ administrator)

Members: Vizum.sessions.getPolicy, Vizum.sessions.revoke, Vizum.sessions.revokeUser, Vizum.sessions.setActivityAudit, Vizum.sessions.setActivityAuditGlobal, Vizum.sessions.setLoginAlerts, Vizum.sessions.setSessionTimeout

Bridge ops: getPolicy, revoke, revokeUser, setActivityAudit, setActivityAuditGlobal, setLoginAlerts, setSessionTimeout

• getPolicy(): Promise<{ login_alerts: boolean; session_timeout: { enabled: boolean; hours: number; min_hours: number }; activity_audit: { enabled: boolean; global: boolean }; supported: boolean }> — Read the session security policy.
• revoke(deviceId: number): Promise<{ revoked: number[] }> — Revoke one session by its res.device id (signs that session out).
• revokeUser(userId: number): Promise<{ revoked: number[] }> — Revoke ALL of a user's other sessions by res.users id.
• setActivityAudit(on: boolean): Promise<{ login_alerts: boolean; session_timeout: { enabled: boolean; hours: number; min_hours: number }; activity_audit: { enabled: boolean; global: boolean }; supported: boolean }> — Master switch for the activity audit (admin).
• setActivityAuditGlobal(on: boolean): Promise<{ login_alerts: boolean; session_timeout: { enabled: boolean; hours: number; min_hours: number }; activity_audit: { enabled: boolean; global: boolean }; supported: boolean }> — ADVANCED master switch: also audit native-UI / RPC writes (a global per-write hook on the whole DB).
• setLoginAlerts(on: boolean): Promise<{ login_alerts: boolean; session_timeout: { enabled: boolean; hours: number; min_hours: number }; activity_audit: { enabled: boolean; global: boolean }; supported: boolean }> — Enable/disable in-app "new sign-in" alerts (admin; needs Odoo 18+).
• setSessionTimeout(on: boolean, hours?: number): Promise<{ login_alerts: boolean; session_timeout: { enabled: boolean; hours: number; min_hours: number }; activity_audit: { enabled: boolean; global: boolean }; supported: boolean }> — Enable/disable idle-session auto-revoke after hours (admin; needs Odoo 18+).

settings

stability stable · permission: none (set: administrator)

Members: Vizum.settings.get, Vizum.settings.open, Vizum.settings.set (since 5.35)

Bridge ops: get, open, set

• get(): Promise<Record<string, any>> — Stored values with manifest defaults merged in.
• open(): Promise<Record<string, any>> — Opens the host settings dialog (admin saves; rejects Error("UserDenied") on cancel).
• set(values: Record<string, any>): Promise<Record<string, any>> — SDK 5.35 — write the app's own settings from the app's own form, for choices whose options only exist at runtime (models this gateway offers, knowledge bases that exist).

team

stability stable · since 5.60 · permission: permissions.team

Members: Vizum.team.history (since 5.116), Vizum.team.invite, Vizum.team.members, Vizum.team.remove, Vizum.team.roles, Vizum.team.save, Vizum.team.setActive, Vizum.team.setPassword, Vizum.team.whoami (since 5.65)

Bridge ops: history, invite, members, remove, roles, save, set_active, set_password, whoami

• history(query?: { user_id?: number; limit?: number; offset?: number }): Promise<Vizum.TeamHistoryRow[]> — SDK 5.116 — the team's audit trail, newest first, managers only.
• invite(id: number): Promise<boolean> — Send the sign-up / reset-password email (needs auth_signup).
• members(query?: { role?: string; has_role?: string }): Promise<Vizum.TeamMember[]> — 5.116: role keeps the members whose PRIMARY role it is; has_role the members who play it at all.
• remove(id: number): Promise<boolean> — Take away every role of this app (the user's other groups stay).
• roles(): Promise<Array<{ name: string; label: string; help: string; grant?: "manager" | "admin" }>> — 5.116: grant — "admin" when only a settings administrator gives or takes the role.
• save(member: { id?: number; name?: string; login?: string; email?: string; phone?: string; role?: string; roles?: string[]; password?: string }): Promise<Vizum.TeamMember> — Create (no id) or update a member; role is a role name from the manifest.
• setActive(id: number, active: boolean): Promise<Vizum.TeamMember>
• setPassword(id: number, password: string): Promise<boolean>
• whoami(): Promise<{ uid: number; manager: boolean; role: string | false; roles?: string[]; settings_admin?: boolean }> — SDK 5.65 — the caller: is a manager of the team, and the role they play.

telemetry

stability stable · permission: none

Members: Vizum.telemetry.summary, Vizum.telemetry.track

Bridge ops: summary, track

• summary(query?: { event?: string; date_from?: string; date_to?: string }): Promise<{ totals: Record<string, number>; total: number }>
• track(event: string, n?: number): Promise<boolean>

ui

stability stable · permission: permissions.ui lists the op (confirm/openHtml/openDocument/exitFullscreen always allowed)

Members: Vizum.ui.addPaletteCommand, Vizum.ui.confirm, Vizum.ui.editDomain, Vizum.ui.evalDomain, Vizum.ui.exitFullscreen (since 5.85), Vizum.ui.fullscreen (since 5.85), Vizum.ui.notify, Vizum.ui.onFullscreenChange (since 5.85), Vizum.ui.openApp, Vizum.ui.openDocument, Vizum.ui.openHtml, Vizum.ui.openList, Vizum.ui.openRecord, Vizum.ui.openUrl (since 5.21), Vizum.ui.openView (since 5.100), Vizum.ui.pinWidget, Vizum.ui.setBadge, Vizum.ui.sound

Bridge ops: addPaletteCommand, confirm, editDomain, evalDomain, exitFullscreen, fullscreen, notify, openApp, openDocument, openHtml, openList, openRecord, openUrl, openView, pinWidget, setBadge, sound

• addPaletteCommand(label: string): Promise<boolean>
• confirm(message: string, title?: string): Promise<boolean> — The host's own confirmation dialog (Odoo's, never window.confirm): true on Confirm, false on Cancel, Escape or close.
• editDomain(model: string, domain?: string, title?: string): Promise<string | null> — Host-rendered REAL Odoo domain builder (DomainSelectorDialog).
• evalDomain(domainStr: string): Promise<Vizum.Domain> — Evaluate an Odoo domain STRING into a concrete domain ARRAY in the host (py.js), resolving relative-date virtual operators.
• exitFullscreen(): Promise<{ active: boolean; browser: boolean; supported?: false }> — SDK 5.85: hand the screen back.
• fullscreen(on?: boolean): Promise<{ active: boolean; browser: boolean; supported?: false }> — SDK 5.85 (grant "fullscreen"): take the whole screen for this app.
• notify(msg: string, type?: "info" | "success" | "warning" | "danger"): Promise<boolean>
• onFullscreenChange(cb: (e: { active: boolean }) => void): () => void — SDK 5.85: cb({ active: false }) when the full screen ends for a reason the app did not ask for (the host's Exit button, Escape, the browser leaving fullscreen).
• openApp(key: string, payload?: any): Promise<boolean> — Open another INSTALLED vapp by key (grant "openApp").
• openDocument(doc: { data: string; contentType: string; name?: string }): Promise<{ opened: boolean; mode: "view" | "download"; popupBlocked?: boolean }> — Open the app's OWN stored document (a KB source PDF, an image, a text file).
• openHtml(html: string, title?: string): Promise<boolean> — Open a self-contained HTML document (e.g.
• openList(model: string, domain?: Vizum.Domain, label?: string): Promise<boolean>
• openRecord(model: string, id: number, label?: string): Promise<boolean>
• openUrl(url: string): Promise<boolean> — Open an EXTERNAL http(s) URL in a new tab.
• openView(spec: Vizum.UiOpenViewSpec): Promise<boolean> — C-IDE-2 — open ONE real Odoo view (grant "openView"): a kanban, calendar, pivot, graph, activity, list or form view, or a specific primary view by xmlid.
• pinWidget(spec: { label: string; model: string; measure?: string; domain?: Vizum.Domain; format?: string; icon?: string; [k: string]: any }): Promise<boolean> — SDK 4.1 (grant "pinWidget"): pin a LIVE KPI to the desktop.
• setBadge(n: number | string): Promise<boolean>
• sound(name?: "message" | "notification" | "share" | "snap" | "trash" | "error"): Promise<boolean> — SDK 5.30 — a short synthesized chime for an event the user should HEAR (an arriving chat message above all).

user

stability stable · permission: none

Members: Vizum.user.groups, Vizum.user.id, Vizum.user.inGroup, Vizum.user.info, Vizum.user.isAdmin, Vizum.user.isSystem, Vizum.user.login, Vizum.user.name

Bridge ops: groups, in_group, info

• groups(): Promise<string[]>
• id: number
• inGroup(xmlid: string): Promise<boolean>
• info(): Promise<{ id: number; name: string; login: string; isAdmin: boolean; isSystem: boolean; lang: string; tz: string; company: { id: number; name: string } }>
• isAdmin: boolean
• isSystem: boolean
• login: string
• name: string

vector

stability stable · permission: permissions.vector

Members: Vizum.vector.del, Vizum.vector.dump, Vizum.vector.getDocAccess, Vizum.vector.global, Vizum.vector.graph, Vizum.vector.graphClear, Vizum.vector.graphDocs, Vizum.vector.graphRecompute, Vizum.vector.indexedDocs, Vizum.vector.moveScope (since 5.83), Vizum.vector.namespaces, Vizum.vector.pgvActivate, Vizum.vector.pgvBackfill, Vizum.vector.pgvIndex, Vizum.vector.pgvProvision, Vizum.vector.pgvStatus, Vizum.vector.principals, Vizum.vector.search, Vizum.vector.setDocAccess, Vizum.vector.sharedNamespaces (since 5.83), Vizum.vector.stats, Vizum.vector.tags, Vizum.vector.unpack, Vizum.vector.upsert

Bridge ops: delete, docdelete, docget, doclist, docput, dump, get_doc_access, global, graph, graph_clear, graph_docs, graph_recompute, indexed_docs, move_scope, namespaces, pgvactivate, pgvbackfill, pgvindex, pgvprovision, pgvstatus, principals, search, set_doc_access, shared_namespaces, stats, tags, upsert

• del(namespace: string, sel: { id?: number | number[] } | { doc_id?: string | string[] } | { doc_id: string | string[]; gen: string | number } | { doc_id: string | string[]; keep_gen: string | number } | { all: true }): Promise<{ deleted: number }> — {doc_id, keep_gen} (platform 5.44) retires every chunk of the doc whose meta.gen is not keep_gen (commit a rewrite); {doc_id, gen} retires only that generation (roll a failed rewrite back).
• dump(namespace: string, opts?: { offset?: number; limit?: number }): Promise<{ namespace: string; dim: number; model: string | null; total: number; offset: number; limit: number; items: Array<{ id: number; doc_id: string; seq: number; text: string; meta: Reco… — Small-corpus offline fallback (packed base64 float32; refused above a few thousand vectors).
• getDocAccess(namespace: string, docId: string): Promise<{ is_public: boolean; users: Array<{ id: number; name: string }>; groups: Array<{ id: number; name: string }>; can_manage: boolean }> — Per-document ACCESS grants (users / groups / public=internal).
• global(namespace: string, query: string, opts?: Record<string, any>): Promise<Array<{ cid: string; title: string; summary: string; size: number; rank: number; member_names: string[] }>> — GraphRAG G2 global/map-reduce — the community summaries most relevant to query (broad/thematic "what are the main themes" questions).
• graph(namespace: string): Promise<{ entities: Array<{ name: string; type: string; rank: number; mentions: number; community: number }>; edges: Array<{ src: string; dst: string; relation: string; weight: number }> }> — GraphRAG G1 — the knowledge graph for a namespace: entities (with PageRank rank + community) + relation edges (scoped like the chunks).
• graphClear(namespace: string): Promise<{ ok: boolean; cleared: number }> — WIPE the namespace's knowledge graph for the caller's writable scope(s) so it can be rebuilt clean.
• graphDocs(namespace: string): Promise<{ doc_ids: string[]; counts: Record<string, number> }> — Which documents in a namespace are IN the knowledge graph (the per-doc "in the graph" indicator's authoritative data source) + how many entities mention each.
• graphRecompute(namespace: string): Promise<{ communities: number; summarized: number; entities_described: number; entities: number; edges: number } | { busy: true }> — GraphRAG on-demand recompute: rebuild the namespace's graph NOW (PageRank + community detection/summaries + entity descriptions) for the CALLER's writable scope, so a "Temas" panel fills right after ingest instead of wa…
• indexedDocs(namespace: string): Promise<{ doc_ids: string[]; counts: Record<string, number>; degraded?: boolean; degraded_reason?: string }> — Which documents are ACTUALLY indexed on the server for namespace, in the caller's readable scope (global ∪ own ∪ my-groups + per-doc grants), with per-doc chunk counts — server truth for a Library, not a local registr…
• moveScope(namespace: string, opts: { from: "global" | "user"; to: "user" | "global"; user_id?: number; doc_id?: string | string[]; batch?: number }): Promise<{ moved: number; remaining: number; conflicts: number; done: boolean; from: string; to: string; user_… — SDK 5.83 — move one namespace's rows between the shared scope and a user's scope WITHOUT re-embedding: the owner of the stored rows changes (embedding, text, metadata and chunk order stay as stored; nothing is embedded …
• namespaces(): Promise<Array<{ name: string; count: number; model: string | null; dim: number }>>
• pgvActivate(opts: { active: boolean; force?: boolean }): Promise<{ available: boolean; installed: boolean; column_ready: boolean; active: boolean; mode: string; pending_backfill: number; error?: string; [k: string]: unknown }> — Switch RAG storage to Mode 3 or back to Local (admin, platform 5.45).
• pgvBackfill(): Promise<{ backfilled: number; skipped?: number; remaining: number; error?: string }> — Migrate existing base64 vectors into pgvector (admin, batched).
• pgvIndex(opts?: { blocking?: boolean }): Promise<{ extversion: string | null; dims: number[]; present: number[]; built: number[]; invalid: number[]; unindexable?: number[]; max_ann_dim?: number; sql: string[]; blocking: boolean; error?: string; failed?: { dim… — Per-dimension hnsw index state (admin, platform 5.45).
• pgvProvision(): Promise<{ available: boolean; installed: boolean; column_ready: boolean; active: boolean; mode: string; pending_backfill: number }> — Install the pgvector extension + column in this database (admin).
• pgvStatus(): Promise<{ available: boolean; installed: boolean; column_ready: boolean; active: boolean; mode: string; pending_backfill: number }> — Mode-3 (local pgvector) setup, for the "RAG pgvector Setup" guide.
• principals(query: string): Promise<{ users: Array<{ id: number; name: string }>; groups: Array<{ id: number; name: string }> }> — For the share picker — people/groups matching query.
• search(namespace: string, query: string | number[], opts?: { topK?: number; minScore?: number; mode?: "vector" | "keyword" | "hybrid"; filter?: { doc_id?: string | string[] } } ): Promise<{ matches: Array<{ id: number; score: number; text: string; doc_id: str… — Top-k retrieval.
• setDocAccess(namespace: string, docId: string, cfg: { is_public?: boolean; user_ids?: number[]; group_ids?: number[] } ): Promise<{ ok: boolean }>
• sharedNamespaces(): Promise<Array<{ name: string; count: number; model: string | null; dim: number }>> — SDK 5.83 (Vizum.supports("vector-scope")) — the namespaces this user-scoped app owns in the SHARED (global) scope, with row counts: what an app that narrowed from vector "global" to "user" must migrate.
• stats(namespace: string): Promise<{ namespace: string; count: number; dim: number; model: string | null; bytes: number; doc_count: number }>
• tags(namespace: string): Promise<{ tags: string[]; categories: string[] }> — The distinct tag vocabulary + auto-classified categories in a namespace.
• unpack(b64: string): Float32Array — Decode one packed base64 float32 blob to a Float32Array (offline path).
• upsert(namespace: string, items: Array<{ id?: number; text?: string; embedding?: number[]; doc_id?: string; seq?: number; meta?: Record<string, any> }>, opts?: { embed_model?: string }): Promise<{ upserted: number; dim: number; model: string }> — Upsert chunks.

vision

stability stable · since 5.11 · permission: permissions.media ['camera']

Members: Vizum.vision.onResults, Vizum.vision.start, Vizum.vision.stop

Bridge ops: start, stop

• onResults(cb: (r: { hands: Array<{ landmarks: Array<{ x: number; y: number; z?: number }>; handedness: any }>; preview?: string; }) => void): Vizum.Subscription
• start(opts?: { numHands?: number; preview?: boolean }): Promise<{ ok: boolean; already?: boolean }>
• stop(): Promise<{ ok: boolean }>

webhooks

stability stable · permission: permissions.webhooks

Members: Vizum.webhooks.ack (since 5.67), Vizum.webhooks.deliveries (since 5.67), Vizum.webhooks.fail (since 5.67), Vizum.webhooks.list, Vizum.webhooks.retry (since 5.67), Vizum.webhooks.url

Bridge ops: ack, deliveries, fail, list, retry, url

• ack(deliveryId: number): Promise<Vizum.WebhookDelivery> — 5.67 — mark a queued delivery (its row's v.delivery) processed.
• deliveries(hook?: string | null, opts?: { status?: Vizum.WebhookDeliveryStatus; limit?: number }): Promise<Vizum.WebhookDelivery[]> — 5.67 — the delivery ledger (metadata only, newest first, at most 200).
• fail(deliveryId: number, error?: string): Promise<Vizum.WebhookDelivery> — 5.67 — could not process it: re-queued, or dead-lettered at the hook's max_attempts.
• list(): Promise<Array<{ name: string; url: string; signed: boolean }>>
• retry(deliveryId: number): Promise<Vizum.WebhookDelivery> — 5.67 — installer or administrator: send a failed / dead-lettered delivery back.
• url(name: string): Promise<{ url: string }>

window

stability stable · permission: none

Members: Vizum.window.close, Vizum.window.openPanel, Vizum.window.resize, Vizum.window.setTitle

Bridge ops: close, openPanel, resize, setTitle

• close(): Promise<boolean>
• openPanel(path: string, opts?: { title?: string; w?: number; h?: number; payload?: any }): Promise<boolean>
• resize(w: number, h: number): Promise<boolean>
• setTitle(t: string): Promise<boolean>

workflow

stability stable · permission: permissions.workflows

Members: Vizum.workflow.approve, Vizum.workflow.cancel, Vizum.workflow.get, Vizum.workflow.list, Vizum.workflow.reject, Vizum.workflow.start

Bridge ops: approve, cancel, get, list, reject, start

• approve(id: number, opts?: { note?: string }): Promise<WorkflowInstance>
• cancel(id: number): Promise<WorkflowInstance>
• get(id: number): Promise<WorkflowInstance>
• list(query?: { workflow?: string; state?: string; mine?: boolean; limit?: number }): Promise<WorkflowInstance[]>
• reject(id: number, opts?: { note?: string }): Promise<WorkflowInstance>
• start(name: string, payload?: Record<string, any>): Promise<WorkflowInstance>

Compatibility matrix

Generated from the since values above: the oldest capability that serves each member introduced by a capability note. Members without a since are served everywhere.