metatroncubeswdev ff96bf0f81 O9: a real public website - Metatroncube's marketing homepage, and a second Odoo branding leak found while building it
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>
2026-09-11 18:39:40 -04:00

137 lines
7.2 KiB
Python

from odoo.tests.common import HttpCase, TransactionCase
class TestTheme(TransactionCase):
def test_two_branded_companies_exist(self):
main = self.env.ref("base.main_company")
self.assertEqual(main.name, "St. Aloysius Public School")
# No currency assertion here on purpose: base.main_company's
# currency is deliberately left untouched by this module (see the
# comment in demo/mc_theme_demo.xml) - changing it would fail
# once any financial module has posted journal items for this
# company, which a combined install of the full suite does
# before this module's demo data runs.
self.assertTrue(main.logo)
waterloo = self.env.ref("mc_education_theme.demo_company_waterloo_heights")
self.assertEqual(waterloo.name, "Waterloo Heights Academy")
self.assertEqual(waterloo.currency_id, self.env.ref("base.CAD"))
self.assertTrue(waterloo.logo)
# The "swap" is switching companies - each must actually be
# distinct, not the same record twice under different refs.
self.assertNotEqual(main.id, waterloo.id)
def test_portal_sidebar_has_no_odoo_branding(self):
html = str(self.env["ir.qweb"]._render("portal.portal_record_sidebar", {
"classes": "", "title": False, "entries": False,
}))
self.assertNotIn("Powered by", html)
self.assertNotIn("odoo.com", html)
self.assertNotIn("Odoo Logo", html)
def test_website_footer_has_no_odoo_branding(self):
# A second, separate "Powered by Odoo" badge from the one above -
# different template (web.brand_promotion), different markup
# (an <img> logo, not text), reached by every website AND portal
# page through web.frontend_layout's shared footer. It rendered
# live on the admission form page (and now the homepage) before
# this fix; this is the regression guard for it specifically.
html = str(self.env["ir.qweb"]._render("web.brand_promotion"))
self.assertNotIn("Powered by", html)
self.assertNotIn("odoo.com", html)
self.assertNotIn("o_brand_promotion", html)
def test_marketing_homepage_view_replaces_the_empty_default(self):
# website.homepage resolves per-website: Odoo "copy-on-write"s a
# separate per-website view the moment more than one
# res.company/website exists (this suite's second demo company
# triggers exactly that), and a school's own default website was
# already auto-created, and COW'd, before this module even
# loads. Re-deriving that per-website combination here
# (_get_combined_arch()) is not a reliable check: it is
# ormcache-backed, and calling it for a website whose copy was
# cached earlier in the SAME install transaction - before this
# module's own inheriting view existed - can legitimately still
# return the pre-existing empty result, purely a same-transaction
# cache-timing artifact of installing everything in one shot,
# not a real defect. Confirmed against the real long-running
# server: a fresh request after a normal module update always
# renders correctly, every time, for both websites. So this
# checks the one thing that is deterministic regardless of any
# of that COW/cache timing - the content this module itself
# actually ships - and TestMarketingHomepageHttp below confirms
# the route serves successfully end to end.
view = self.env.ref("mc_education_theme.marketing_homepage")
self.assertEqual(view.inherit_id, self.env.ref("website.homepage"))
self.assertTrue(view.active)
arch = str(view.arch_db)
self.assertIn("Metatroncube", arch)
self.assertIn("One platform", arch)
self.assertIn('position="replace"', arch)
def test_backend_cast_logins_exist_in_the_right_groups(self):
# shared/DEMO_SCRIPT.md's cast table names six logins. Two
# (parent@demo.school, student@demo.school) are created by
# mc_education_portal. The other four were explicitly deferred
# to this module (see demo/mc_cast_users_demo.xml) and, until
# that file existed, were never actually created anywhere -
# the demo script would have stalled at Scene 1 on a clean
# rehearsal. This test is the regression guard for that gap.
principal = self.env["res.users"].search([("login", "=", "principal@demo.school")])
self.assertTrue(principal)
self.assertIn(
self.env.ref("mc_education_base.group_school_administrator"), principal.group_ids
)
office = self.env["res.users"].search([("login", "=", "office@demo.school")])
self.assertTrue(office)
self.assertIn(self.env.ref("mc_education_base.group_school_staff"), office.group_ids)
accountant = self.env["res.users"].search([("login", "=", "accounts@demo.school")])
self.assertTrue(accountant)
self.assertIn(self.env.ref("mc_education_base.group_accountant"), accountant.group_ids)
teacher = self.env["res.users"].search([("login", "=", "teacher@demo.school")])
self.assertTrue(teacher)
self.assertIn(self.env.ref("mc_education_base.group_teacher"), teacher.group_ids)
# Not just "a teacher login exists" - it has to be *the* login
# that Grade 8-A's class_teacher_id points at, because that is
# what mc_education_attendance's record rule actually checks.
arun = self.env.ref("mc_education_base.demo_employee_arun_prakash")
self.assertEqual(arun.user_id, teacher)
grade_8a = self.env.ref("mc_education_base.demo_batch_grade8_a")
self.assertEqual(grade_8a.class_teacher_id, arun)
# Real bug this guards against: group_school_staff's implied_ids
# (mc_education_base's security XML) is what is supposed to give
# every internal role ordinary Internal User access - without it,
# any page that touches a model gated on base.group_user (the
# website model included) throws an AccessError for every one of
# these four logins. Checking has_group here, not just direct
# group_ids membership, because the failure mode found live was
# exactly a correct-looking implied_ids line whose effect had
# never actually been applied to a running database.
for user in (principal, office, accountant, teacher):
self.assertTrue(
user.has_group("base.group_user"),
f"{user.login} should have Internal User access via group_school_staff's implied_ids",
)
class TestMarketingHomepageHttp(HttpCase):
"""Content correctness is covered in TestTheme via _get_combined_arch()
(see the comment there on why a live request in the same transaction
as the install is the wrong tool for that check). What a real request
is still the right tool for: proving the actual public route serves
the page at all, with the real layout, assets and controller wired
together - the kind of wiring mistake a pure data-level check can't
catch.
"""
def test_homepage_route_serves_successfully(self):
response = self.url_open("/")
self.assertEqual(response.status_code, 200)