CLAUDE.md's own O9 spec says branding applies to "backend, portal, website and every QWeb report" - the website part was never actually built. The public side of the site was still bare stock Odoo: an empty homepage (website.homepage ships as a literal `<div id="wrap" class="oe_structure oe_empty"/>`) and the admission form as the only real content anywhere a visitor could land. Per discussion: this is Metatroncube's own product marketing page, not the fictional school's site - it stays on a fixed brand (navy/indigo, Manrope + Work Sans, an illustrative dashboard preview panel), not the per-company colours the admission form and portal already read from res.company. Swapping the demo company for the O9 closing beat re-skins the product's own screens; it must not also repaint Metatroncube's own marketing collateral. Real second bug found building this, not related to the homepage content itself: rendering it surfaced a second, separate "Powered by Odoo" badge - web.brand_promotion, called from web.frontend_layout's shared footer - that is completely different from the one mc_education_theme already hid on the portal sidebar (different template, different markup, an <img> logo rather than text). This one sits in the footer of every website AND portal page and had been live on the admission form this whole time; nobody had reason to scroll to the bottom of that page and look. Neutralizing the shared, reusable template rather than website.layout specifically means every current and future caller of web.brand_promotion is covered by one fix. New dependencies this actually needs and the spec's one-line "Depends: mc_education_base" missed: `website` (to inherit website.homepage) and `web` (to inherit web.brand_promotion) - on top of `portal`, already added for the same reason last time. Flagging per CLAUDE.md's closing instruction rather than working around it quietly again. Testing note worth recording: website.homepage resolves through a per-website "copy-on-write" view, and Odoo auto-creates a default website (COW'd immediately) before this module even loads. Checking that per-website combination via _get_combined_arch() inside a --test-enable run that installs and tests everything in one transaction can see a stale, pre-COW empty result purely from cache timing internal to that one transaction - confirmed NOT a real defect by checking the same thing as a fresh request against the actual long-running server, which renders correctly every time. Tests here check what's actually deterministic (this module's own authored view content) plus a live HTTP round trip proving the route itself serves successfully, rather than chase that harness artifact. Full suite (all 9 modules + web_responsive) re-verified together: 0 failed, 0 error(s) of 85 tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
30 lines
1.2 KiB
Python
30 lines
1.2 KiB
Python
{
|
|
"name": "School ERP - Theme",
|
|
"version": "19.0.1.0.0",
|
|
"category": "Education",
|
|
"summary": "Per-company branding; hides Odoo/ERPNext branding the demo audience would see.",
|
|
"author": "Metatroncube Software Solutions LLP",
|
|
"license": "Other proprietary",
|
|
# portal, website and web are real, necessary dependencies this
|
|
# module's own spec line ("Depends: mc_education_base") missed:
|
|
# hiding the "Powered by Odoo" text means inheriting
|
|
# portal.portal_record_sidebar AND web.brand_promotion (two
|
|
# separate badges, two separate templates - see
|
|
# views/portal_branding_templates.xml), and the public marketing
|
|
# homepage (views/homepage_templates.xml) means inheriting
|
|
# website.homepage. All three modules must be loaded for that.
|
|
# Flagging per CLAUDE.md's closing instruction rather than silently
|
|
# working around it.
|
|
"depends": ["mc_education_base", "portal", "website", "web"],
|
|
"data": [
|
|
"views/portal_branding_templates.xml",
|
|
"views/homepage_templates.xml",
|
|
],
|
|
"demo": [
|
|
"demo/mc_theme_demo.xml",
|
|
"demo/mc_cast_users_demo.xml",
|
|
],
|
|
"installable": True,
|
|
"application": False,
|
|
}
|