# Ivy Convert Odoo

> Convert an Odoo application or module to an Ivy project. Use when the user wants to migrate from Odoo, convert an Odoo module, or build an Ivy app from Odoo Python/XML source files. Handles Python files and folders containing Odoo modules.

- Skill: `ivy-interactive/ivy-convert-odoo` (Agent Skill, multi-file: 62 files)
- Install (CLI): `npx skillmds@latest add ivy-interactive/ivy-convert-odoo`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ivy-interactive/ivy-convert-odoo/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ivy-interactive (https://skillmd.com/u/ivy-interactive)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ivy-interactive/ivy-convert-odoo

---


# ivy-convert-odoo

Convert an Odoo application or module to an Ivy project.

## Pre-flight: Read Learnings

If the file `.ivy/learnings/ivy-convert-odoo.md` exists in the project directory, read it first and apply any lessons learned from previous runs of this skill.

## Reference Files

Read before implementing:
- [references/AGENTS.md](references/AGENTS.md) -- Ivy framework API reference (widgets, hooks, layouts, inputs, colors)

## Reference Files

The [references/](references/) folder contains 60 reference files with Odoo-to-Ivy component mappings (fields, views, components). Read the relevant reference files before implementing the conversion to understand how to map Odoo features to Ivy features.

## Step 1: Locate the Odoo Module

You need a path to a Python file or a folder containing the Odoo application/module. Check if a path was provided via `$ARGUMENTS`. If not, ask the user to provide one.

Verify the path exists with `test -f "<path>"` or `test -d "<path>"`.

## Step 2: Research the Odoo Application

Read all the `.py` and `.xml` files and build a mental model of:
- Odoo models (fields.Char, fields.Many2one, fields.Selection, etc.)
- View types used (form, list/tree, kanban, calendar, graph, pivot, search, activity, etc.)
- Field widgets and OWL components
- Actions (ir.actions.act_window, server actions, automated actions)
- Business logic (compute methods, onchange, constraints, workflows)
- Security rules (ir.model.access.csv, record rules)
- Reports (QWeb templates)
- Menu structure and navigation

### 2a: Classify Each View

For each view identified, classify it:
- **CRUD**: Standard create/read/update/delete for a model (list + form)
- **Dashboard**: Reporting, charts, KPIs (pivot, graph, calendar)
- **Workflow**: Multi-step process with state transitions
- **Read-only**: Information display only, no editing

This determines the Ivy pattern to use.

### 2b: Document Security Model

Identify security and access control:
- Access rights from `ir.model.access.csv`
- Record rules (row-level security)
- `@check_access_rights` decorators
- User groups and permissions
- Document who can view/edit each model

### 2c: Map Computed Fields

For each model, identify:
- Fields with `@api.depends` decorators (computed fields)
- Fields with `@api.onchange` handlers (dynamic updates)
- `_compute_*` methods and their logic
- Dependency chains between fields
- Document the computation logic for each

### 2d: Map Menu and Navigation

Document the application structure:
- Extract menu hierarchy from `ir.ui.menu`
- Map actions from `ir.actions.act_window`
- Identify navigation flow between views
- Note sidebar, top menu, breadcrumbs

## Step 3: Detect Odoo Connection

Before converting, check if an Odoo connection is configured:

1. Look for connection files in the project's connections directory
2. Check if connection type is "odoo"
3. Verify connection details (host, database, username)
4. If missing, prompt the user to configure a connection using the appropriate connection skill (e.g., `/ivy-create-db-connection` for databases, `/ivy-create-auth-connection` for auth, `/ivy-create-any-connection` for APIs)
5. Test connection before proceeding

## Step 4: Present the Conversion Plan

Write a summarized conversion guide that maps the Odoo features used in the application to Ivy features. The conversion guide should be structured in a way that makes it easy to follow when implementing the conversion. Use markdown formatting to make it clear and organized -- but be concise and token efficient.

Present the plan to the user for approval before proceeding.

## Step 5: Implementation

Identify if there are any additional connections (db, auth, api) that should be set up using the appropriate connection skill (e.g., `/ivy-create-db-connection` for databases, `/ivy-create-auth-connection` for auth, `/ivy-create-any-connection` for APIs).

Given the conversion guide from the previous step, implement the conversion of the Odoo application to an Ivy application. Use the conversion guide and the reference files to map Odoo features to Ivy features.

## Step 6: Validation

After generating Ivy code, validate the conversion:

1. All Odoo views have corresponding Ivy pages
2. All models have Ivy data classes
3. All form fields have Ivy input widgets
4. Security rules are documented (even if not implemented)
5. Computed fields have UseQuery or UseEffect equivalents
6. Menu structure maps to Ivy routing

Generate a validation report listing:
- Successfully converted views
- Views with workarounds/limitations
- Missing or incomplete conversions

## Post-run: Evaluate and Improve

After completing the task:

1. **Evaluate**: Did the build succeed? Were there compilation errors, unexpected behavior, or manual corrections needed during this run?
2. **Update learnings**: If anything required correction or was surprising, append a concise entry to `.ivy/learnings/ivy-convert-odoo.md` (create the file and `.ivy/learnings/` directory if they don't exist). Each entry should note: the date, what went wrong, why, and what to do differently next time.
3. **Skip if clean**: If everything succeeded without issues, do not update the learnings file.