|
|
|
open
[FIX] viin_brand_common, web_responsive, viin_brand_mail, to_backend_theme: keep brand CSS out of core test bundles
|
[FIX] web_responsive: pin primary-variables bundle order
CPython randomizes string hashing per process (PYTHONHASHSEED), so a
Python set literal used as an assets bundle value iterates in a
different order every time the Odoo server process starts. The
"web._assets_primary_variables" bundle was declared as a set of two
SCSS paths, making its file load order nondeterministic across
deployments and restarts.
Switch the bundle from a set literal to a list literal, keeping the
exact same two files in the exact same order they were already
written in: form_variable.scss first, then primary_variable.scss.
Verified safe to keep this order: form_variable.scss defines only
$o-form-renderer-max-width and $o-form-view-sheet-max-width, while
primary_variable.scss defines only $app-menu-text-color,
$app-menu-background-color, $app-menu-item-highlight,
$app-menu-box-shadow and $app-menu-box-shadow-highlight, all with
!default. The two files' variable namespaces are fully disjoint in
both directions, so there was no dependency-driven "correct" order to
choose - this order is now a deliberate, deterministic choice rather
than an accident of hash seeding.
Protected by the repo-wide regression guard added in the immediately
preceding commit
(viin_brand/tests/test_manifest_assets_no_set_literals.py), which was
measured RED against exactly this bundle before this fix, and is now
confirmed GREEN together with this fix on a real Odoo 18.0 instance
(db odoo_18_0_standard_viindoo_18_t_cbeabf2d): odoo.tests.result: 0
failed, 0 error(s) of 6 tests.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Succeed
|
|
|
|
|
|
|
|
open
[FIX] viin_brand_common, web_responsive, viin_brand_mail, to_backend_theme: keep brand CSS out of core test bundles
|
[FIX] viin_brand_onboarding: drop own SCSS from core's JS unit-test bundles
viin_brand_onboarding was the one brand module the earlier four-module
sweep missed. Its onboarding.scss reads five brand variables that only
viin_brand_common defines - $brand-primary-light/-dark/-darker and
$brand-secondary-light/-dark - and that web.assets_unit_tests_setup and
web.tests_assets no longer carry now that viin_brand_common's own
sweep removed them. So this leak did not merely pollute core's JS unit
tests with Viindoo design tokens, it aborted the compile of the whole
bundle with "Undefined variable".
Remove this module's own stylesheet from those two TEST-ONLY bundles;
web.assets_backend (the real webclient) is untouched and still serves
the stylesheet with all 18 brand gradient declarations byte-identical.
New tests guard both directions.
Measured: before 7 failed of 21 tests (14 "Undefined variable"
occurrences), after 1 failed of 21 (0 "Undefined variable"). The one
remaining failure is unrelated and pre-existing: a sibling guard test
that needs point_of_sale or hr_attendance installed to verify
anything, and correctly refuses to pass vacuously when neither is.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Killed
|
|
|
|
|
|
|
|
open
[FIX] viin_brand_common, web_responsive, viin_brand_mail, to_backend_theme: keep brand CSS out of core test bundles
|
[FIX] viin_brand_common: guard overrides out of public bundles
Lock in the separation the previous commit established, so it
cannot quietly rot. This module's overrides of core files belong to
the backend webclient and must stay out of the point-of-sale
terminal, the public mail page, the embedded livechat widget and the
attendance kiosk.
The guard asserts that in both directions: it also asserts the
emoji-picker override is still deliberately shared with the public
mail page and the livechat embed, so a future cleanup that mistakes
those two intentional declarations for part of the leak gets caught
instead of silently stripping brand coverage. It further asserts
every override still reaches the webclient, so nobody can turn the
suite green by deleting the overrides outright.
Verified: 22 tests pass on a live database, and the four
brand-appearance tours each still complete all three steps.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Failed
|
|
|
|
|
|
|
|
open
[FIX] viin_brand_common, web_responsive, viin_brand_mail, to_backend_theme: keep brand CSS out of core test bundles
|
[FIX] web_responsive: guard responsive layout now unit tests carry no brand CSS
The previous commits on this branch stripped web_responsive's own SCSS
back out of core's Hoot/QUnit test bundles, which fixed core tests that
were measuring this module's layout instead of core's own defaults - but
also removed the only place a regression that silently drops this
module's SCSS from the real webclient would have been noticed.
Add test_brand_css_out_of_test_bundles.py (2 tests): assert
web_responsive.scss is absent from web.assets_unit_tests_setup and
web.tests_assets (what the prior commit fixed) while still present in
web.assets_web, the bundle the real webclient is served from - so a
future change cannot silently strip the responsive layout from
production while the test bundles stay clean. The module marker is
matched on the full SCSS-compiler comment path, not a bare module-name
substring, since this database also carries
viin_customizer_web_responsive whose own stylesheet legitimately sits in
the test bundle and would otherwise report a false leak.
Verified live on a real instance: baseline 0 failed of 18, an inversion
that comments out this module's own ('remove', ...) manifest entry takes
down this guard specifically, and a restore-verify pass returns to 0
failed with all tours succeeding.
|
Failed
|
|
|
|
|
|
|
|
open
[FIX] viin_brand_common, web_responsive, viin_brand_mail, to_backend_theme: keep brand CSS out of core test bundles
|
[FIX] to_backend_theme: drop own SCSS from core's Hoot/QUnit bundles
Both web.assets_unit_tests_setup (core's Hoot test-setup bundle) and
web.tests_assets (the legacy QUnit bundle) carry
('include', 'web.assets_backend') and ('include', 'web.assets_backend_lazy'),
declared in Odoo core's own addons/web/__manifest__.py. That pulled
to_backend_theme's own backend-theme SCSS straight into core's own
unit-test pages, so several of core's own tests were measuring
to_backend_theme's styling instead of core's own defaults.
Add explicit ('remove', <path>) entries for all 7 of this module's
own SCSS files, spanning both source bundles
(web.assets_backend / web.assets_backend_lazy), to both TEST-ONLY
bundle keys in this module's own manifest. web.assets_backend and
web.assets_backend_lazy themselves (the real webclient) are untouched
- AssetPaths.remove() operates on the accumulated per-bundle path
list, not on the source bundle that contributed it. Confirmed both
statically (zero diff on either production bundle key) and live (the
two test bundles now resolve zero of this module's SCSS paths while
the production bundles still resolve all of them, unchanged, and both
test bundles still compile clean with zero errors).
Manifest-only change - this module has no test-page CSS shim to
remove.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] web_responsive: reach the apps menu the user actually opens
|
[FIX] web_responsive: fix apps-menu toggle dead-end and flash bug
The apps-menu toggle button (button.o_grid_apps_menu__button) could go
permanently dead. AppsMenuAction is registered under the "menu"
client-action tag, so it can be mounted directly via doAction("menu"),
bypassing the apps_menu service's own openMenu() (the overlay path)
entirely. When that happens, the service's isOpening flag still turns
true (AppsMenuScreen's mount effect fires unconditionally) but
removeOverlay stays null, so the next click's closeMenu() finds
nothing to remove and does nothing - the button stays dead until the
action is dismissed some other way. A code comment claimed this path
was "unreachable, no live path to test" - that was false:
erponline-enterprise18/viin_customizer_web_responsive (auto_install:
True) reaches it via its own isolated action service, and this
module's own test suite already drives doAction("menu") through the
real action service elsewhere. closeMenu() now falls back to the real
"action" service: when the "menu" action is the current controller and
something is underneath it (breadcrumbs already exclude "menu"-tagged
controllers, so a non-empty array means a real prior screen), it
restores that screen. With nothing underneath (a bare doAction("menu"),
e.g. the boot fallback) the button stays a no-op by design - there is
nothing to reveal.
Separately, the previous commit's anti-flash fix (66a6a7d65d, passing
`open` down as a prop so the app grid renders in the same cycle the
screen mounts) was silently discarded for any upgraded user.
AppsMenu.setup() called useState() a second time whenever
session.apps_menu.is_redirect_home is true, recomputing `open` from
the router's menu_id and overwriting the prop entirely.
migrations/18.0.1.0.8/post-migration.py backfills is_redirect_home=True
for every upgraded user with no action_id - the dominant real
configuration, not an edge case - so any such user landing on a
non-root menu (menu_id != 0) got the one-frame empty-overlay flash
back. Collapsed to a single useState() call: the prop wins whenever
the caller passes it; the is_redirect_home fallback only applies when
AppsMenu is mounted without that prop.
Also removed a dead `browser.localStorage.setItem("redirect_menuId",
"")` write (and its now-unused import) - its only reader, onMenuClick,
was deleted by 66a6a7d65d; no other reader exists anywhere across
branding18, tvtmaaddons18, or erponline-enterprise18. Updated a stale
test comment describing the retired bus-round-trip open mechanism, and
dropped a stray blank line. Bumped the module version.
Two RED-before-green Hoot tests were added protecting each fix, both
confirmed failing on the pre-fix code and passing after, live on Hoot
desktop preset:
- "clicking the navbar apps button dismisses the menu action too, not
only the overlay"
- "the is_redirect_home branch never overrides the open prop
AppsMenuScreen always passes"
Before: filter=@web_responsive/apps_menu - 17 tests, 15 passed / 2
failed (both new tests red on the exact predicted assertions).
After: same filter - 17/17 passed. Full @web_responsive tag - 17/17
passed. Also manually verified the ordinary overlay open/close flow
live in the browser - no regression.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] web_responsive: reach the apps menu the user actually opens
|
[FIX] web_responsive: reach the apps menu the user actually opens
e2e5205 split the apps-menu screen into two sibling classes -
AppsMenuAction (still registered under the "menu" actions tag, the
class third-party modules patch by name) and AppsMenuOverlay (what
appsMenuService.toggleMenu() actually mounts for the user, via the
overlay service). Because the overlay was a SIBLING of AppsMenuAction
rather than a descendant, a module that does
patch(AppsMenuAction.prototype, {...}) and separately extends the
shared "web_responsive.AppsMenuAction" template by name - the real,
shipped shape in erponline-enterprise/viin_customizer_web_responsive -
never reached the class that renders for the user. Runbot build
224030 failed 71 of 83 tests with "TypeError: ctx.getAppCreatorItem is
not a function at AppsMenuOverlay.slot2": every tour that opens the
apps menu died.
Make AppsMenuOverlay extend AppsMenuAction instead of the shared
AppsMenuScreen base, so a prototype patch() applied to AppsMenuAction
- by this module or any third party, in either load order - is
inherited by the overlay too. Corrected what plain inheritance would
otherwise get wrong on the new subclass: static props (an overlay's
shape, not the action-service props it would otherwise inherit),
coversNothing (the overlay has no env.config to read breadcrumbs
from, so it falls back to the base class's own resolution), and left
static target/displayName inherited-but-inert with a comment so a
future reader does not "clean them up" and reopen this. Documented at
the class declarations that AppsMenuAction is both the "menu" action-
tag registrant and the patch target other modules reach for by name,
so the next module that legally patches this class does not silently
break again.
This repairs a regression we shipped, already merged into 18.0
(origin/18.0 @ 2cfee94 contains e2e5205). The suite was NOT executed
here: this fix was produced under a static-verification-only
constraint (no instance, no odoo-bin, no database, no test run). RED
was argued from source - traced against e2e5205's diff and the real
external patcher/template-inheritor - and the fix confirmed by static
reasoning over the JS prototype chain (AppsMenuOverlay.prototype's
[[Prototype]] is a live reference to AppsMenuAction.prototype, so a
patch() mutation to the latter is visible to overlay instances).
Syntax-checked with node --input-type=module --check; no reachable
project ESLint config to run further here - that gate runs later at
the run's own pre-PR tail.
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] web_responsive, viin_brand_common: unbreak the tours #14456 re-enables
|
[FIX] viin_brand_common: stop prepending brand to every tab title
Every real page title got "Viindoo - " prepended to it, because
WebClient.setup() injected a PERMANENT titleParts entry
(zopenerp: "Viindoo") whenever session.viin_brand is set. Core only
ever composes the literal "Odoo" as the EMPTY-CASE FALLBACK -
Object.values(titleParts).join(" - ") || "Odoo" in
web/static/src/core/browser/title_service.js - it never appears
beside a real title. website's SEO dialog rendered
"Viindoo - Hello, world!" instead of "Hello, world!", failing core's
own test_website_event_pages_seo tour (runbot 223907, target G1 of
run tour-reenable-14456).
Remove the permanent setParts() injection - webclient.js had no
other purpose, so it is deleted - and instead patch core's "title"
service itself (new static/src/core/browser/title_service.js) so
ONLY the empty-case fallback is rebranded: core computes the title
exactly as it always does, and only when core's own getParts() shows
titleParts is empty does the patch replace the trailing "Odoo" with
"Viindoo". A real title composed by core is never touched. Still
gated on the server-stamped session.viin_brand marker (introduced by
f35f41c) so core's own QUnit/Hoot suites, whose mock sessions lack
the marker, keep asserting the plain "Odoo" title.
NOT verified against a live Hoot/QUnit run: this environment has no
spare RAM to build an instance (a foreign run owns the only live
one). RED-today / green-after was argued by reading
title_service.js's composition and hand-tracing titleParts for both
scenarios in the companion test, never executed.
|
Succeed
|
|
|
|
|
|
|
|
merged
V18 fix web responsive
|
[FIX] web_responsive: drop the statusbar DropdownItem hotkey override
DropdownItem no longer accepts a hotkey prop on 18.0, so grafting
hotkey='shift+a' onto every statusbar dropdown item crashed the whole
statusbar with an OwlError on small screens (where the buttons collapse
into that dropdown). The override was pointless anyway — it assigned the
same hotkey to every item.
|
Killed
|
|
|
|
|
|
|
|
merged
[FWD] forward-port 8 commits from 17.0 (c676d5a..2fe943f)
|
[FWD] forward-port 17.0 -> 18.0 (c676d5a..2fe943f, 8 commits)
Single merge of origin/17.0 into 18.0. Every source commit enters the DAG with
its own SHA intact, so the merge-base advances to 17.0's tip and none of these
conflicts is ever re-resolved on a future run.
Ported: 6aef9e0 8069ccc 221946b 4c0d67c f35f41c 0d6646d 33a11ec 2fe943f
FOUR THINGS WOULD HAVE MERGED GREEN AND BEEN WRONG AT 18.0. Each is invisible
in the diff, so they are named here.
1. 221946b's guard is deliberately NOT taken. Source gates _loadDefaultApp on
registry.category("actions").contains("apps_menu"). At 18.0 the action
registers under the tag "menu", so that condition is permanently false and
would have silently disabled the apps-menu redirect for every user. The
target already reaches the same no-throw outcome via its session marker.
2. 4c0d67c's isCheck does not exist at 18.0. The tour engine was rewritten;
StepSchema declares no isCheck and validates through Owl validate(). `run` is
optional-typed, so an explicit undefined is not the same as absent - the key
is deleted, not set.
3. The AppsMenu tests are re-implemented on Hoot, not ported. 18.0 replaced
QUnit and all three of this module's suites imported a helper 18.0 core does
not ship - they were already dead on this branch. 18.0 also passes a BARE
STRING to doAction("menu"), so a literal port of `step(`do-action:${action.tag}`)`
reads .tag off a string, records "do-action:undefined", and passes while
asserting nothing. The new tests step on the argument itself.
4. One CSS reset was not enough. 17.0 had one test page; 18.0 runs two. Both
resets are declared under web.tests_assets AND web.assets_unit_tests.
EVIDENCE. A/B on this tree - identical suite, brand absent from the addons path
vs brand installed with the resets absent - returned 0 failures against 28, all
pixel-geometry (11x column_widths, 4x daterange, 1x datetime, draggable,
scroller, nested_sortable, 7x html_editor, 1x mail). With the resets in place
that drops to 6, all in @html_editor/*. The 17.0 runbot ids and counts were
deliberately not carried into the code - 18.0's suite has different names and
numbers, and quoting the old ones would be fabricated evidence.
Also verified on a live 18.0 build rooted on this tree: 10/10 new Hoot tests
pass, 26/26 Python tests pass across the four modules, and
WebSuite.test_check_suite now passes - it was erroring on 18.0 before this work,
which is what 2fe943f fixes.
TWO CHANGES BEYOND THE EIGHT COMMITS, both deliberate:
- viin_brand_website's x_icon QWeb override is removed and replaced by a
data-level default on website.favicon. The override was a position="replace"
that, because locate_node resolves an xpath to the first document-order match,
destroyed website's own favicon producer - so a customer who configured a
favicon could never serve it. Removing it alone would have left new websites
unbranded, so the brand image is now the field's default instead: branded out
of the box, and the customer's own value survives once set.
- Three local fixes were needed to make the ported tests actually run at 18.0:
defineMailModels() for mail's mock models, componentEnv for env.config on a
direct mount, and /web/offline -> /odoo/offline after core's route rename.
KNOWN GAPS, not hidden: the design doc's test_asset_isolation.py leak-guard was
not written; 6 @html_editor failures remain (brand-caused, pre-existing on 18.0,
outside what the 17.0 commits addressed); test_qunit_desktop fails on
viin_web_gantt, a module in a different repo; the colorpicker tour was adapted
statically and not executed; cluster-wide acceptance was not run.
|
Killed
|
|
|
|
|
|
|
|
merged
[FWD] forward-port 8 commits from 17.0 (c676d5a..2fe943f)
|
[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.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FWD] forward-port 8 commits from 17.0 (c676d5a..2fe943f)
|
[FIX] viin_brand_common+viin_brand_website: make 2fe943f's regression tests pass on 18.0
The two suites forward-ported with 2fe943f failed on their first real 18.0 run.
Two distinct causes, both fixed here.
1. /web/offline was renamed to /odoo/offline at 18.0
(web/controllers/webmanifest.py), so two tests in test_web_layout.py got a
404 and never reached their assertions. Only the TEST was affected -
viin_brand_common's own controller overrides the handler with a bare
@http.route(), inherits core's path, and therefore followed the rename by
itself. The path is now a module-level OFFLINE_URL constant so the next
rename breaks in one obvious place.
2. viin_brand_website's layout carried an 18.0-only override that destroyed the
website's own favicon:
<xpath expr="//t[@t-set='x_icon']" position="replace">
<t t-set="x_icon" t-value="'/viin_brand/static/img/favicon.ico'"/>
</xpath>
locate_node resolves an xpath to the FIRST document-order match, which in the
combined website.layout arch is website's own producer
(t-set x_icon = website.image_url(website, 'favicon')). Replacing it meant a
website that had configured its own favicon could never serve it - the brand
path was substituted unconditionally, with no `or` guard. Adding a guard would
not have helped: after the replace, x_icon is unset at that point, so
`x_icon or <brand>` collapses to the brand every time.
This is why the title survived while the favicon did not: only x_icon had a
second, replace-based mutator. Title flows through website's own
`t-if="not title"` guard untouched.
SCOPE NOTE: that override is NOT one of the eight commits this wave forward-ports
and predates it on 18.0 - 17.0 has no such block. It is removed rather than left
red because the test 2fe943f brings across exists precisely to assert that the
brand default never pre-empts a website's own value, and removing the override
restores the 17.0 behaviour that test encodes. It does change observable
behaviour: a website with its own configured favicon now serves that favicon on
website pages instead of the brand one. Non-website pages are unaffected - they
still take the brand default from viin_brand_common's own fallback. Flagged for
review rather than buried.
Verified: the four affected modules' Python suites now run 22 tests with zero
failures on a live 18.0 build (was 3 failures).
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] web_responsive: stop disabling the attachment side panel on every
|
[FIX] web_responsive: stop disabling the attachment side panel on every
form
form_renderer.esm.js patched FormRenderer.hasFile() to return false
unconditionally, and the file is loaded in web.assets_backend for the
whole backend. hasFile() is what mail's form compiler asks before
rendering the "o_attachment_preview" hook
(mail/chatter/web/form_renderer.js mailLayout(),
which returns COMBO only when there is a file), so with it in place the
attachment preview panel never rendered on ANY form at ANY screen size -
no receipt beside an expense report, no PDF beside a vendor bill.
The patch also has nothing left to do on 18.0: mailLayout() already
gates the panel on SIZES.XXL, so narrow screens get the chatter at the
bottom and no preview whether or not this override exists. It only
removed the feature from the wide screens that are supposed to have it.
The exported unpatchDisableFilePreview handle is never imported
anywhere, so nothing ever put the behaviour back.
Reproduced and verified on v18_full: hr_expense's
test_show_expense_receipt_on_expense_line_click went from "1 failed of 1
tests" (step 8/12 "Check attachment" timing out after 10s because the
panel was absent from the DOM) to "tour succeeded, 0 failed of 1 tests".
A browser probe on the same database confirmed the cause was rendering,
not data: the mail store held all three attachments with
attachmentsInWebClientView = 3, uiService.size = 6 (XXL) and the chatter
mounted, while .o_attachment_preview was absent entirely.
No manifest version bump: the module declares its assets with the
"views/form/*" glob, so the ir.asset rows in the database are unchanged
and the bundle is rebuilt from the checksum of the files it resolves.
|
Killed
|
|
|
|
|
|
|
|
merged
[18.0][FWD] Forward-port 17.0 fixes: branded colorpicker tour, POS navbar guard, statusbar/chatter absorbs
|
[FIX] viin_brand_pos: make forward-ported POS navbar guard Hoot test runnable on 18.0
The Hoot test added with the a982703 forward-port statically imported the real
@point_of_sale/app/navbar/navbar, which drags 9 transitive POS-app modules into the
shared web.assets_unit_tests bundle and aborts the whole web unit suite at setup.
Register a dependency-free stand-in under the same module name (core's own odoo.define
idiom) so the real guard patch applies on top of it without pulling the POS UI tree into
the shared bundle. Proven live on 18.0: passed 2/2 with the guard, and the guard test
fails when the guard is reverted (confirm-by-toggle).
|
Killed
|
|
|
|
|
|
|
|
open
[FWD] forward-port 17.0 -> 18.0: store URLs + web_responsive apps_menu guard + is_redirect_home restoration
|
[FIX] web_responsive: correct a false idempotency comment + bind the session_info test
Three review findings from the forward-port batch.
The migration's comment claimed the is_redirect_home filter makes a re-run
match nothing, so an opted-out user is never silently re-opted-in. The second
half was false: an opted-out user holds False, which is exactly what the
domain selects. Odoo compiles a boolean "= False" to
(col IS NULL OR col = FALSE), so the domain provably cannot tell "never
backfilled" from "deliberately opted out" - the manifest version gate is what
makes this run once. The comment now says that. The domain and the logic are
unchanged and correct: that same collapse is what lets the backfill match the
NULL rows every pre-existing user actually has.
test_session_info only ever exercised the preference at True, so a hardcoded
True in the session_info transport would have passed it. It now also flips the
preference to False and re-asserts, binding the assertion to the user's real
stored value on both sides.
The new JS test file carried an OCA sibling's copyright header; it is
Viindoo's own 2026 file. The LGPL-3 license line stays - the module is OCA.
|
Killed
|
|
|
|
|
|
|
|
merged
Fwd from 17 to 18 260630 01
|
Merge remote-tracking branch 'origin/17.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FWD] branding: forward-port 17.0 → 18.0 (web_responsive guard + sticky statusbar, demo enrich)
|
[FWD] branding: forward-port origin/17.0 into 18.0
Absorb origin/17.0 (9 commits since a83807d) into 18.0. Net behavioral deltas:
- web_responsive: guard session.apps_menu?.theme (60a49a7); .o_form_statusbar sticky block (3d5df32)
- viin_brand_mass_mailing: Viindoo-branded newsletter demo + i18n strings (603119f)
- viin_brand_social_media: demo (603119f); .gitignore node_modules/.odoo-ai (36603e7)
Already-on-18.0 / net-zero: web_tour manifest dep, chatter.xml styling, test_patch.js (removed in 18.0), serve-menu-icon revert pair.
Verified: 73 modules install clean on 18.0 with demo ON (--no-http, demo enabled).
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] viin_brand_hr_expense: re-enable on 18.0 + refresh live_test_url
|
[FIX] viin_brand_hr_expense: restore empty-state image size on v18
On v18 the core placeholder %o-nocontent-init-image no longer declares
width/height (each consumer must set its own, e.g. core sets 120x80).
The branded phone-bill :before only set background + background-size,
so it collapsed to height:0 and the image was invisible on the My
Expenses empty-state. Add explicit width:300px / height:230px matching
the background-size. Caught by live-browser render verification.
Claude-Session: https://claude.ai/code/session_01FsCCRaAZ4Tb84s2UdQQQS2
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] viin_brand_hr_expense: re-enable on 18.0 + refresh live_test_url
|
[FIX] viin_brand_hr_expense: restore empty-state image size on v18
On v18 the core placeholder %o-nocontent-init-image no longer declares
width/height (each consumer must set its own, e.g. core sets 120x80).
The branded phone-bill :before only set background + background-size,
so it collapsed to height:0 and the image was invisible on the My
Expenses empty-state. Add explicit width:300px / height:230px matching
the background-size. Caught by live-browser render verification.
Claude-Session: https://claude.ai/code/session_01FsCCRaAZ4Tb84s2UdQQQS2
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
merged
[FIX] viin_brand_hr_expense: re-enable on 18.0 + refresh live_test_url
|
[FIX] viin_brand: refresh live_test_url to v18demo
Point live_test_url / live_test_url_vi_VN at v18demo-int / v18demo-vn
(were still v17demo) on the 18.0 branding modules.
Claude-Session: https://claude.ai/code/session_01FsCCRaAZ4Tb84s2UdQQQS2
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FWD] branding: forward-port 17.0 styling fixes to 18.0
|
[FWD] branding: forward-port 17.0 styling fixes to 18.0
Forward-port 8 white-label frontend commits (b1e478d..a83807d) from 17.0
onto 18.0: viin_brand_mail / viin_brand_common / viin_brand_pos /
web_responsive SCSS plus the apps_menu preferences OWL group-guard.
Platform-drift adaptations for v18:
- viin_brand_mail manifest: register new message/message_seen_indicator
overrides and move the messaging_menu asset anchor to
mail/static/src/core/public_web (v18 relocated it from core/web),
keeping the v18 mail.assets_public + im_livechat bundles.
- apps_menu_preferences.esm.js: re-graft the base.group_system visibility
guard (useState + onWillStart + t-if) onto the v18 @web/core/user
singleton idiom and static template.
- viin_brand_pos/style.scss: drop dead v17-era POS highlight rules.
Verified on a live v18 instance: install-clean, asset bundles build with
zero console errors, the apps_menu OWL component mounts, and the
white-label styling applies.
Claude-Session: https://claude.ai/code/session_01Vxr24zjvJXj5gmv6vgzPPd
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_website_slides: fix bad UI
|
[FIX] viin_brand_website_slides: fix bad UI
|
Killed
|
|
|
|
|
|
|
|
merged
[IMP][18.0] web_responsive: change home menu to action
|
[IMP] web_responsive: change home menu to action
|
Killed
|
|
|
|
|
|
|
|
merged
[IMP][18.0] web_responsive: change home menu to action
|
[IMP] web_responsive: change home menu to action
|
Killed
|
|
|
|
|
|
|
|
merged
[IMP][18.0] web_responsive: change home menu to action
|
[IMP] web_responsive: change home menu to action
|
Failed
|
|
|
|
|
|
|
|
merged
[UPD] web_responsive: update code from upstream
|
[UPD] web_responsive: update code from upstream
|
Killed
|
|
|
|
|
|
|
|
merged
[UPD] web_responsive: update code from upstream
|
[UPD] web_responsive: update code from upstream
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[UPD] web_responsive: update code from upstream
|
[UPD] web_responsive: update code from upstream
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand: change odoo email template to viindoo
|
[FIX] viin_brand: change odoo email template to viindoo
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand: change odoo email template to viindoo
|
[FIX] viin_brand: change odoo email template to viindoo
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand: bad UI 2
|
[FIX] viin_brand: bad UI 2
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand: bad UI 2
|
[FIX] viin_brand: bad UI 2
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[MISC][18.0] viin_brand_website_forum: add viindoo logo and texts
|
[MISC] viin_brand_website_forum: add viindoo logo and texts
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_website_slides: fix bad UI
|
[FIX] viin_brand_website_slides: fix bad UI
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_website: fix odoo text in HTML/CSS editor
|
Apply suggestion from @royle-vietnam
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_website_slides: fix bad UI
|
[FIX] viin_brand_website_slides: fix bad UI
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_website: fix odoo text in HTML/CSS editor
|
[FIX] viin_brand_website: fix odoo text in HTML/CSS editor
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_hr: fix translation
|
[FIX] viin_brand_hr: fix translation
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand: change odoo text to viindoo
|
[FIX] viin_brand: change odoo text to viindoo
- Change odoo text in fields of viin_brand_mail_bot and viin_brand_common
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX][18.0] viin_brand_pos: change odoo save screen to viindoo
|
[UPG] viin_brand_pos: bad UI
|
Killed
|
|
|
|
|
