|
|
|
merged
[I18N][18.0] *: Vietnamese "View" leftovers as "Xem" or "Giao diện", stock "Location" as "Địa điểm"
|
[I18N] stock, *: translate the stock Location as Dia diem in Vietnamese
A stock location reads "Dia diem" in the Vietnamese UI of the
inventory apps instead of "Vi tri": source and destination locations,
child and parent locations, location types, storage categories of
locations, the view location type, the warehouse view location and
the relocation of stock. "Vi tri" stays where it means a position.
246 entries updated across 14 modules (stock, stock_account,
stock_fleet, stock_picking_batch, mrp, mrp_subcontracting,
mrp_subcontracting_dropshipping, repair, purchase_stock, sale_stock,
spreadsheet_dashboard_stock_account, point_of_sale,
barcodes_gs1_nomenclature, and the mrp, sale_amazon and account_add_gln
descriptions in base); translations only.
|
Killed
|
Not started
|
|
|
|
|
|
|
merged
[I18N][18.0] *: Vietnamese "View" leftovers as "Xem" or "Giao diện", stock "Location" as "Địa điểm"
|
|
Killed
|
Not started
|
|
|
|
|
|
|
merged
[I18N][18.0] *: translate "View" as "Xem" or "Giao diện" in Vietnamese
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 261110 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 261105 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] l10n_vn_edi_viettel: fetch only the missing SInvoice files on re-send
|
[FIX] l10n_vn_edi_viettel: fetch only the missing SInvoice files on re-send
Steps to reproduce:
- Send & Print a posted customer invoice with "Send to SInvoice" ticked:
the invoice is issued and its PDF and XML files are fetched from
SInvoice and stored on the invoice.
- Send & Print the same invoice again, for instance to email it to the
customer.
Current behavior:
`_call_web_service_after_invoice_pdf_render` calls
`_l10n_vn_edi_fetch_invoice_files` for every invoice already sent, so
both files are fetched from SInvoice again on every Send & Print. Each
run creates a second attachment on the same binary field and posts a
new "Invoice sent to SInvoice" note in the chatter.
Besides, when SInvoice answers with an empty `fileToBytes`, the retry
loop gives up and the empty content is stored as the PDF file; a reply
without the `fileToBytes` key raises a KeyError in that loop, and a
reply that is not a ZIP archive raises zipfile.BadZipFile out of
`_l10n_vn_edi_fetch_invoice_xml_file_data`.
After this commit:
A file already stored on the invoice is not fetched again; only a
missing one is. An empty reply, a reply without the file key and a
non-ZIP reply are returned as error messages, which Send & Print shows
on the invoice like the other SInvoice errors. The two new messages are
added to the translation template and the Vietnamese catalog.
Closes Viindoo/odoo#1328
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] l10n_vn_edi_viettel: fetch only the missing SInvoice files on re-send
|
[FIX] l10n_vn_edi_viettel: fetch only the missing S-Invoice files on re-send
Re-sending an invoice already issued to Viettel S-Invoice no longer
fetches the PDF and XML again, so no duplicate attachment or chatter
note appears. A file answer that is empty, lacks the file key or is not
a ZIP archive becomes a clear error on the invoice instead of a
traceback or a silent empty PDF.
Closes Viindoo/odoo#1328
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 261028 01
|
[FIX] account_edi_ubl_cii: skip deferred dates tests without accountant
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, fields
defined by account_accountant. Without it they raised ValueError:
Invalid field 'deferred_start_date'. Guard them with
ensure_installed('account_accountant'), as test_invoice_deferred_dates
already does.
|
Killed
|
|
|
|
|
|
|
|
closed
Merge from upstream 18 261026 01
|
[FIX] pos_self_order: stop kiosk receipt print after leaving page
The kiosk confirmation page schedules the automatic receipt print
with setTimeout (first after 500 ms, then retried every 500 ms
until the order is loaded) but only clears the default-navigation
timeout when it unmounts. A print timer could therefore fire after
the customer left the page. Keep the print timeout ids and clear
them in onWillUnmount, as is already done for the default timeout.
The self_simple_order tour also ended while the automatic print was
still preloading the company logo. When the browser was closed right
after, the aborted image load was reported by the printer service
as an error and logged as 'Error received after termination'. Make
the last step wait for the confirmation page to be gone and for the
printer to be idle, so the tour waits for the work it started.
|
Failed
|
|
|
|
|
|
|
|
closed
Merge from upstream 18 261026 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 20261024 01
|
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 261011 01
|
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX] website_sale: wait for each cart line removal in the reorder tour
|
[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.
|
Failed
|
|
|
|
|
|
|
|
merged
[I18N] 18.0: fix Vietnamese translations and terminology of core modules
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
[I18N] 18.0: fix Vietnamese translations and terminology of core modules
|
[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.
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 261006 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 261002 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
open
[FIX] stock_account: let a product without stock change category without valuation access
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260919 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] tests, project: stabilise the browser tests that fail on the runbot
|
[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>
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] tests, project: stabilise the browser tests that fail on the runbot
|
[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>
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
closed
[FIX] project: wait for quick-create to enable before editing
|
[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>
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
closed
V18 fix tour tests
|
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260910 01
|
[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>
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260910 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260908 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260906 01
|
|
Failed
|
|
|
|
|
|
|
|
open
Merge from upstream 18 20250110 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
open
Merge from upstream 18 20250110 01
|
|
Failed
|
|
|
|
|
|
|
|
open
Merge from upstream 18 20250110 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
open
Merged from upstream 18 260105 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
open
Merge from upstream 18 20250915 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
Conflicts:
addons/base_setup/i18n/vi.po
|
Killed
|
|
|
|
|
