From 8dd97dec9b2214d5f46ca238945330fe20f36f67 Mon Sep 17 00:00:00 2001 From: metatroncubeswdev Date: Thu, 20 Aug 2026 09:23:32 -0400 Subject: [PATCH] docs(phase-9-a): fill in real module READMEs, add CHANGELOGs, fix stale HANDOFF - 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). --- HANDOFF.md | 53 +++++++++++++--------- README.md | 13 ++++++ addons/community_benefits/CHANGELOG.rst | 9 ++++ addons/community_benefits/README.rst | 10 +++- addons/community_classifieds/CHANGELOG.rst | 9 ++++ addons/community_classifieds/README.rst | 11 ++++- addons/community_interac/CHANGELOG.rst | 9 ++++ addons/community_interac/README.rst | 14 +++++- addons/community_membership/CHANGELOG.rst | 12 +++++ addons/community_membership/README.rst | 15 +++++- addons/community_portal/CHANGELOG.rst | 8 ++++ addons/community_portal/README.rst | 10 +++- addons/community_school/CHANGELOG.rst | 14 ++++++ addons/community_school/README.rst | 17 ++++++- addons/community_theme_base/CHANGELOG.rst | 8 ++++ addons/community_theme_base/README.rst | 10 +++- addons/event_qr_ticketing/CHANGELOG.rst | 10 ++++ addons/event_qr_ticketing/README.rst | 11 ++++- 18 files changed, 206 insertions(+), 37 deletions(-) create mode 100644 addons/community_benefits/CHANGELOG.rst create mode 100644 addons/community_classifieds/CHANGELOG.rst create mode 100644 addons/community_interac/CHANGELOG.rst create mode 100644 addons/community_membership/CHANGELOG.rst create mode 100644 addons/community_portal/CHANGELOG.rst create mode 100644 addons/community_school/CHANGELOG.rst create mode 100644 addons/community_theme_base/CHANGELOG.rst create mode 100644 addons/event_qr_ticketing/CHANGELOG.rst diff --git a/HANDOFF.md b/HANDOFF.md index 06ad23e..abf1e83 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -17,8 +17,8 @@ file is the "where things actually stand" companion to it. | 5 | `community_interac` (Interac e-Transfer payment provider) | ✅ Done, committed | | 6 | `community_theme_base` + `community_portal` | ✅ Done, committed | | 7 | `tncsc_deployment` (client config layer) | ✅ Done, committed | -| 8 | TNCSC data migration scripts | ✅ Written and verified live, **not committed** — see below | -| 9 | Packaging for resale + production go-live | ⬜ Not started | +| 8 | TNCSC data migration scripts | ✅ Done, committed (`9a24691`) | +| 9 | Packaging for resale + production go-live | 🟡 9-A in progress (see below); 9-B not started | Every phase 0–7 commit was verified against a **live** Odoo 19 + Postgres 16 container before being committed — not just written and assumed to work. @@ -27,9 +27,7 @@ documents what was built and how it was verified, including several real Odoo 19 API changes that don't match older docs/tutorials (see "Gotchas" below for the index). -**No git remote is configured.** This repo only exists on this machine -right now. Before handing off to a team, push it somewhere (GitHub/GitLab/ -etc.) — see "Handing off to a team" below. +**Git remote is configured**: `origin` -> `https://git.metatroncube.in/admin/TNCSC_Odoo.git`. ## Resuming the dev environment @@ -56,11 +54,10 @@ docker compose up -d ``` This bit repeatedly during development — don't skip it when testing. -## Phase 8 — exactly where it was left off +## Phase 8 — done, committed (`9a24691`) -All three migration scripts exist and have been verified against a **live** -Odoo instance, but **the work is not committed yet** (see "To pick this back -up" below for why). +All three migration scripts exist, are committed, and have been verified +against a **live** Odoo instance (see "How each was tested" below). - `scripts/_migration_common.py` — shared JSON-RPC helpers (auth, execute_kw, CSV normalization, a `MigrationReport` class) for the migration scripts. @@ -146,19 +143,33 @@ before it's mistaken for anything resembling real data. ### To pick this back up -The scripts work and are proven idempotent, but haven't been committed — -do that first (a `feat: Phase 8 migration scripts` commit, following the -same "verified against a live container before committing" convention as -every other phase), then either wait for real TNCSC export samples to -validate the assumed CSV schemas against, or move on to Phase 9. +Either wait for real TNCSC export samples to validate the assumed CSV +schemas against, or move on to Phase 9. -## Phase 9 — not started +## Phase 9 — 9-A in progress, 9-B not started Two sub-parts with very different risk profiles: -- **9-A (productize)**: static description pages, READMEs, CHANGELOGs, - release tagging for the product modules. Safe to do autonomously. -- **9-B (go-live)**: SSL, DNS cutover, firewall rules, backups on a **real - production server**. This needs a human in the loop with actual server +- **9-A (productize)**: safe to do autonomously. Done so far — every + `community_*` module has `static/description/index.html`, a real + `README.rst` (Usage sections filled in past the Phase-0 placeholder), + and a `CHANGELOG.rst`; manifests pass `scripts/check_manifests.py`. + Still open: + - Every product manifest's `images` key points at + `static/description/banner.png`, but no module actually has that + file — the Apps-list/App-Store banner image doesn't exist yet. Needs + a real designed asset per module, not a placeholder. + - No `v1.0.0` git tag yet, and no release report — holding off on both + until the banner-image gap above is resolved and the full + `--test-enable` suite has actually been run against live Odoo (this + session had no Docker available, so only the static checks — + brand-leak grep, manifest completeness — were re-verified, not the + live module install/tests). + - No role guides (admin/treasurer/teacher/parent) written yet. +- **9-B (go-live)**: not started. `deploy/odoo.conf` is still dev config + (`list_db = True`, `proxy_mode = False`, no `workers`) and + `deploy/nginx-communityos.conf` is an explicit "development skeleton" — + SSL, DNS cutover, firewall rules, and backups on a **real production + server** all remain. This needs a human in the loop with actual server access/credentials — don't let an agent run this unattended. ## Gotchas discovered this build (Odoo 19 API drift + environment quirks) @@ -206,8 +217,8 @@ re-discovering it: ## Handing off to a team -1. **Push this repo to a real remote** (GitHub/GitLab/etc.) — right now it - only exists locally. +1. Repo is already pushed to `origin` (see above) — confirm the team has + access to `git.metatroncube.in`. 2. Point them at `CommunityOS_Implementation_Plan_for_Claude_Code.md` (the plan) and this file (current status). 3. They'll need Docker Desktop (or equivalent) to run `deploy/docker-compose.yml` diff --git a/README.md b/README.md index 75b803f..5bb0c65 100644 --- a/README.md +++ b/README.md @@ -59,6 +59,19 @@ product code never changes. |---|---| | `tncsc_deployment` | TNCSC branding, tiers/prices, chart of accounts, email copy, website pages, user groups | +### Independent vs. bundled + +Every product module installs standalone on a stock Odoo 19 CE with only +its declared Community-core dependencies — none require another +`community_*` module to function, with one deliberate exception: +`community_benefits` hard-depends on `community_membership` (a benefit is +entitled per membership tier, so the dependency is intrinsic to what it +does). `community_school` and `community_classifieds` *soft*-detect +`event_qr_ticketing`/`community_membership` when present and degrade +gracefully without them. `community_portal` soft-detects all of the above +and only renders cards for whichever are installed. This means each module +can be sold and installed on its own, or bundled as the full suite. + ## Local development ```bash diff --git a/addons/community_benefits/CHANGELOG.rst b/addons/community_benefits/CHANGELOG.rst new file mode 100644 index 0000000..5e5b45f --- /dev/null +++ b/addons/community_benefits/CHANGELOG.rst @@ -0,0 +1,9 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: benefit centres/vendors, per-tier benefit entitlements, + and a redemption log verified against the membership QR-verify endpoint. +* Member portal page at ``/my/benefits`` and a public directory at + ``/benefits``. diff --git a/addons/community_benefits/README.rst b/addons/community_benefits/README.rst index 3256a78..f0ff7a4 100644 --- a/addons/community_benefits/README.rst +++ b/addons/community_benefits/README.rst @@ -11,8 +11,14 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 4). +* Admins register benefit centres/vendors (``community.benefit.partner``) + and the benefits they offer (``community.benefit``), each entitled to one + or more membership tiers. +* Members see the benefits their tier entitles them to at ``/my/benefits``; + the public directory of participating centres is at ``/benefits``. +* A benefit centre logs a redemption (``community.benefit.redemption``) + after confirming the member is active via the membership QR-verify + endpoint, giving a verifiable usage trail per member/benefit. Credits ======= diff --git a/addons/community_classifieds/CHANGELOG.rst b/addons/community_classifieds/CHANGELOG.rst new file mode 100644 index 0000000..68482bf --- /dev/null +++ b/addons/community_classifieds/CHANGELOG.rst @@ -0,0 +1,9 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: public classifieds board, member-gated posting + (soft-detects ``community_membership``), admin moderation queue. +* Auto-expiry, 7-day expiry warning, and new-submission notification + crons. diff --git a/addons/community_classifieds/README.rst b/addons/community_classifieds/README.rst index dd4191f..ad0213b 100644 --- a/addons/community_classifieds/README.rst +++ b/addons/community_classifieds/README.rst @@ -10,8 +10,15 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 4). +* Public board at ``/classifieds`` (list, filter, search); detail page at + ``/classifieds/`` increments a view counter. +* Posting at ``/classifieds/new`` requires portal login, and an active + membership if ``community_membership`` is installed (soft-detected). +* Submissions start ``pending_review``; admins publish or reject from the + moderation queue. Listings auto-expire on a configurable number of days + after posting, with a 7-day expiry warning email and an admin + notification on every new submission. Posters manage their own listings + and renew them at ``/classifieds/my`` and ``/classifieds//renew``. Credits ======= diff --git a/addons/community_interac/CHANGELOG.rst b/addons/community_interac/CHANGELOG.rst new file mode 100644 index 0000000..f32d1bf --- /dev/null +++ b/addons/community_interac/CHANGELOG.rst @@ -0,0 +1,9 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: Interac e-Transfer ``payment.provider`` for the Odoo 19 + payment framework, with configurable instructions email. +* Treasurer "Pending Interac" admin view with one-click confirmation, and + an auto-cancel cron for unconfirmed transactions. diff --git a/addons/community_interac/README.rst b/addons/community_interac/README.rst index a045473..b06f5ee 100644 --- a/addons/community_interac/README.rst +++ b/addons/community_interac/README.rst @@ -11,8 +11,18 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 5). +* Registers as a standard Odoo 19 ``payment.provider``/``payment.method`` — + select "Interac e-Transfer" at any checkout that uses the payment + framework (membership renewal, event registration, school fees). +* Choosing it sets the transaction to ``pending`` and emails configurable + instructions (recipient e-transfer address, amount, reference code + ``REF-{tx}``, deadline) — recipient address, org name, and copy all come + from the provider configuration, never hardcoded. +* Treasurers confirm receipt from the **Pending Interac** admin view with a + one-click "Payment received," which marks the transaction ``done`` and + confirms the linked order/registration/invoice. +* An unconfirmed transaction auto-cancels (with a notification email) after + a configurable window, via a scheduled cron. Credits ======= diff --git a/addons/community_membership/CHANGELOG.rst b/addons/community_membership/CHANGELOG.rst new file mode 100644 index 0000000..dc462ac --- /dev/null +++ b/addons/community_membership/CHANGELOG.rst @@ -0,0 +1,12 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: configurable membership tiers, ``res.partner`` extension + (member ID, tier, state, family grouping, volunteer hours), and + membership settings. +* Renewal automation: daily cron, configurable email templates, draft + renewal invoices. +* QR membership card (QWeb PDF), public verification endpoint, and + self-service member portal at ``/my/membership``. diff --git a/addons/community_membership/README.rst b/addons/community_membership/README.rst index fe770ec..166b915 100644 --- a/addons/community_membership/README.rst +++ b/addons/community_membership/README.rst @@ -15,8 +15,19 @@ Settings > Members > Membership Settings. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 1). +* Define tiers under **Members > Configuration > Tiers** (name, code, price, + period). Each tier auto-creates its membership product. +* A partner's ``membership_member_id`` is generated on activation using the + format string configured in Membership Settings (default + ``MEM-{year}-{seq}``). +* A daily cron moves members to ``renewal_due`` at the configured reminder + offsets and to ``expired`` on expiry, sending the matching email template + and creating a draft renewal invoice for review. +* Members self-serve at ``/my/membership`` (status, tier, expiry, renew, + download card) and can be verified publicly, without exposing personal + data, at ``/membership/verify/``. +* The QR membership card is a QWeb PDF report (85mm x 54mm) whose QR code + encodes the verification URL. Credits ======= diff --git a/addons/community_portal/CHANGELOG.rst b/addons/community_portal/CHANGELOG.rst new file mode 100644 index 0000000..6b4beef --- /dev/null +++ b/addons/community_portal/CHANGELOG.rst @@ -0,0 +1,8 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: unified member dashboard at ``/my`` that soft-detects + whichever Community OS product modules are installed and renders only + their cards. diff --git a/addons/community_portal/README.rst b/addons/community_portal/README.rst index 5c0b6ca..658089b 100644 --- a/addons/community_portal/README.rst +++ b/addons/community_portal/README.rst @@ -11,8 +11,14 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 6). +* Renders a member dashboard at ``/my`` that soft-detects whichever product + modules are installed and shows only their cards: membership status (if + ``community_membership``), upcoming registered events/tickets (if + ``event_qr_ticketing``), a child's schedule/attendance at ``/my/school`` + (if ``community_school``), entitled benefits (if ``community_benefits``), + and a member's own classifieds (if ``community_classifieds``). +* Uninstalling any one of those product modules removes its card without + breaking the rest of the dashboard. Credits ======= diff --git a/addons/community_school/CHANGELOG.rst b/addons/community_school/CHANGELOG.rst new file mode 100644 index 0000000..65055c3 --- /dev/null +++ b/addons/community_school/CHANGELOG.rst @@ -0,0 +1,14 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: terms, configurable levels, classes, students, + enrollment, and attendance models. +* Teacher attendance portal at ``/school/attendance`` with batch save and + configurable absence emails; admin attendance pivot report and + at-risk flag. +* Multi-step parent registration at ``/school/register`` with automatic + waitlisting, and ``website_slides`` LMS glue (auto channel creation and + enrolment). +* ``scripts/migrate_classroom.py`` for bulk-importing existing assignments. diff --git a/addons/community_school/README.rst b/addons/community_school/README.rst index 0f76402..c172ffd 100644 --- a/addons/community_school/README.rst +++ b/addons/community_school/README.rst @@ -11,8 +11,21 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 3). +* Admins define terms, levels (e.g. Beginner..Advanced, or Grade 1-12 — + entirely configurable), and classes; teachers are ``res.partner`` records + flagged ``is_teacher``. +* Parents register at ``/school/register`` in three steps (parent -> student + -> class + payment), which creates the child contact, student record, an + enrollment, and a fee invoice. Full classes fall back to a waitlist that + is notified automatically when a seat frees up. +* Teachers take attendance from ``/school/attendance`` (today/this week + roster, batch Present/Absent/Late/Excused save); an ``absent`` mark + queues a configurable email to the parent. Admins get an attendance + pivot report and an "at-risk" flag below a configurable threshold. +* Each class auto-creates a ``website_slides`` channel; enrolling/ + withdrawing a student enrols/unenrols them from it automatically. +* ``scripts/migrate_classroom.py`` bulk-imports existing assignments (CSV of + title + Drive/YouTube URL) as slide records. Credits ======= diff --git a/addons/community_theme_base/CHANGELOG.rst b/addons/community_theme_base/CHANGELOG.rst new file mode 100644 index 0000000..3689b22 --- /dev/null +++ b/addons/community_theme_base/CHANGELOG.rst @@ -0,0 +1,8 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: brand tokens (colours, logo, fonts) exposed via + settings and injected as CSS variables across the website, member + portal, and PDF reports. Neutral default layout, no client colours. diff --git a/addons/community_theme_base/README.rst b/addons/community_theme_base/README.rst index b305070..d4992fe 100644 --- a/addons/community_theme_base/README.rst +++ b/addons/community_theme_base/README.rst @@ -16,8 +16,14 @@ Settings > Website > Community OS Theme. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 6). +* Set primary/secondary/accent colours, logo, and heading/body fonts once + under Settings > Website > Community OS Theme. +* Those tokens are injected as CSS variables across the public website, the + member portal, and PDF reports (e.g. the membership card), so a new + deployment can rebrand entirely with data — no SCSS edits required. +* Ships with a neutral default navbar/footer layout and no client colours + in code; a fresh install looks generic until a deployment module (or an + admin) sets its own brand tokens. Credits ======= diff --git a/addons/event_qr_ticketing/CHANGELOG.rst b/addons/event_qr_ticketing/CHANGELOG.rst new file mode 100644 index 0000000..f1d4af3 --- /dev/null +++ b/addons/event_qr_ticketing/CHANGELOG.rst @@ -0,0 +1,10 @@ +Changelog +========= + +19.0.1.0.0 (2026-08-17) +~~~~~~~~~~~~~~~~~~~~~~~~ +* Initial release: signed QR ticket per event registration, attached to the + standard CE registration confirmation email. +* Staff check-in / verification screen at ``/event/checkin``, with + duplicate and forged-token guards, and a per-event registered vs. + checked-in dashboard. diff --git a/addons/event_qr_ticketing/README.rst b/addons/event_qr_ticketing/README.rst index a77ccc5..9c4b25f 100644 --- a/addons/event_qr_ticketing/README.rst +++ b/addons/event_qr_ticketing/README.rst @@ -11,8 +11,15 @@ Install as any Odoo module. Usage ===== -Content to be completed as the module is built out (see project plan, -Phase 2). +* Every ``event.registration`` gets a unique ``ticket_ref`` and a QR code + encoding a per-database-signed token, attached automatically to the + standard CE registration confirmation email as a PDF ticket. +* Staff check attendees in at ``/event/checkin/`` (camera scan or + manual ticket-ref entry, restricted to the Event User group). The scan + endpoint verifies the token signature and rejects forged or already + used tickets. +* A per-event dashboard on the same page shows registered vs. checked-in + counts in real time. Credits =======