Re-extracted the raw HTML of tncsc.com's homepage (the earlier pass used a
summarizing tool that dropped whole sections and paraphrased copy). The
home page was missing entire sections and had shortened text throughout:
- Hero was a single static banner; the real site is a 4-slide carousel
(Bootstrap carousel, real headline/subhead/CTA/image per slide).
- "Watch Our Story" section was missing entirely.
- "Why Join TNCSC?" FAQ section (Where is TNCSC based / How can I join)
was missing entirely.
- The 3 program cards, the "Speak the Language" section, and the final
CTA all had shortened/paraphrased copy - replaced with the real text.
- About section and Upcoming Events now use the real image grids instead
of a single photo each.
- Final CTA copy corrected to "Be a Part of the Legacy" (was invented
copy); kept the live membership-tier price strip merged into it rather
than dropped, since that's real dynamic data the static site can't show.
8 more real images downloaded from tncsc.com for the carousel and events
section. Verified against a live container: fresh install + module test
suite (9/9 passing) + HTTP 200 with correct content on every page.
Replaces the Phase 7 "content to be finalized" placeholder pages with
TNCSC's actual site content (captured 2026-08-20), verified against a
live Odoo container on a dedicated fresh database (tncsc_site):
- Home, About, About/Tamil Nadu, About/Board of Directors (12 real
members), Membership hub, Membership Benefits, Tamil Class, and
Contact pages, with nav restructured to match tncsc.com's real
structure (About and Membership as dropdowns).
- Real images downloaded from tncsc.com and self-hosted under
static/src/img/ instead of hotlinking the WordPress site.
- Home's "Upcoming Events" and the membership pricing tables are wired
to live event.event / community.membership.tier records instead of
being static copies; Tamil Class links to the real /school/register
flow. One real event seeded (Summer Picnic 2026).
- Deliberately not reproduced: tncsc.com's own Sponsors page and Contact
phone number are unmigrated WordPress theme demo placeholders on the
live site itself (generic client-01..09 logos, a non-Canadian demo
number) - confirmed by inspection, not assumed. Contact page uses the
real, verified email and social links instead.
- post_init_hook now also fixes two Odoo website Copy-On-Write gotchas
that silently prevented the new homepage and nav dropdowns from
rendering at all (auto-forked per-website duplicates winning over
this module's records) - see HANDOFF.md for the full explanation.
- Replace the Phase-0 "content to be completed" placeholder Usage section
in every community_* README.rst with the actual features built across
Phases 1-6 (routes, crons, portal pages).
- Add CHANGELOG.rst (19.0.1.0.0) to every community_* module.
- Note independent-vs-bundled module relationships in the root README.
- Fix HANDOFF.md: Phase 8 was already committed (9a24691) and a git
remote is configured, contrary to what it still said; record 9-A
progress and the open gaps (missing banner.png assets, live
--test-enable suite not re-run this session, no v1.0.0 tag yet).
Data-only deployment layer seeding TNCSC's branding (navy/orange/electric-
blue from the plan), 5 membership tiers in CAD (Individual $50, Family $80,
Student $20, Senior $30, Life $500 - the plan's own example figures;
update via Settings once TNCSC confirms real pricing), the
'TNCSC-{year}-{seq}' member-ID format, a Canadian (Ontario/HST) chart of
accounts via l10n_ca plus non-profit-specific accounts (Membership Dues/
Event/Sponsorship/School Fees/Donations Revenue, Deferred Event Revenue
liability, a Stripe clearing account) and a Donations journal, bilingual
EN/Tamil overrides of two membership email templates (Tamil text is a
best-effort draft only, explicitly flagged as needing native-speaker
review before go-live), five placeholder website pages (Home/About/Tamil
School/Sponsors/Contact), and TNCSC-named role groups (Board Admin,
Treasurer, Events Officer, School Coordinator, Teacher, Classifieds
Moderator) that imply the existing generic product-layer groups rather
than defining new permission logic.
Chasing the chart-of-accounts setup down to a genuinely working state
took real digging: setting company.country_id on a brand-new company
auto-schedules this Odoo build's own chart-template installer via a
precommit hook (res.company.install_l10n_modules), which races an
explicit try_loading('ca_2023', ...) call made in the same install
transaction and silently replaces its result afterwards (reverting
currency to USD, chart_template to 'generic_coa', and deleting the custom
accounts) - confirmed via raw SQL checks that the correct state exists
right up until the post_init_hook transaction commits, and is gone by the
time the install process exits. Since the precommit auto-trigger only
ever fires once per company (guarded by chart_template being unset), a
second call from a separate transaction is immune to the race. The fix:
the actual setup logic lives in an idempotent res.company._tncsc_setup_
accounting() method (models/res_company.py - a narrow, documented
exception to "no models" in the deployment layer, since cramming this
into a sandboxed ir.cron code string wasn't practical), called as a
best-effort from post_init_hook and guaranteed by a daily safety-net cron
que runs in its own transaction. Also hit two smaller, separate bugs on
the way: ir.cron code execution forbids direct attribute assignment
(STORE_ATTR) in its sandbox, and Html config_parameter fields must not be
wrapped in CDATA in data XML.
Verified end-to-end on a genuinely fresh database (not the long-lived dev
DB, which already has posted entries and correctly refuses a currency
change): installed tncsc_deployment alone, pulling in all 8 product
modules plus l10n_ca as dependencies, confirmed the post-install state via
raw SQL, manually triggered the safety-net cron and confirmed it reached
the fully-correct state (CAD, ca_2023, 355 accounts including all 7
custom ones, the Donations journal, tier products linked to the dues
account), confirmed the cron is idempotent on a second run, and ran the
full test suite (9/9 passing) with the same deterministic setup called
from the test transaction directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reported: clicking "Post a Listing" on /classifieds while logged out threw
a raw 500 instead of prompting login.
Root cause is upstream, in this Odoo 19 build's own http.py: when
auth='user' raises SessionExpiredException for an anonymous visitor,
Request._serve_db's `finally: self.env = None` clears the request env
before the exception reaches the website error handler, which then tries
to build the login redirect via self.env['ir.http']._redirect(...) and
crashes with TypeError: 'NoneType' object is not subscriptable. This
isn't specific to any one route - it reproduces on every auth='user' +
website=True page hit anonymously, including stock Odoo's own /my (traced
this back to the true cause rather than continuing to treat it as an
unrelated environment quirk, since it now has a real reported symptom).
Since core can't be patched here, worked around it at the route level
across all 9 affected pages (classifieds new/my/renew, membership
my/renew/card, benefits my, school attendance, portal my/school, event
checkin): switched from auth='user' to auth='public' and added an
explicit `if request.env.user._is_public(): return request.redirect(...)`
check at the top of each handler, before Odoo's own auth layer ever gets
a chance to raise. The jsonrpc AJAX endpoints (attendance save, checkin
scan/dashboard) were left on auth='user' since they return a JSON error
rather than attempting an HTML redirect, so they don't hit this path.
Verified against a live Odoo 19 + Postgres 16 container: reproduced the
original crash pre-fix, then confirmed all 9 previously-broken routes now
303-redirect to /web/login?redirect=<path> when hit anonymously, that the
login page carries the redirect target, that logged-in access is
unaffected (200), and that the separate "logged in but lacking a required
group" case (event check-in without Registration Desk) still degrades
gracefully to a clean 403 rather than a crash. Full regression: 48/48
tests pass across the six touched modules.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
community_theme_base: brand tokens (primary/secondary/accent colour, logo,
heading/body font) exposed via res.config.settings, backed by
ir.config_parameter with a neutral default palette. A theme_css_vars QWeb
template renders them as CSS custom properties and is injected into both
website.layout (xpath into //head) and web.basic_layout (used by every
PDF report, including community_membership's card and event_qr_ticketing's
ticket) - so any deployment rebrands with data only. Confirmed env['model']
is accessible bare inside arbitrary QWeb templates (checked core usage in
web/report_templates.xml and website_templates.xml first) before relying
on it for the injection.
community_portal: extends portal.portal_my_home with cards for Membership,
Events, School, Benefits, and Classifieds, each gated by an inline
ir.module.module installed-check so a card is fully absent (not just
zero-count) when its module isn't installed - this is the piece that
finally wires up community_membership's membership_count counter, which
Session 1-C had already implemented but nothing was rendering yet. Adds
counters for the other four product modules (none of which had their own
portal home counter) and a new /my/school page listing a parent's
children's enrollments and attendance.
Verified against a live Odoo 19 + Postgres 16 container, automated (6
tests) and manually per the Phase 6 gate exactly: set a custom primary
colour via config parameter and confirmed it appears both on a real public
page (HttpCase hitting '/') and the live /my dashboard; then uninstalled
community_classifieds via button_immediate_uninstall and confirmed /my
still returned 200 with the "My Classifieds" card gone and no error,
before reinstalling it to restore the dev environment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The plan flags this as the highest-risk module since the payment provider
API is strict and version-sensitive. Before writing any code, read Odoo
19's own payment_custom module (its wire-transfer provider) end to end as
a reference, since it's the closest first-party analog to a manual/
offline payment flow - this avoided the trial-and-error that hit the
other modules and got the core logic right on the first install attempt.
payment.provider gains code='interac' (via selection_add, same pattern
payment_custom uses for 'custom') plus interac_recipient_email
(required_if_provider='interac' - Odoo only enforces this when the
provider's state is enabled/test, so the module ships a disabled,
unconfigured provider record and the deployment layer configures + enables
it, keeping client specifics out of product code) and a configurable
interac_deadline_hours.
Flow: selecting Interac at checkout calls _apply_updates, which sets the
transaction 'pending' and emails instructions (recipient address, amount,
reference, deadline) via a mail.template - no dynamic per-transaction data
needs to live in the static provider-level pending_msg field, since the
reference/amount are already shown on Odoo's generic payment status page.
A "Pending Interac Payments" admin list (Interac Payment Verifier group)
has a one-click "Payment Received" button calling action_confirm_interac_
payment (-> _set_done, which triggers Odoo's normal order/invoice
reconciliation - no need to reimplement that). An hourly cron cancels
unconfirmed pending transactions past the deadline and emails a
cancellation notice.
Verified against a live Odoo 19 + Postgres 16 container: 4/4 automated
tests pass, plus a full manual live run of both cycles the plan's gate
asks for - drove a transaction through the actual /payment/interac/process
controller to pending (confirmed the instructions email), used the
treasurer action to confirm it to 'done', and separately backdated a
second transaction's last_state_change and triggered the auto-cancel cron
via ir.cron's method_direct_trigger, confirming both the state change to
'cancel' and the cancellation email.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
community_classifieds: a member-gated classifieds board. community.classified
(title/category/description/up-to-3-images via a child .image model/contact
info/state) with a public board at /classifieds, detail pages that track
view_count, portal posting at /classifieds/new (soft-detects
community_membership - blocks non-active-members only if that module is
installed, otherwise anyone logged in can post), a "my listings" portal
page with self-service renew, and an admin moderation queue
(publish/reject). Daily crons expire past-due listings and send a 7-day
expiry warning; a new-submission notice goes out to the Classifieds
Moderator group. Listing duration is configurable (Settings), never
hardcoded.
community_benefits: community.benefit.partner (benefit centres) offer
community.benefit entitlements scoped to specific community_membership
tiers via tier_ids. community.benefit.redemption logs a redemption but
its create() is guarded by a constraint that re-checks the same
active-membership condition the membership QR verification page uses
(membership_state in active/renewal_due) plus tier entitlement, refusing
the redemption otherwise. Public directory at /benefits, portal page at
/my/benefits listing only benefits the member's tier actually entitles
them to.
Two more real Odoo 19 API changes hit here: search-view <group> elements
for "Group By" sections no longer accept a `string` attribute (must use
`name` only - same fix as community_membership's partner search view,
applied here to a fresh module), and res.groups.users was renamed to
user_ids.
Verified against a live Odoo 19 + Postgres 16 container: 7+4 automated
tests pass, plus a full manual live run covering the Phase 4 gate exactly -
confirmed a non-member is blocked from /classifieds/new, activated a real
membership, posted a classified (pending_review), published it via the
moderator action, confirmed it appears on the public board and detail
page with view_count incrementing, entitled a tier to a benefit, logged a
redemption for the active member, confirmed it shows on /my/benefits, and
confirmed redemption creation is refused for a non-member.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the multi-step website registration at /school/register (parent ->
student -> class), carrying state across steps in the request session
(auth='public' - a family with no account yet can register). Finalizing
creates/finds the parent partner by email, creates the child partner +
student, and creates the enrollment as 'enrolled' or 'waitlist' depending
on whether the chosen class.fee_product_id/max_students still has room -
generating a draft fee invoice when the class has a fee (a new
class.fee/fee_product_id, following the same auto-created-product pattern
as community_membership's tiers).
LMS glue: enrollment create/write now auto-enrols the student's partner
into the class's slide.channel via _action_add_members() when state
becomes 'enrolled', and deactivates the slide.channel.partner membership
on withdrawal. An hourly cron (_cron_promote_waitlist) fills freed seats
from the waitlist in enrollment-date order and emails the parent.
Adds scripts/migrate_classroom.py: a standalone, dependency-free (stdlib
only) JSON-RPC script that reads a title,url CSV and creates slide.slide
records in a target channel - YouTube links become published video slides
(source_type='external' lets Odoo's own compute fields resolve youtube_id
automatically), everything else becomes an unpublished document slide
flagged for manual re-upload/review, since the script can't read Google
Drive content itself. Idempotent by (channel_id, title); --dry-run and
--force supported.
Verified against a live Odoo 19 + Postgres 16 container: 14/14 automated
tests pass, plus full manual live runs - walked all three registration
steps over real HTTP (with CSRF tokens) and confirmed the resulting
enrollment and draft invoice; ran the migration script twice against a
real channel and confirmed the second run skipped both already-created
slides, with the YouTube slide's youtube_id correctly auto-derived.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Session 3-A - core models: community.school.term, .level (admin-defined,
so the same module fits a Grade 1-12 school or a Beginner-Advanced
language school with no code change), .class (auto-creates a linked
slide.channel for LMS glue), .student, .enrollment, and .attendance, plus
is_teacher on res.partner. Class enrolled_count and enrollment
attendance_rate are stored/non-stored computes driven by the
enrollment/attendance one2many chains.
Session 3-B - teacher attendance + at-risk reporting: a portal page at
/school/attendance (auth='user', scoped to classes where teacher_id
matches the logged-in user's partner - works whether the teacher is an
internal or portal user) with a roster and batch save, built as a v19
Interaction (same pattern as event_qr_ticketing's check-in page). Marking
a student absent queues a configurable notice to the parent partner.
Enrollment.is_at_risk flags students below a configurable attendance
threshold (School settings page, same <app>/<block>/<setting> pattern as
community_membership), plus an admin pivot attendance report and an
At-Risk Students list.
Verified against a live Odoo 19 + Postgres 16 container: 14/14 automated
tests pass (class/slide-channel creation, enrolled_count tracking incl.
withdrawal, attendance_rate and at-risk computation, unique
enrollment+date constraint, absence email queuing), plus a full manual
live run - created a term/level/class/student/enrollment via JSON-RPC,
loaded the actual /school/attendance page as the teacher, POSTed a batch
save marking the student absent, and confirmed both the attendance record
and the queued "Absence notice" mail.mail record.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Adds a QWeb PDF "Membership Card" report (85x54mm landscape, custom
report.paperformat) showing the company logo, member name/ID, tier, and
a QR code generated with the qrcode library (embedded as a base64 PNG via
a non-stored res.partner.membership_card_qr compute field). The QR encodes
a public verification URL built from ir.config_parameter's web.base.url.
Adds the public GET /membership/verify/<member_id> controller: shows
valid/expired/not-found with no personal data beyond name (and tier, for
valid members) - internal states like 'invoiced'/'none' are deliberately
reported as not-found so partial signup state isn't leaked.
Adds the member portal: /my/membership (status/tier/expiry), /my/membership/
renew (finds or creates a draft renewal invoice, redirects to the existing
portal invoice page), and /my/membership/card (PDF download) - plus a
"Membership" entry card on the main /my portal home page. Since
community_theme_base doesn't exist yet (that's Phase 6), the card uses
res.company.logo rather than a theme setting - still brand-neutral,
just resolved from the standard company record for now.
Verified against a live Odoo 19 + Postgres 16 container, both via the
test suite (12/12 tests: unit tests, HttpCase tests hitting the real verify
endpoint for valid/expired/unknown IDs) and by hand end-to-end - created a
tier and member over JSON-RPC, activated the membership, fetched the live
/membership/verify/ page, and rendered the actual PDF card via
/report/pdf/... (11.7KB single-page PDF, confirmed non-blank).
Along the way, hit a third real Odoo 19 API change: res.users.groups_id
was renamed to group_ids.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the daily membership renewal cron (_cron_process_membership_renewals):
sends a "renewal upcoming" reminder at each non-final configured offset,
flips state to renewal_due and sends a "renewal due" notice at the final
(smallest) offset, and on expiry flips to 'expired', sends an expiry notice,
and creates a draft renewal invoice for the member's tier product.
Email templates (renewal_upcoming, renewal_due, membership_expired) use
Odoo 19's current mail.template syntax ({{ }} subject/QWeb t-out body) -
the plan referenced the older ${object...} syntax, which v19 no longer
uses. Org name is pulled via a new non-stored res.partner.membership_org_name
compute field backed by ir.config_parameter, never hardcoded.
Also had to adapt the ir.cron data record: Odoo 19 removed 'numbercall'
entirely (ir.cron now delegates most fields to a linked ir.actions.server
under the hood, though name/model_id/state/code are still settable
directly on the record, per the core mail module's own cron definitions).
Verified against a live Odoo 19 + Postgres 16 container: module upgrades
clean, all 8 tests pass (4 from 1-A + 4 new: non-final-offset reminder,
final-offset state flip to renewal_due, expiry creates a draft invoice +
notice, no action outside any offset window).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the membership foundation: community.membership.tier (admin-configurable
tiers, each auto-creating a linked invoicing product), res.partner membership
fields (member ID, tier, state, family grouping, volunteer tracking), and a
res.config.settings page (org name, member-ID format, renewal offsets, portal
toggle) - all backed by ir.config_parameter so nothing is hardcoded.
Member IDs are generated on activation via a configurable format string
({year}/{seq}) resolved against an ir.sequence. Adds the Membership Manager
group/menu and views (tier list/form, partner form tab, list columns, search
filters, settings page).
Along the way, hit two real Odoo 19 API changes vs. older tutorials/docs:
res.groups.category_id was replaced by privilege_id -> res.groups.privilege,
and module settings pages now use the <app>/<block>/<setting> pattern
inherited from base.res_config_settings_view_form rather than raw divs.
Verified by upgrading the module against a live Odoo 19 + Postgres 16
container: installs clean, all 4 tests pass (tier->product creation, member
ID generation on activation, one-time/lifetime tiers never expire,
configurable ID format), and the module still installs cleanly for its
dependents (community_benefits, tncsc_deployment).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Scaffolds the CommunityOS monorepo per the implementation plan: 8
brand-neutral product modules (community_theme_base, community_membership,
event_qr_ticketing, community_school, community_classifieds,
community_benefits, community_interac, community_portal) plus the
tncsc_deployment client layer, each with an App-Store-ready manifest,
LGPL-3 license, and empty security/data/demo/tests/views scaffolding.
Adds deploy/docker-compose.yml (Odoo 19 CE + Postgres 16), CI workflow
that installs all modules with --test-enable, and scripts/check_brand_leak.py
+ check_manifests.py enforcing the no-client-identity-in-product-code and
manifest-completeness rules. Verified locally: all 9 modules install clean
on a fresh Odoo 19 database, and the brand-leak check correctly fails when
a client term is added to a product module and passes once removed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
metatroncubeswdev