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>
