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>
