Extends stock event.registration with a signed QR ticket system, built to
complement rather than duplicate Odoo 19's existing barcode/badge
infrastructure. ticket_ref ('TIX-{event}-{seq}') and a QR code encoding
"ticket_ref|hmac_token" are added; the HMAC is signed with Odoo's own
per-database secret (ir.config_parameter 'database.secret', the same
mechanism core uses for password-reset tokens), so a copied/edited
ticket_ref without the matching signature is rejected as forged. A "Event
Ticket (QR)" PDF report is auto-attached to the core registration
confirmation email by adding it to event.event_subscription's
report_template_ids - no override of core mail-sending logic needed.
Adds the missing piece core doesn't provide: a mobile-friendly staff
check-in page at /event/checkin (gated on event.group_event_registration_desk),
built as a v19 "Interaction" (registry.category("public.interactions"),
the current replacement for legacy publicWidget) with manual ticket-ref
entry always available and camera scanning via the browser's native
BarcodeDetector API - avoiding a third-party CDN dependency and its
security/offline-reliability tradeoffs. Guards against forged tokens and
double check-in; a live per-event registered-vs-checked-in dashboard.
Two more real Odoo 19 surprises hit here: event.event has no more `state`
field at all (replaced by a stage_id/event.stage kanban system - my
check-in page's event picker now filters by date_end instead), and a
route type='json' should be type='jsonrpc' (json still works but is
deprecated).
Verified against a live Odoo 19 + Postgres 16 container: 9/9 tests pass
(ticket generation/uniqueness, valid/duplicate/forged/tampered token
handling, manual lookup), plus a full manual live run over HTTP - created
an event and registration via JSON-RPC, confirmed ticket_ref generation,
authenticated a session, hit /event/checkin/scan for a real check-in and
duplicate rejection, confirmed dashboard counts update, and loaded the
actual /event/checkin page (title, camera-button markup, and our JS
present in the served frontend bundle).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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
- Every product module is licensed
LGPL-3. - No
community_*module may depend on an Odoo Enterprise module — seeAppendix Ain the project plan for the Community-only allowlist. - 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. - All client-variable behaviour is configuration data, seeded by the deployment layer, never a literal in product code.
- Every product module ships an App-Store-ready manifest, a
tests/package, and astatic/description/index.htmllisting 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.