metatroncubeswdev f6886c1b20 fix(community_theme_base): Binary fields can't use config_parameter= directly
Odoo's res.config.settings framework only supports auto-persisting fields
of type boolean/integer/float/char/selection/many2one/datetime via
config_parameter=. theme_logo (Binary) doesn't qualify, and because it was
injected into the *shared* res.config.settings form, it broke every
Settings tab across the whole install (including unrelated ones like
Website/eLearning) - any settings load triggered default_get, which
scans all fields on the model and raised. Caught via live testing in the
browser, not by the automated suite, since the failure only surfaces on
create()/default_get() of a resx.config.settings record, which the
existing tests didn't exercise for other apps' tabs.

Fixed by removing config_parameter from the field and persisting it
manually through get_values()/set_values() overrides, base64-encoded into
the same ir.config_parameter key the QWeb template already reads from -
so the storage format is unchanged, just how it gets there.

Audited every other config_parameter= field across all modules (grep) to
confirm none of the others have the same problem - all are Char/Integer/
Boolean, which are on the whitelist.

Verified against the live container: settings load and save cleanly for
every module's tab, the logo round-trips through upload -> config
parameter -> template read, and a full test run across all 9 modules
(56 tests) plus a sweep of every custom button (call_button, matching
the exact browser click path) and every public/portal page passes clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 22:22:23 -04:00

Community OS

A brand-neutral, resellable suite of Odoo 19 Community modules for community and cultural organizations. First deployment: the Tamil Nadu Cultural Society of Canada (TNCSC).

Vendor: Metatroncube Software Solutions LLP · Waterloo, Ontario Target platform: Odoo 19 Community Edition (LGPL-3) · PostgreSQL 16 · Python 3.12

community_* is a placeholder module prefix. Replace it with a unique vendor prefix before publishing to the Odoo App Store so technical names never collide with anything already listed.

Layered architecture

┌─────────────────────────────────────────────────────────────┐
│  DEPLOYMENT LAYER  (per client — data only, no logic)        │
│  tncsc_deployment:  branding, tiers & prices, chart of        │
│  accounts, email copy, website pages, user groups             │
└───────────────▲─────────────────────────────────────────────┘
                │ depends on
┌───────────────┴─────────────────────────────────────────────┐
│  PRODUCT LAYER  (brand-neutral, resellable, LGPL-3)          │
│  community_membership   event_qr_ticketing   community_school │
│  community_classifieds  community_benefits    community_interac│
│  community_theme_base   community_portal                      │
└───────────────▲─────────────────────────────────────────────┘
                │ depends only on
┌───────────────┴─────────────────────────────────────────────┐
│  ODOO 19 COMMUNITY CORE  (never Enterprise)                  │
└─────────────────────────────────────────────────────────────┘

Product-layer modules never mention a client name, never hardcode a price, a colour, an account code, or an email address. Anything client-specific is a configuration record, seeded only by a *_deployment module. Landing a new client means writing a new clientname_deployment module — the product code never changes.

Modules

Product layer (brand-neutral, sellable)

Module Purpose
community_theme_base Configurable brand tokens (colours, logo, fonts) via settings
community_membership Member profiles, tiers, family grouping, renewals, QR membership card
event_qr_ticketing QR ticket per event registration, staff check-in / verification
community_school Programs, classes, enrollment, attendance, LMS link, parent portal
community_classifieds Member-gated classifieds board with moderation and auto-expiry
community_benefits Benefit centres and per-tier member benefit entitlements
community_interac Interac e-Transfer semi-automated payment provider (Canada)
community_portal Unified member portal dashboard, soft-detects installed modules

Deployment layer (per client — data only)

Module Purpose
tncsc_deployment TNCSC branding, tiers/prices, chart of accounts, email copy, website pages, user groups

Local development

cd deploy
docker compose up

Odoo will be available at http://localhost:8069. The ../addons folder is mounted read-write, so changes to module code are picked up on restart (dev mode reload is enabled in deploy/odoo.conf).

Licensing & resellability guardrails

  1. Every product module is licensed LGPL-3.
  2. No community_* module may depend on an Odoo Enterprise module — see Appendix A in the project plan for the Community-only allowlist.
  3. No client identity (name, email, colour, price, account code) may appear in a product module. This is enforced in CI by scripts/check_brand_leak.py.
  4. All client-variable behaviour is configuration data, seeded by the deployment layer, never a literal in product code.
  5. Every product module ships an App-Store-ready manifest, a tests/ package, and a static/description/index.html listing page.

See CommunityOS_Implementation_Plan_for_Claude_Code.md for the full, phase-by-phase build plan.

CI

.github/workflows/ci.yml installs every module against Odoo 19 + Postgres 16 with --test-enable, runs the brand-leak grep, and lints with flake8 / pylint-odoo.

Description
No description provided
Readme 5.6 MiB
Languages
Python 94.6%
JavaScript 3.3%
HTML 2.1%