Branch
[FIX] website_sale: wait for each cart line removal in the reorder tour The fourth reorder of website_sale_reorder_from_portal empties the cart by clicking the first delete link four times, one second apart. The quantity change is debounced (500ms) then sent by RPC, and the input ignores changes until the answer comes back; on a loaded runbot the round trip exceeds the remaining 500ms, so a click hits the line still being removed and is lost. A line stays in the cart, the reorder then asks whether to clear it, and the tour fails at "Checking if Reorder Product 1 is in the cart" (runbot build 225353). Wait for the cart lines to be re-rendered (the clicked link is detached) before removing the next line instead of sleeping a fixed second.
PR:
[FIX] website_sale: wait for each cart line removal in the reorder tour
PR State:
merged
[I18N] *: fix Vietnamese translations and terminology Correct the Vietnamese catalogs of the core modules against a glossary researched per business domain (accounting per Circular 99/2025 and 133/2016, inventory, manufacturing, sales/purchase, HR, platform). - Definite defects: wrong meanings, broken placeholders and markup, untranslated user-facing strings, a real third-party e-mail address in auth_signup. - Key terms unified across modules, e.g. Journal Item = "Phát sinh kế toán", Credit Note = "Hóa đơn điều chỉnh giảm", Fiscal Position = "Chế độ thuế", Sales/Purchase Order = "Đơn bán"/"Đơn mua", Transfer = "Phiếu kho", Work Center = "Trung tâm sản xuất", Work Order = "Lệnh công đoạn", Analytic Account = "Tài khoản quản trị". - Records shared between modules (model names, re-declared fields) carry the same translation in every module, so the result no longer depends on module load order. - Old-style tone marks everywhere (hóa, hủy, khóa). - Residual defects found while aligning the Viindoo catalogs: the field type "float" read "dự trữ" (reserve), a garbled overdue line in the activity status help, Send Money = "Gửi tiền" (a deposit), the Blacklist family now "Danh sách chặn / Bị chặn", "Nếu được cài đặt" for settings, statement = "Sao kê", SEO meta labels, and a tax-mode label colliding with Fiscal Position. - l10n_vn_edi_viettel: catalog follows the renamed invoice type 5 label. Only msgstr content changes; msgids, references and layout are the exporter's and stay as they are.
PR:
[I18N] 18.0: fix Vietnamese translations and terminology of core modules
PR State:
merged
[I18N] *: fix Vietnamese translations and terminology Correct the Vietnamese catalogs of the core modules against a glossary researched per business domain (accounting per Circular 99/2025 and 133/2016, inventory, manufacturing, sales/purchase, HR, platform). - Definite defects: wrong meanings, broken placeholders and markup, untranslated user-facing strings, a real third-party e-mail address in auth_signup. - Key terms unified across modules, e.g. Journal Item = "Phát sinh kế toán", Credit Note = "Hóa đơn điều chỉnh giảm", Fiscal Position = "Chế độ thuế", Sales/Purchase Order = "Đơn bán"/"Đơn mua", Transfer = "Phiếu kho", Work Center = "Trung tâm sản xuất", Work Order = "Lệnh công đoạn", Analytic Account = "Tài khoản quản trị". - Records shared between modules (model names, re-declared fields) carry the same translation in every module, so the result no longer depends on module load order. - Old-style tone marks everywhere (hóa, hủy, khóa). - l10n_vn_edi_viettel: catalog follows the renamed invoice type 5 label. Only msgstr content changes; msgids, references and layout are the exporter's and stay as they are.
PR:
[I18N] 18.0: fix Vietnamese translations and terminology of core modules
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 261002 01
PR State:
merged
[FIX] stock_account: let a product without stock change category without valuation access Changing the category of a product to one with another cost method or valuation empties and replenishes its valuation layers. Since 61782d7163be ("[PERF] stock_account: prevent MemoryError in _svl_empty_stock"), `_svl_empty_stock()` reads `stock.valuation.layer` up front for every impacted product to collect the lots of lot-valuated ones, even when no product holds any stock. Users allowed to edit products but not Inventory/Administrator (every other manager group) therefore got "You are not allowed to access 'Stock Valuation Layer'" right after creating a product and changing its category. Return early when no impacted product holds stock, and only collect lots of lot-valuated products holding stock, the only ones whose lots are used. A product with stock still creates layers, and that stays refused for those users, exactly as before.
PR:
[FIX] stock_account: let a product without stock change category without valuation access
PR State:
open
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260919 01
PR State:
merged
[FIX] website_sale: a garbage ?category= on a product page must not answer 500 SQL-injection scanners request product pages with payloads in ?category= (e.g. "1' AND 1=1 UNION SELECT NULL-- -"): int(category) raised ValueError in _prepare_product_values and the page answered 500 - 1,031 times in one week on a production 16.0 shop. The earlier guard only covered the shop listing. The category only drives the breadcrumb and the back link here, so an invalid one is ignored, as upstream 19.0 does.
PR:
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
PR State:
merged
[FIX] project: wait for quick-create to enable before editing The "Second task" step in project_update_tour ran right after the prior quick-create ("New task") was validated, while KanbanRecordQuickCreate was still in its post-validate disabled window (o_disabled, pointer-events: none) held until web_save -> web_read -> onchange -> model.load resolve. Under network/CI latency the tour's click, aimed at that inert input, resolved to the ancestor `.o_kanban_group` instead (pointer-events: none excludes the input from hit-testing), and the following edit step then failed with "target should be editable". This reproduced 3/3 on retry within a single Viindoo runbot build but was intermittent across separate builds, consistent with a latency-dependent race, and reproduced locally on demand by injecting 150ms of CDP network latency. Guard the step's trigger to wait until the quick-create leaves o_disabled before interacting. The earlier "New task" edit step is left unchanged: it runs right after opening a fresh quick-create, not inside any post-validate disabled window. Verified on this fix: one 0ms-latency run and two 150ms-latency runs, two tours succeeded and none failed in each run. Without the guard the same 150ms latency fails the tour at this step. Live users are unaffected: focus stays in the quick-create input during the save. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
[FIX] tests, project: stabilise the browser tests that fail on the runbot
PR State:
merged
[FIX] tests: park the mouse out of the viewport before browser tests Seven `web` module HOOT/browser tests were deterministically red on the Viindoo runbot (18.0): four in WebSuite.test_hoot, three in WebSuite.test_unit_desktop (autocomplete and sortable). On the Viindoo runbot, the failure signature is byte-identical to a mouse cursor resting inside the viewport at test-page load. The runbot's own OS-level cursor position was never directly observed - only the in-page mechanism is proven: a known cursor position lets Blink dispatch a genuine TRUSTED pointerover/mouseover event into whatever element sits under that point on the next focus/scroll/ layout change, corrupting hoot-dom fixture assertions, AutoComplete's mouseover handlers, and sortable's edge-scroll math. Add ChromeBrowser._park_mouse_outside_viewport(), which sends CDP Input.dispatchMouseEvent {type: 'mouseMoved', x: -100, y: -100} (defensive: logs and never raises on failure). Call it from HttpCase.browser_js right after _wait_ready succeeds and before test code runs. Add addons/web/tests/test_browser_harness.py (BrowserHarnessCursorHygieneTests) as a guard: a permanent sensitivity proof plus the actual regression guard, both authored test-first (RED, confirmed failing before the fix, confirmed green after). Verified by a prior debug run's toggle on Chrome for Testing 150.0.7871.114 (the runbot's exact build): 7/7 failures reproduced then cleared, byte-identical output both directions. Re-confirmed on the finished fix with an integrated run on a fresh ephemeral Odoo 18.0 instance (core-only, web module), same Chrome build: 0 failed, 0 error(s) of 4 tests - both new guard-test methods green, WebSuite.test_hoot 199/199, and WebSuite.test_unit_desktop[@web/core/autocomplete,@web/core/utils/sortable] 33/33, the exact previously-failing set. No existing test, hoot, or hoot-dom file was touched. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
[FIX] tests, project: stabilise the browser tests that fail on the runbot
PR State:
merged
[FIX] project: wait for quick-create to enable before editing The "Second task" step in project_update_tour ran right after the prior quick-create ("New task") was validated, while KanbanRecordQuickCreate was still in its post-validate disabled window (o_disabled, pointer-events: none) held until web_save -> web_read -> onchange -> model.load resolve. Under network/CI latency the tour's click, aimed at that inert input, resolved to the ancestor `.o_kanban_group` instead (pointer-events: none excludes the input from hit-testing), and the following edit step then failed with "target should be editable". This reproduced 3/3 on retry within a single Viindoo runbot build but was intermittent across separate builds, consistent with a latency-dependent race, and reproduced locally on demand by injecting 150ms of CDP network latency. Guard the step's trigger to wait until the quick-create leaves o_disabled before interacting. The earlier "New task" edit step is left unchanged: it runs right after opening a fresh quick-create, not inside any post-validate disabled window. Verified on this fix: one 0ms-latency run and two 150ms-latency runs, two tours succeeded and none failed in each run. Without the guard the same 150ms latency fails the tour at this step. Live users are unaffected: focus stays in the quick-create input during the save. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
[FIX] project: wait for quick-create to enable before editing
PR State:
closed
[FIX] account_edi_ubl_cii: prevent deferred test crash on Community test_invoice_deferred_dates sets invoice.line fields deferred_start_date/deferred_end_date on the new line's create-vals, but only the Enterprise addon account_accountant defines them. Without it installed, the test crashed on every Community build instead of being skipped. Guard it with ensure_installed("account_accountant"), the same idiom already used four times elsewhere in this file, since the fields belong to the Enterprise deferred-revenue feature and are absent here by design. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
Merged from upstream 18 260910 01
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260910 01
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260908 01
PR State:
closed
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merged from upstream 16 20261012 01
PR State:
merged
[FIX] website_sale: a garbage ?category= on a product page must not answer 500 SQL-injection scanners request product pages with payloads in ?category= (e.g. "1' AND 1=1 UNION SELECT NULL-- -"): int(category) raised ValueError in _prepare_product_values and the page answered 500 - 1,031 times in one week on a production 16.0 shop. The earlier guard only covered the shop listing. The category only drives the breadcrumb and the back link here, so an invalid one is ignored, as upstream 19.0 does.
PR:
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260919 01
PR State:
merged
[FIX] website_sale: a garbage ?category= on a product page must not answer 500 SQL-injection scanners request product pages with payloads in ?category= (e.g. "1' AND 1=1 UNION SELECT NULL-- -"): int(category) raised ValueError in _prepare_product_values and the page answered 500 - 1,031 times in one week on a production 16.0 shop. The earlier guard only covered the shop listing. The category only drives the breadcrumb and the back link here, so an invalid one is ignored, as upstream 19.0 does.
PR:
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260911 01
PR State:
merged
Merge branch '16.0' into 16_survey_translate
PR:
[16.0][I18N] survey: translate template certificate
PR State:
open
[FIX] mrp: align open transfer bom lines before updating component quantity _link_bom now points the raw move and its open same-product origins at the new BoM line before writing product_uom_qty. A phantom kit puts bom_line_id in the merge key, so a quantity delta can fold into the open transfer instead of becoming a return. Co-authored-by: Cursor <cursoragent@cursor.com>
PR:
[FIX] mrp: align open transfer bom lines before updating component quantity
PR State:
closed
[FIX] website_event: call the parent start with the widget as `this` `this._super.apply(this.arguments)` passes `this.arguments` (undefined) as the receiver and no arguments at all. The parent start therefore ran with an undefined `this`, which has worked by accident only as long as the inherited start never touched `this`: as soon as a module includes `publicWidget.Widget` to wrap `start`, the registration form crashes with "Cannot read properties of undefined (reading '_super')" and every website_event tour breaks. Pass the widget and the real arguments, as `init` and `destroy` already do.
PR:
[FIX] website_event: call the parent start with the widget as `this`
PR State:
merged
Merge remote-tracking branch 'upstream/17.0' into 17.0
PR:
Merged from upstream 17 261014 01
PR State:
merged
Merge remote-tracking branch 'upstream/17.0' into 17.0
PR:
Merged from upstream 17 261013 01
PR State:
closed
[FIX] website_sale: wait for each cart line removal in the reorder tour The fourth reorder of website_sale_reorder_from_portal empties the cart by clicking the first delete link four times, one second apart. The quantity change is debounced (500ms) then sent by RPC, and the input ignores changes until the answer comes back; on a loaded runbot the round trip exceeds the remaining 500ms, so a click hits the line still being removed and is lost. A line stays in the cart, the reorder then asks whether to clear it, and the tour fails at "Checking if Reorder Product 1 is in the cart" (runbot build 225353). Wait for the cart lines to be re-rendered (the clicked link is detached) before removing the next line instead of sleeping a fixed second.
PR:
[FIX] website_sale: wait for each cart line removal in the reorder tour
PR State:
open
[FIX] website_sale: a garbage ?category= on a product page must not answer 500 SQL-injection scanners request product pages with payloads in ?category= (e.g. "1' AND 1=1 UNION SELECT NULL-- -"): int(category) raised ValueError in _prepare_product_values and the page answered 500 - 1,031 times in one week on a production 16.0 shop. The earlier guard only covered the shop listing. The category only drives the breadcrumb and the back link here, so an invalid one is ignored, as upstream 19.0 does.
PR:
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
PR State:
merged
Merge remote-tracking branch 'odoo/17.0' into 17.0
PR:
Merge from upstream 17 20260911 01
PR State:
merged
Merge remote-tracking branch 'odoo/17.0' into 17.0
PR:
Merge from upstream 17 20260911 01
PR State:
merged
[I18N] purchase_stock: correct Vietnamese translation Forward-Port-Of: #1170
PR:
[FWD][17.0][I18N] purchase_stock: correct Vietnamese translation
PR State:
open
[FIX] pos_loyalty: make the next order coupon tours robust on slow runners PosLoyaltyTour11.1 reloads the page right after the receipt "done" synchronization while it can still be in flight: the reloaded page replays the order, which stays in the cache without new_coupon_info, and the Paid filter never reads it again ("Next order coupon is missing"). The last step also read the paid order once, while the navbar spinner it waited on is cleared by whichever concurrent request ends first, so the order could still be missing from the model (TypeError reading 'new_coupon_info'). PosLoyaltyTour6 has the same reload after payment. Runbot build 225871 (subbuild 427841) failed on the first attempt; build 225816 (subbuild 427570) failed attempts 1 and 2. Wait for the synchronization to end before every reload, and make the last step wait until the paid order carries the coupon information instead of reading it once. Reproduced on core with latency injected in sync_from_ui, notify_synchronisation and read_pos_orders: the tours failed before the fix and pass after it. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR State:
merged
[FIX] test_website: make test_replace_media tour robust on slow runners After an image is replaced by another image, the step "ensure image size is displayed" was satisfied by the old Image options container, which stays mounted until the builder re-targets the new media. The next "Replace" click then acted on the detached element ("Invalid selection. Node is not part of the editable: None") and the Icon container never appeared. Runbot signature: "[18/36] Tour test_replace_media -> Step ensure icon block is displayed". The tour now marks the container of the media being replaced and waits for an Image container without that mark. That is the container of the new media, a new component since containers are keyed per element. Verified by injecting latency on /html_editor/get_image_info (+1 s): the tour passes 3/3 with the fix and fails at the same step with the same warning when the fix is reverted. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
[FIX] website, test_website: merge upstream 19.0 and make website tours robust on slow runners
PR State:
merged
[FIX] web: increase test_unit_desktop suite timeout In 19.0 the desktop unit suite runs the Hoot tests of all installed addons in one browser session (about 17,900 tests). Under runbot load the run can exceed the 3600 s overall browser_js timeout even though no test fails or hangs: 7 of 13 web-slice builds between 2026-10-13 and 2026-10-20 were cut at 95-99.8% of the suite, with 0 test failures. Raise the limit to 5400 s, the value upstream uses for a full run from 19.1 onward. Splitting the suite per sub-build as 19.1 does needs odoo.tests.CrossModule, which does not exist in 19.0. This follows upstream commit a7017b504c5c, which raised the same timeout from 3000 to 3600 for the same reason.
PR:
[FIX] web: increase test_unit_desktop suite timeout
PR State:
merged
[FIX] account_edi_ubl_cii: prevent deferred tests crash on Community test_invoice_deferred_dates_with_delivery_date, test_invoice_deferred_dates_on_some_lines and test_invoice_deferred_dates_on_some_lines_with_delivery_date create invoice lines with deferred_start_date/deferred_end_date, but only the Enterprise addon account_accountant defines them. Without it installed, they crashed with "Invalid field" on every Community build instead of being skipped. Guard each with ensure_installed("account_accountant"), the same idiom already used by test_invoice_deferred_dates. Signed-off-by: David Tran <david.tran@tvtmarine.com> (cherry picked from commit 5e828c61ed0f222af0f195d46fb2b34e53888bc0)
PR:
Merged from upstream 19 261018 01
PR State:
merged
Merge remote-tracking branch 'upstream/19.0' into merged-from-upstream-19-261018-01
PR:
Merged from upstream 19 261018 01
PR State:
merged
Merge remote-tracking branch 'upstream/19.0' into merged-from-upstream-19-261017-01
PR:
Merged from upstream 19 261017 01
PR State:
closed
Merge remote-tracking branch 'upstream/19.0' into 19.0
PR:
Merged from upstream 19 261011 01
PR State:
closed
[I18N] *: fix remaining Vietnamese translation defects Follow-up to Viindoo/odoo#1302: the Vietnamese defects the 19.0 sync pass still found in core, fixed so each concept reads one way. - Email Button Color = "Màu nút Email" (the Viindoo branding wording), and the other mail labels that kept the English word order. - Weekdays: long names in word form ("Thứ Hai" ... "Chủ nhật"), short names as the calendar abbreviations "T2" ... "CN" (lunch had a mix of both). Opening Hours snippet = "Giờ mở cửa". - Dashboard = "Bảng tổng quan" everywhere, replacing "Báo cáo tổng quan", "Bảng điều khiển" and "Trang tổng quan". "Bảng điều khiển" stays for the control panel. - Minimum = "Tối thiểu", the pair of Maximum = "Tối đa". - Loyalty: typo in "Điểm phiếu giảm giá", word-for-word reward labels, the "CT KH" abbreviation, and eWallet = "Ví trả trước" in every label. - pos_loyalty: a coupon that is "not yet valid" is "chưa có hiệu lực", not "không hợp lệ". - CRM won/lost = "Thắng"/"Thua" everywhere. The "Won" currency unit (KRW/KPW) is no longer translated as "Đạt". - Rotting (records stuck in a stage) = "Tồn đọng", now translated in mail, crm, hr_recruitment and project. - Accounting: Inbound Payment Methods = "Phương thức thu tiền" (pair of "Phương thức chi tiền"), Json Activity Data, Add a subsection. - HR: the Officer access role = "Người phụ trách" in every app; Work Entries = "Công" in the module names. - Offline/online presence = "Ngoại tuyến"/"Trực tuyến" in web, mail, POS, payment, website and the employee status popovers.
PR:
[I18N] 19.0: fix remaining Vietnamese translation defects of core modules
PR State:
merged
[I18N] *: fix Vietnamese translations and terminology Bring the Vietnamese catalogs of the 19.0 core modules to the corrected terminology of 18.0 (Viindoo/odoo#1299), so a Vietnamese user sees one term per concept on 19.0 too. The wording follows the same owner-approved glossary (accounting per Circular 99/2025 and 133/2016, inventory, manufacturing, sales/purchase, HR, platform). - Entries whose msgid and translation are unchanged since 18.0 take the corrected 18.0 translation, including the strings #1299 translated for the first time (l10n_vn_edi_viettel and others). Strings that moved to another module in 19.0 follow them. - Entries 19.0 retranslated, and strings new in 19.0, were reviewed in context: the approved terms are applied (e.g. Journal Item = "Phát sinh kế toán", Credit Note = "Hóa đơn điều chỉnh giảm", Fiscal Position = "Chế độ thuế", Sales/Purchase Order = "Đơn bán"/"Đơn mua", Transfer = "Phiếu kho", Work Center = "Trung tâm sản xuất", Analytic Account = "Tài khoản quản trị", Settings = "Thiết lập") while genuine 19.0 improvements are kept. - Records shared between modules (model names, re-declared fields) carry the same translation in every module, so the result no longer depends on module load order. - One wording per label for the mail and activity fields every document model inherits (e.g. Action Needed = "Cần xử lý", Is Follower = "Đang theo dõi"), across all modules. - Inventory valuation options use the names accountants know: Periodic = "Kiểm kê định kỳ", Perpetual = "Kê khai thường xuyên". Account closing = "Khóa sổ". Restaurant courses = "Lượt món". Validation Error = "Dữ liệu không hợp lệ". Vehicle = "Phương tiện" (the app stays "Đội xe"). - Old-style tone marks everywhere (hóa, hủy, khóa). - Definite defects found on the way: broken spacing in mail templates, "Second" read as seconds in calendar recurrences, typos such as "kiểm tử", the garbled overdue line in the activity status help. - l10n_vn_edi_viettel: catalog follows the renamed invoice type 5 label. Only msgstr content changes, apart from the renamed type 5 msgid; msgids, references and layout are the exporter's and stay as they are.
PR:
[I18N] 19.0: fix Vietnamese translations and terminology of core modules
PR State:
merged
[FIX] test_base_automation: wait for trigger menu content in tours The tours test_form_view_mail_triggers and test_form_view_model_id asserted the trigger select menu content synchronously, while the trigger selection field rebuilds its groups asynchronously after a model change. The expected groups and items are now checked by waiting triggers. The checkMenu helper comes from upstream odoo commit fcd0005f73e8, with an exact-count step added so an extra group or item still fails. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
Merged from upstream 19 261007 01
PR State:
merged
Merge remote-tracking branch 'upstream/19.0' into 19.0
PR:
Merged from upstream 19 261007 01
PR State:
merged
Merge remote-tracking branch 'upstream/19.0' into 19.0
PR:
Merged from upstream 19 261007 01
PR State:
merged
Merge remote-tracking branch 'upstream/19.0' into 19.0
PR:
Merged from upstream 19 261007 01
PR State:
merged
[FIX] survey: keep the action helper alive when the RPC is unreachable `SurveySurveyActionHelper` (shown when the survey list/kanban is empty) fetches the sample templates in `onWillStart` and lets any error through. In the offline clickbot (`TestMenusAdminLight.test_02_click_apps_menus_ as_admin_offline`) that RPC is cut and the whole Surveys app fails: Error found: - Current testing app is Surveys (survey.menu_surveys) - Currently running offline Connection to "/web/dataset/call_kw/survey.survey/get_survey_templates_data" couldn't be established or was interrupted Odoo's runbot never renders the helper during that test because the enterprise `hr_appraisal_survey` ships surveys as regular data; a community-only database without demo data has an empty list and hits it. Swallow `ConnectionLostError` only and render the helper without templates: "Start from scratch" stays available, other errors still propagate. Verified with `-i survey,web --test-enable --test-tags=/web:TestMenusAdminLight` on a community checkout without demo data: test_02 fails without this change and passes with it (2/2).
PR:
[FIX] survey: keep the action helper alive when the RPC is unreachable
PR State:
open