PR State:
merged
PR:
#663
Commit:
0825c24bcd7749ae3a149482bf63b49cfc22024e
[FIX] viin_brand_website: keep the brand favicon as a DATA default, not a layout override
Removing the x_icon QWeb override earlier in this branch fixed the field being
unusable, but lost something worth keeping: a website that had never configured
a favicon fell back to core's website.favicon default, which is Odoo's own
web/static/img/favicon.ico. A Viindoo deployment would have started unbranded on
its public pages - the most visible place a customer looks.
The override was not the right way to hold that. Because locate_node resolves an
xpath to the first document-order match, the `position="replace"` landed on
website's own `t-set x_icon` producer and destroyed it, so a customer who set
their own favicon could never serve it. Brand-always-wins and
customer-can-configure were mutually exclusive under that design.
A data-level default gives both. `website.favicon` is redeclared with the brand
image as its default, so a NEW website starts branded and any value the customer
sets afterwards survives untouched.
Redeclared rather than merely overriding _default_favicon: core binds the default
to the function OBJECT (`default=_default_favicon`, evaluated at class-definition
time), so overriding the method alone would never be picked up. to_base.res_company
redeclares its own favicon field for exactly this reason.
The image is read by addons path, not through a module dependency - viin_brand is
auto_install and always present in a branded deployment, but this module declares
no edge to it, so a missing file logs a warning and degrades to core's default
rather than breaking website creation.
Two tests lock the pair, because holding only one of them is the bug this commit
exists to avoid repeating: a fresh website starts with the brand favicon, and a
favicon the customer sets is not overwritten by the default.
KNOWN LIMIT: a default applies at record CREATION. Databases whose website record
already exists keep whatever favicon they have, which for an existing branded
deployment is the correct outcome anyway (the old override was render-time, so
nothing was ever stored). A deployment that wants existing website records
re-branded needs a separate data step - not added here.
Verified: 26 Python tests across the four modules, 0 failures, both new tests
confirmed executed rather than skipped.
Branch:
18.0