Using the assistant¶
Interactive chat¶
Backend users in AI: User can open the assistant from the systray bubble (persistent chat UI) or from .
Typical turn flow:
You send a message (optionally with attachments).
The orchestrator assembles layered system prompts (core safety, global behaviour, agent prompt, skills, environment facts, optional record snapshot, history).
The model may call tools (search, read, skills, memory, …).
Each tool call is authorized by the access gate (ban → capability → AI policy → Odoo ACL → sanitise → audit).
The assistant replies in the conversation language when possible.
Chatting from a business form may attach a record snapshot (L4) so the model sees the current record context. Snapshots are data-fenced; treat them as sensitive if the form is sensitive.
Conversations¶
lists chat threads for the current user (administrators may see more depending on record rules).
Use conversations to:
continue multi-turn work with full history;
review what was asked and answered;
relate write proposals and logs back to a thread.
Note
Agent channels (Discuss, chatter, assignment) also use conversation-style ledgers so every channel has an auditable communication history.
Attachments and files¶
Users can attach images and documents to a chat turn (subject to configured MIME types and max size under AI Settings → Web Access / file limits).
Images may be re-encoded before they reach the model.
HTML/SVG and other renderable active content is refused for document download tools.
Fetching a file from a URL into a binary field requires both Web and Write capabilities (
fetch_file_to_field).
Write proposals¶
When a tool wants to create, update, delete, attach a file, or run certain
actions and confirmation is required, the gate creates an
ai.pending.write row instead of applying immediately.
Open to:
read the human-readable Summary;
inspect model, operation, target id and values;
Apply or Cancel while the proposal is still Pending;
use Open record to jump to the existing target document (write / delete / action on a live id — not available for pure creates).
For agent proposals the supervisor also receives a To-Do on the target business record when possible (e.g. the vendor bill), with a chatter note and a fallback activity on the agent task for creates without an id yet. That activity is a pointer into the proposal workflow; applying or cancelling the proposal closes it. See Task write mode (agent runs only).
An agent proposal can be refused at apply time even while it still reads Pending. If the run that proposed it was stopped on request, or closed by the stuck-run reaper because its worker died, Apply answers The agent run that proposed this write was stopped before it finished, so this proposal can no longer be approved. A run that somebody else declared over may no longer authorise a change, so the work has to be re-requested rather than approved — see Stopping a run. Usually such a proposal has already been cancelled or expired with its run; where the row survives, this is what you meet. Proposals from a run that ended on its own stay approvable until they expire, and Cancel is never refused for this reason.
Note
Even with Write enabled, the gate refuses fields that also write into a different model — a lead’s email address, or a product on an invoice line. The refusal names the model and the field it would not write; for a line inside Invoice lines it names that parent field rather than the line’s own. It does not say why, so ask an administrator to check Cross-model write protection. Such a refusal is a configuration boundary: it records no violation and costs you no strike.
Chat vs agent proposals¶
Interactive chat |
Autonomous agent run |
|
|---|---|---|
Controlled by |
Global Ai Write Mode in Settings |
The task’s Write Mode (default confirm; see Task write mode (agent runs only)) |
Approver |
Usually the chatting user |
Agent supervisor (when the task mode still proposes) |
Default TTL |
60 minutes (configurable) |
1440 minutes (configurable), only while its run is open |
Acting identity on apply |
The chat user |
The agent user (from the run), not the supervisor |
Systray nudge |
Chat card / own proposals list |
To-Do on the business record when possible, else on the task |
Note
The agent lifetime applies only while the proposing run is still open. Once that run has ended — Done, Failed or Timed out — the AI: Expire pending writes scheduled action expires its remaining proposals on its next pass, at most 15 minutes later, whatever the lifetime says. The case that catches supervisors out is a run that overran its own time limit: it closes as Timed out while still holding open proposals. Review proposals from failed and timed-out runs promptly. If you open a To-Do for a proposal that no longer exists, mark the activity done: the proposal expired with its run.
Important
Approving an agent proposal means: “I authorise this agent to perform this change with its rights.” The supervisor does not need (and should not use) broader rights than necessary to review the summary — execution rights come from the agent user + policy at apply time.
Write modes¶
Interactive chat — under :
Apply automatically — every create/write/delete/file tool runs immediately. Highest risk.
Always require confirmation — everything becomes a proposal.
Create automatically, confirm updates (hybrid, default) — only new records auto-apply; updates, deletes and file attaches wait for confirmation.
Agent runs — same three values, but on the task form (Write Mode), defaulting to Always require confirmation. The Settings value does not apply to agent runs. Use auto or hybrid only when the standing instruction and skills keep risk bounded (draft-only fills, no posting, no payments). Details: Task write mode (agent runs only).
A TTL of 0 disables expiry by age for that class of proposals. It does not disable the sweep described above: a proposal whose agent run has already ended is expired however long you are prepared to wait for an approval.
Presenting choices¶
The assistant may use a structured present choices tool so the UI can show selectable options instead of free text only (when supported by the chat frontend).
What the assistant should not do¶
Claim a model, field, stage or module exists without tool or environment evidence on this database.
Write
statedirectly to skip business buttons.Promise that an email was sent to a customer unless a real mail tool/action did so under policy (shipped support prompts forbid fake send claims).
Treat ticket text as a privilege upgrade.
For agent-driven work (assignment, @mention), see Agents.