group_classifieds_moderator wasn't implied by anything an Administrator
already has, so a standalone install of just this module (no deployment
layer to seed role groups - the exact scenario this module's soft
membership-detection is designed for) left the installing admin unable
to see the Classifieds app or Moderation queue at all until someone
manually granted the group.
Make base.group_system imply group_classifieds_moderator instead, so
every Odoo Administrator gets it automatically with zero extra wiring.
Verified on a from-scratch database with only community_classifieds
installed (community_membership and tncsc_deployment both uninstalled):
admin's has_group() returns True and "Classifieds" appears in their app
switcher immediately after install.
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.
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>
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>
