BambooForge NocoDB Connector
A real connector between Odoo 19 and NocoDB — the open-source no-code database platform, the self-hosted Airtable alternative. Point it at your NocoDB URL, drop in an API token, and the connector imports your bases and their tables straight into Odoo over the NocoDB REST API (v2) — and, when you configure a Row Sync mapping, does two-way row sync (import upsert / export create-update) between a NocoDB table and an Odoo model, on a schedule, with dry-run safety and full source you can audit.
Verified live against a running NocoDB
We don't just claim a vague version range. The connector was installed on Odoo 19, pointed at a live NocoDB instance over its REST API v2, and run through a full base / table import — 0 errors.
| NocoDB version | API | Live result |
|---|---|---|
| Latest (v2 API) | REST API (xc-token) | ✔ Live-tested — 2 bases + 2 tables, 0 errors |
| Recent releases | REST API v2 | ✔ Compatible — validate on your build |
| Self-hosted | /api/v2 meta + data | ✔ Supported (xc-token) |
The live test imported 2 bases — “Sales CRM” and “Getting Started” — and 2 tables with no errors: “Deals” (5 rows, in Sales CRM) and “Features” (in Getting Started). Each became an Odoo record carrying its row count and a link back to its parent base, read straight from the NocoDB REST API v2.
Built to actually sync — not to look busy
NocoDB exposes a clean REST API, and this connector treats it that way: it authenticates with an API token sent as xc-token, calls the /api/v2 meta + data endpoints for your bases and their tables, and maps each one onto a dedicated Odoo model — so you can see your NocoDB workspace without leaving Odoo. Every model ships with verifiable sync logic, covered by tests — no fake dashboards, no “readiness score” with nothing behind it.
What you actually get
Everything below ships in the box — a connector that reads your NocoDB metadata over the REST API v2 with an API token, and syncs the actual rows two ways when you configure a Row Sync mapping.
Two-way row sync
Sync the actual rows, not just table metadata. Bind one NocoDB table to one Odoo model with a column↔field map, a direction and a key column: import upserts NocoDB rows into Odoo, export pushes Odoo records back as NocoDB rows (create/update). Idempotent via the binder (external row id ↔ res_id — re-runs update, never duplicate) and strictly scoped to the one model/table you configure.
Bases → nocodb.base
Each NocoDB base (project) imports into a dedicated nocodb.base record — its name, with a count of the tables it contains — so your NocoDB workspace inventory lives in Odoo.
Tables → nocodb.table
Each NocoDB table becomes a nocodb.table record — its display name, its internal table name and its row count — so you can see the shape of every base at a glance.
Tables linked to bases
Every table is tied to its parent base, so you can open a base in Odoo and see its tables and their row counts resolved from the import — your NocoDB structure carries over intact.
Status mapping
The NocoDB import status for each base and table is carried across onto the Odoo records through an editable mapping table per instance, so you always know what synced and what is still pending.
Scheduled sync
The connector runs from NocoDB on a schedule (cron) — point it at your instance and it keeps Odoo up to date, running both metadata import and any configured Row Sync mappings (import and export) unattended.
Token-auth REST API v2 client
One client authenticates with a NocoDB API token sent as the xc-token header against the /api/v2 meta + data endpoints. No OAuth, no passwords — JSON responses, with retry, backoff and rate-limit handling built in.
Sync Control Tower
A live operations dashboard for every instance — sync health, circuit-breaker state, queue backlog, dead-letter count, open conflicts and throughput, each a click-through to the jobs behind it. Know sync is healthy without reading a single log line.
Bulk dead-letter console
Every job that exhausted its retries lands here, grouped by instance and error. Select many at once and bulk requeue once you've fixed the cause, or bulk discard — no record-by-record clean-up.
Conflict-resolution workbench
When a local and a remote change collide, the conflict is captured with a side-by-side snapshot diff. Triage them in one place and bulk-resolve — keep local or take remote — instead of digging through history.
Field-mapping studio
Map source fields to Odoo fields visually, test the exact payload transform in a wizard before you save, and let one-click suggestions propose sensible mappings. Expression transforms and step conditions evaluate through Odoo's sandboxed safe_eval.
A live walkthrough inside Odoo 19
Recorded in a real Odoo 19 connected to a live NocoDB — the connection cockpit, a synced base, the imported tables, the status mapping and the flow engine, all on real data.
Every screen, from a live install
Captured from a running Odoo 19 connected to a live NocoDB — real data imported through the connector, not mockups.
nocodb.table records — display name, internal table name and row count.
Run every NocoDB store from one Control Tower
A short walkthrough of the operations tooling on real data: the Control Tower board, the side-by-side conflict workbench and the bulk dead-letter console.
Production safety, by default
Resilient queue
Retry with exponential backoff, rate-limit awareness, dead-letter handling and conflict capture for every job.
Circuit breaker
Auto-pauses sync after N consecutive failures so a broken endpoint can never flood your data.
Dry-run mode
Default-ON for every new instance — preview the exact write before anything touches live records.
Pre-flight validation
Blocking and warning findings surfaced before go-live, with auto-fix suggestions.
Rollback snapshots
Capture record state before risky writes and roll back cleanly when needed.
Write-back is opt-in
Out of the box the connector only reads NocoDB (metadata import). It writes back to a NocoDB table only when you configure an export/bidirectional Row Sync mapping — strictly scoped to the one table you choose, idempotent via the binder, and it never touches any other base or table.
Honest feature matrix
No asterisks, no fake checkmarks. Here is exactly what this version does — and what is on the roadmap.
| Capability | Status |
|---|---|
Token-auth REST API v2 connection (xc-token against /api/v2) | ✔ Included |
Bases → nocodb.base (name, table count) | ✔ Included |
Tables → nocodb.table (display name, internal table name, row count) | ✔ Included |
| Tables linked to their parent base | ✔ Included |
| Import status mapping per instance | ✔ Included |
| JSON responses parsed across all bases / tables | ✔ Included |
| Scheduled (cron) import | ✔ Included |
| Queue: retry · backoff · dead-letter · circuit breaker | ✔ Included |
| Pre-flight validation · rollback snapshots · dry-run | ✔ Included |
| Built-in import flow templates | ✔ Included |
| Two-way row sync — import upsert / export create-update, keyed matching, strict per-table model scoping | ✔ Included |
| Sync Control Tower — live health / circuit / backlog / dead-letter / conflicts / throughput dashboard | ✔ Included |
| Bulk dead-letter console — grouped exhausted jobs, bulk requeue / discard | ✔ Included |
| Conflict-resolution workbench — snapshot diff, triage & bulk resolve | ✔ Included |
Field-mapping studio — payload-test wizard, one-click suggestions, safe_eval transforms & conditions | ✔ Included |
| Column / field-level schema import | Roadmap |
Live in four steps
A guided quick-setup wizard and onboarding checklist walk you from a NocoDB API token to your first safe import.
Create an API token
In NocoDB, go to Account Settings → Tokens and create an API token. No schema changes, no plugin to install.
Connect
In Odoo, enter your NocoDB base URL plus the API token, then run the first scheduled import. One click tests reachability.
Dry-run
Preview exact writes with dry-run + validation on. Clear any blocking findings.
Go live
Let the scheduled (cron) run keep Odoo and NocoDB in step — metadata import plus any Row Sync mappings you enabled.
Buy with full clarity
In the box today
- Metadata import: bases →
nocodb.base, tables →nocodb.table - Tables linked to their parent base — your NocoDB structure visible in Odoo
- Token-auth REST API v2 client (
xc-token) — no OAuth, no passwords, JSON responses - Scheduled (cron) import — point it at your NocoDB and it stays current
- Configurable import status mapping, dry-run safety, rollback snapshots
- Full source included — audit and extend every line for your own use
- Two-way row sync — bind a NocoDB table to an Odoo model, import upsert / export create-update, idempotent & strictly scoped
- Sync Control Tower — one live dashboard for health, circuit breaker, backlog, dead-letter, conflicts & throughput
- Bulk dead-letter console & conflict-resolution workbench — triage and fix at scale, not row by row
- Field-mapping studio — visual mapping, a payload-test wizard, one-click suggestions and
safe_evaltransforms
Roadmap
- Column / field-level schema import (auto-map every NocoDB column to an Odoo field)
- Multi-table / linked-record sync in a single mapping
- Real-time (webhook-driven) sync in addition to scheduled runs
Frequently asked
Which versions are supported?
Odoo 19.0 on the Odoo side. On the NocoDB side, the connector was live-tested on the current NocoDB self-hosted release using the stable REST API v2 (/api/v2), and is compatible with NocoDB versions that expose the /api/v2 meta + data API. Validate on your specific build.
What does it import?
Two NocoDB entities, each into a dedicated Odoo model the connector ships: bases become nocodb.base records — carrying the name and a count of their tables — and tables become nocodb.table records with the display name, internal table name and row count. Each table is linked to the base it belongs to. Beyond metadata, a Row Sync mapping syncs the actual table rows two ways — import upsert into Odoo and export create/update back to NocoDB — strictly scoped to the one model/table you configure.
How does authentication work?
One mode: an API token. You create a token in NocoDB under Account Settings → Tokens, then enter your NocoDB base URL plus that token in Odoo. The connector sends it as the xc-token header on every REST API v2 call — no OAuth, no passwords. Metadata import only reads; an export/bidirectional Row Sync mapping also writes rows back to the one table you configure.
Does it push changes in real time?
Not instantly — it runs on a schedule (cron). Each run does the metadata import (bases, tables and row counts) and executes any Row Sync mappings you enabled, in both directions. Real-time (webhook-driven) sync is on the roadmap.
Is it safe to run against production data?
Dry-run mode is ON by default for new instances, validation blocks risky writes, and rollback snapshots let you undo. Metadata import is read-only, and row sync writes back only when you configure an export/bidirectional mapping — strictly scoped to the one table you choose. You decide when to go live.
What support and refund policy do I get?
Every request is answered within 24 hours, setup help included. If you report a bug within 2 months of purchase and it isn't resolved within 15 days, you're entitled to a full money-back refund.
Connect Odoo and NocoDB the honest way
24-hour support · Report a bug within 2 months — unresolved in 15 days = full refund · Full source included
bambooforge.labs@gmail.comMore from BambooForge Labs — one vendor, the same standard: tested, source included, supported.
BambooForge NocoDB Connector
A read-only importer that brings your NocoDB (the open-source no-code database / Airtable alternative) workspace into Odoo 19: it imports your bases and the tables inside each base, with a live row count for every table, so you get an auditable inventory of your NocoDB data without leaving Odoo. Nothing is ever written back to NocoDB.
This page is the complete manual. If you follow it top to bottom you can install, connect, run your first import, automate it, and fix the common issues without contacting support.
- Overview
- Requirements
- Installation
- Step 1 — Create an API token in NocoDB
- Step 2 — Create the connection in Odoo
- Step 3 — First import (dry-run, then live)
- Field mapping & customization
- Automation (scheduled actions & webhooks)
- Safety features
- Troubleshooting
- Frequently asked questions
- Data, privacy & limits
- Support & updates
- Upgrading & version compatibility
- Uninstallation
- Changelog
Overview
The connector reads from the NocoDB REST/Meta API (api/v2) and mirrors the metadata into dedicated Odoo models. It covers:
- Bases — every NocoDB base (database/project) from GET /api/v2/meta/bases, imported into NocoDB Base records (the base id and its title).
- Tables — the tables inside each base from GET /api/v2/meta/bases/<baseId>/tables, imported into NocoDB Table records. Each table links back to its base (resolved from the table's baseId).
- Row counts — a live record count per table, read from GET /api/v2/tables/<tableId>/records?limit=1 -> pageInfo.totalRows and stored on the table at import time.
Direction of sync: Odoo <- NocoDB (import only). This connector never writes to NocoDB — no create, update or delete is ever sent to your workspace. Bases are imported before tables so each table can link back to its base.
Importing the actual table records (the row data itself) is a roadmap item; v1 imports the base/table inventory and row counts only.
Every remote call goes through a queue: nothing is written to Odoo until a job runs, jobs retry with back-off on transient failures, and a circuit breaker pauses an instance that keeps failing.
Requirements
- Odoo: 19.0, Community or Enterprise.
- NocoDB: any NocoDB exposing the v2 Meta/REST API (/api/v2/meta/bases, /api/v2/meta/bases/<id>/tables, /api/v2/tables/<id>/records) with xc-token header auth. NocoDB must be reachable from the Odoo server.
- Python: no extra libraries beyond a standard Odoo 19 install.
- Odoo access: any internal user can use the connector screens. The NocoDB API token is stored in a system-only field, so only the Settings / Administration user can read or change it.
- Network: outbound HTTP/HTTPS from Odoo to your NocoDB server. By default the connector refuses internal/loopback/private hosts as an SSRF safeguard (see Safety features).
Installation
- Copy bambooforge_nocodb_connector into your Odoo addons path.
- Restart the Odoo service.
- Open Apps, click Update Apps List, search for NocoDB, and press Activate / Install. The only dependencies are base and mail.
No live NocoDB server is required to evaluate the connector: a mock NocoDB API ships inside the module, so you can install, explore and run the full import flow against sample data before pointing it at a real NocoDB.
Step 1 — Create an API token in NocoDB
NocoDB authenticates with a single API token, sent as the xc-token header on every request. To create one:
- In NocoDB, open Account Settings (your avatar, top of the sidebar).
- Go to the Tokens section.
- Click Create / Add new token, give it a description such as Odoo, and create it.
- Copy the generated token. You will paste it into Odoo in Step 2.
Because the connector is read-only, the token only ever needs read access to your bases, tables and records.
Step 2 — Create the connection in Odoo
Open NocoDB Connector ▸ Configuration ▸ Instances and create a record.
Key fields:
| Field | What to enter |
|---|---|
| Name | A label for this connection, e.g. My NocoDB. |
| Base URL | Your NocoDB server root, e.g. https://nocodb.example.com or http://localhost:8200. |
| Authentication | API Token (xc-token) — the only option NocoDB supports. |
| API Token | The token from Step 1 (visible to administrators only). Sent as the xc-token header on every request. |
| API Path | Leave the default api/v2 unless your NocoDB differs. The client builds <Base URL>/<API Path>/meta/bases and so on. |
| Verify SSL | Keep on for production. Turn off only for self-signed test certificates. |
| Allow internal host | Off by default. Turn on only to reach a NocoDB on localhost or a private network (lowers the SSRF guard — see Safety features). |
Then click Test Connection. The connector lists your bases as a lightweight auth + connectivity check. A green Connected state means the token and URL are correct. If it fails, the exact error is shown on the form and recorded in Logs (see Troubleshooting).
Step 3 — First import (dry-run, then live)
New instances start with Dry-run ON. In dry-run, import jobs simulate writes: instead of changing data they produce Validation Results you can review under NocoDB Connector ▸ Operations ▸ Validation Results. This lets you confirm what would happen before anything is written.
To run a first import:
- On the instance, click Queue Base Import (and/or Queue Table Import). This enqueues jobs; it does not block the UI.
- Jobs are processed by the Nocodb Queue Processor scheduled action (every minute), or immediately if you run it manually from Operations ▸ Queue Jobs.
- Review Validation Results while still in dry-run.
- When satisfied, open the instance, turn Dry-run OFF, and run the imports again to write the records for real.
Imported records land in NocoDB Connector ▸ Imported Data ▸ Bases and ▸ Tables. Each carries its NocoDB id, so re-imports update the same record instead of duplicating it. Bases are imported before tables so each table links back to its base.
Field mapping & customization
- Field Mappings (Configuration) map NocoDB fields to Odoo fields per entity. Use Generate suggested mappings on the instance to seed the core ones, then adjust.
- Schema Fields lists the discovered fields per entity. Run Schema Introspection on the instance to refresh it: it records the Odoo target fields and samples one live NocoDB record (falling back to the bundled mock when the API is unreachable) so you can see both sides.
- Import limits on the instance cap how much is pulled per run: Bases import limit (default 100) and Tables import limit (default 200), with matching reconcile limits. Raise them if your workspace is larger.
Because the connector is read-only, there are no stock/image/tax/order toggles — it imports the base and table inventory and row counts, nothing more.
Automation (scheduled actions & webhooks)
The module ships these scheduled actions (Settings ▸ Technical ▸ Scheduled Actions):
| Scheduled action | Default | Purpose |
|---|---|---|
| Nocodb Queue Processor | every 1 min | Processes queued import jobs. |
| Nocodb Reconciliation | every 15 min | Pulls recent remote ids for enabled entities and queues what is missing. |
| Nocodb Maintenance | every 1 hr | Recovers stale/locked jobs and trims old jobs and logs. |
| Nocodb Flow Scheduler | every 5 min | Runs scheduled import flows. |
| Nocodb Flow Metrics | every 1 hr | Aggregates flow-run metrics. |
| Nocodb Auto Recover | every 15 min | Reopens a tripped circuit breaker once NocoDB is healthy again. |
Turn on Auto import / Auto reconcile per entity on the instance (Auto import bases, Auto import tables, Auto reconcile bases, Auto reconcile tables) to let the scheduled actions keep the inventory current hands-free.
Webhooks: this connector is a pull-only importer. The route /nocodb/webhook exists only as a neutralized stub that always answers a clear "not supported" response (HTTP 501) — there is no webhook intake. A genuine push path (NocoDB does support per-table webhooks) is a roadmap item, not part of this read-only v1. The scheduled reconciliation keeps your inventory current without it.
Safety features
- Read-only by design — the connector only ever issues authenticated GET calls to NocoDB. There is no write path, so it cannot create, change or delete anything in your workspace.
- Dry-run mode — simulate Odoo-side writes and review Validation Results before going live (Dry-run field, ON by default).
- Business validation profiles — Minimal / Standard / Strict gate risky writes (Business validation profile field).
- Resilient queue — every import is a job with retry and exponential back-off (Retry limit, Backoff policy, Backoff base/cap minutes).
- Circuit breaker — after repeated failures (or an auth/configuration error) an instance auto-pauses (Tripped); the Auto Recover action reopens it once NocoDB responds again (Auto-pause threshold, default 5).
- Rollback snapshots — when enabled, imports capture a snapshot so you can undo a batch from Operations ▸ Rollback Snapshots (Rollback enabled).
- SSRF guard — the connector refuses internal/loopback/private/link-local/ reserved hosts unless Allow internal host is explicitly enabled.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Test Connection fails with 401 / 403 | Wrong or missing API token. The xc-token is invalid or was revoked. Re-create it in NocoDB (Account Settings ▸ Tokens) and paste it into the API Token field (Step 1). |
| "NocoDB API token (xc-token) is required." | The API Token field is empty. Paste the token; only an administrator can see or edit this field. |
| "...is not allowed because it resolves to the non-public address..." | Base URL points at localhost/private/loopback/link-local IP. Enable Allow internal host on the instance (test/self-hosted only). |
| "the URL must start with http:// or https://" | The Base URL has no scheme. Enter the full root, e.g. https://nocodb.example.com. |
| SSL errors on Test Connection | Self-signed certificate. Use a valid cert, or turn off Verify SSL for testing only. |
| 404 on bases/tables | The API Path is wrong for your NocoDB. The default is api/v2; adjust it if your server exposes the API elsewhere. |
| Row counts all show 0 | The token cannot read records, or the table is empty. Confirm the token has read access; the count comes from pageInfo.totalRows on /tables/<id>/records. |
| Jobs stay in Pending | The Queue Processor is off or the instance is paused. Check Scheduled Actions is active and the instance is not Paused. |
| Instance shows Tripped | Circuit breaker tripped after repeated failures (or an auth error). Fix the token/URL; Auto Recover reopens it, or click Resume. |
| Nothing happens after Import | You are in Dry-run. Review Validation Results, then turn dry-run off and re-run. |
| Tables imported but not linked to a base | The base was not imported yet. Import bases first (the connector does this automatically when both run); re-run the table import. |
For anything else, Operations ▸ Logs records every API call and error with a timestamp.
Frequently asked questions
Which versions are supported? Odoo 19.0 on the Odoo side. On the NocoDB side, any server exposing the v2 Meta/REST API with xc-token auth. Validate your exact build with the bundled mock first.
Do I need NocoDB installed to evaluate it? No. A mock NocoDB API ships inside, so you can install, explore and demo the full import flow before connecting a real server.
How does authentication work? Create an API token in NocoDB under Account Settings ▸ Tokens and paste it into the API Token field. The connector sends it as the xc-token header on every request.
Does the connector write anything to NocoDB? No. It is read-only: every call is an authenticated GET. It cannot create, update or delete bases, tables or records in your workspace.
Does it import the actual rows in my tables? Not in v1. It imports the base/table inventory and a live row count per table. Importing the row data itself is on the roadmap.
How does it keep the inventory current? The scheduled actions (Queue Processor + Reconciliation) re-import on a schedule when you enable Auto import / Auto reconcile. There is no webhook intake.
Is it safe to run against production data? Yes. It only reads from NocoDB, and on the Odoo side dry-run is ON by default, validation gates risky writes, and rollback snapshots let you undo. You decide when to go live.
What support and refund policy do I get? Every request is answered within 24 hours, setup help included. If you report a bug within 2 months of purchase and it is not resolved within 15 days, you are entitled to a full money-back refund.
Data, privacy & limits
- The connector reads bases, tables and per-table row counts from your NocoDB and writes the corresponding NocoDB Base / NocoDB Table records in Odoo. It never writes back to NocoDB.
- The API token is stored in an administrator-only field.
- In scope today: base import, table import, live row counts, scheduled re-import/reconciliation, dry-run, validation, rollback snapshots, SSRF guard.
- Out of scope / roadmap: importing the actual table records (row data); webhook/push intake from NocoDB; writing any data back to NocoDB.
Support & updates
- Support: bambooforge.labs@gmail.com — answered within 24 hours, setup help included.
- Refund: report a bug within 2 months of purchase; if unresolved within 15 days, full refund.
- Full source is included. Updates track the supported Odoo 19 / NocoDB v2 API line.
Upgrading & version compatibility
This build targets Odoo 19.0. Each Odoo major series (17.0, 18.0, 19.0) has its own dedicated build of this module — always install the build that matches your Odoo version. Mixing a build with a different Odoo series is not supported.
Patch upgrades (same series, e.g. 19.0.1.0.0 → later)
Back up your database and filestore first.
Replace the module folder with the newer build.
Restart Odoo with the module updated:
./odoo-bin -c your.conf -u bambooforge_nocodb_connector -d your_db
Odoo applies any schema/data changes automatically. Your existing records and configuration are preserved.
Cross-version migration (e.g. Odoo 17 → 18)
Upgrading Odoo itself is a database migration handled by Odoo's standard upgrade tooling. When you migrate the database to the next Odoo series, install the matching build of this module for that series. Data created by this module carries over with the database migration.
After any upgrade the module's scheduled actions resume on their normal cadence — no manual re-activation is required.
Uninstallation
You can remove this module at any time from Apps → (this module) → Uninstall, or from the command line. Uninstalling is clean and reversible by reinstalling — but note what is and is not deleted.
What is removed
- The module's own tables and every record in them (23 models, prefixed nocodb.*) — this is the data this module created.
- The menus, actions, views and reports this module installed.
- Its scheduled actions (cron jobs) — they stop immediately on uninstall.
- Connection records, credentials, field mappings, queue jobs and sync logs stored in Odoo.
What is preserved
- Your remote platform is never touched. Uninstalling only removes the Odoo-side connector; products, customers and orders on the external store/service are untouched.
- Records already imported into standard Odoo models (e.g. contacts, products, sales orders) remain — they are ordinary Odoo records once created.
- Attachments and chatter messages on standard records are kept.
As always, take a database backup before uninstalling in production.
Changelog
19.0.1.0.0
Current release for Odoo 19.0. This build includes:
- Odoo 19 connector for NocoDB: two-way row sync (import/export) between selected NocoDB tables and Odoo models, plus base/table metadata import.
- Resilient queue, binder-based idempotency, dry-run, SSRF-guarded.
Feature additions and fixes ship as new builds on the Odoo Apps store; this page and the module's version reflect the current published release. Always keep the build matched to your Odoo series (see Upgrading & version compatibility).
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module