Only community_membership and community_school had application: True;
the other 6 product modules (community_benefits, community_classifieds,
community_interac, community_portal, community_theme_base,
event_qr_ticketing) had application: False despite being fully installed
and functional. Odoo's Apps screen filters to application=True by
default, so they were invisible there even though Technical > Installed
Modules showed them correctly - looked like they weren't installed.
Per the plan's own resellability rule ("each module is independently
installable and independently sellable"), every community_* product
module should be a discoverable Apps-grid entry. tncsc_deployment stays
application: False - it's the hidden client-config layer, not something
anyone browses to install on its own.
Verified on tncsc_site: -u upgrade picked up the flag for all 6, and the
site still serves every page (/, /about, /membership, /tamil-school,
/contact, /event) after the upgrade.
- 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).
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>
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>
