PR State:
merged
PR:
#664
Commit:
c6270b8daa251566323f2751b5f61b41fb51feb3
[FIX] viin_brand_website: brand the websites a field default cannot reach
Removing the x_icon QWeb override was right - it resolved to website's own
producer and destroyed it, so a configured favicon could never be served. But
that override was also, incidentally, what made unconfigured websites look
branded: it forced the brand path at render time for every website regardless
of the stored field. With it gone the stored value renders, and for two
populations that value is still Odoo's icon - website.default_website, which
core creates while loading the website module, before this module's field
extension exists, and any website predating this module's install. A field
default fires only at record creation, so it reaches neither.
So on every existing 19.0 database this branch, as it stood, silently swapped
the Viindoo favicon for Odoo's. Reported by Codex on PR #664.
Corrected once, from two entry points that share one implementation:
post_init_hook for a fresh install, migrations/0.1.2 for a database where the
module is already installed. Both rewrite ONLY records byte-identical to core's
own default - those are provably nobody's choice - and leave every configured
favicon exactly as it is, which is the whole point of having removed the
override.
Verified on clean databases: a fresh install and an upgrade both end with the
default website branded, while a website whose owner set its own favicon keeps
it byte-for-byte. UntouchedFaviconsGetBrandedTest locks both halves - doing
nothing fails one assertion, overwriting everything fails the other.
Branch:
19.0