| Created Date | Type | Name | Commit Description | State | Age | Up Time | Life Time | Action |
|---|---|---|---|---|---|---|---|---|
|
merged
Merged from upstream 19 261002 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Killed | |||||
|
|
merged
Merged from upstream 19 260925 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Killed | |||||
|
|
open
[FIX] pos_loyalty, sale_loyalty: backport two upstream loyalty fixes
|
[FIX] sale_loyalty: allow invoicing-only users to open sale orders Steps to reproduce: 1. Create a user in the Invoicing group (account.group_account_invoice) only, without any Sales group. 2. As that user, open any sale order form (draft or confirmed with loyalty history). Issue: The form never opens; the client raises "You are not allowed to access 'Loyalty Coupon' (loyalty.card) records". This blocks a user who already has read/write access to sale.order in core, via the access_sale_order_invoicing_payments rule in sale's own security CSV, from doing their job. Cause: Two non-sudo reads in the sale.order extension hit loyalty models that are restricted to the Sales groups: the gift card stat button count queries loyalty.card directly, and the loyalty summary looks up the coupon point name via coupon_point_ids.coupon_id without the sudo already used one line above for loyalty.history. Fix: Gate the gift card count query behind a has_access('read') check, so a user without access simply sees a zero count (the stat button stays hidden), matching the has_access guard sale.order already uses in _create_invoices(). Read the coupon point name through sudo(), consistent with the loyalty.history read beside it, since the loyalty summary is meant to be visible to anyone who can already read the order. Signed-off-by: David Tran <david.tran@tvtmarine.com> (cherry picked from commit 84536036b471ced708a149c40c7f01dbf9a2d2fc) | Failed | |||||
|
|
open
[FIX] pos_loyalty, sale_loyalty: backport two upstream loyalty fixes
|
[FIX] sale_loyalty: allow invoicing-only users to open sale orders Steps to reproduce: 1. Create a user in the Invoicing group (account.group_account_invoice) only, without any Sales group. 2. As that user, open any sale order form (draft or confirmed with loyalty history). Issue: The form never opens; the client raises "You are not allowed to access 'Loyalty Coupon' (loyalty.card) records". This blocks a user who already has read/write access to sale.order in core, via the access_sale_order_invoicing_payments rule in sale's own security CSV, from doing their job. Cause: Two non-sudo reads in the sale.order extension hit loyalty models that are restricted to the Sales groups: the gift card stat button count queries loyalty.card directly, and the loyalty summary looks up the coupon point name via coupon_point_ids.coupon_id without the sudo already used one line above for loyalty.history. Fix: Gate the gift card count query behind a has_access('read') check, so a user without access simply sees a zero count (the stat button stays hidden), matching the has_access guard sale.order already uses in _create_invoices(). Read the coupon point name through sudo(), consistent with the loyalty.history read beside it, since the loyalty summary is meant to be visible to anyone who can already read the order. Signed-off-by: David Tran <david.tran@tvtmarine.com> (cherry picked from commit d5acfaf89b7beffa9ff6c3289432ee0507e55683) | Killed | Not finished | ||||
|
|
merged
Merged from upstream 19 260919 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Killed | |||||
|
|
merged
Merged from upstream 19 260915 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> | Killed | |||||
|
|
merged
Merged from upstream 19 260915 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Failed | |||||
|
|
merged
[FIX] tests, project: forward-port the runbot browser-test fixes to 19.0
|
[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. Forward-port to 19.0: applied unchanged. KanbanRecordQuickCreate on 19.0 keeps the same disabled window between the previous record's save and model.load, so the guard addresses the same race. Re-verified on 19.0 (fresh project database, no demo data, same Chrome build): both tours of test_01_project_tour succeeded, 0 failed of 1 test. X-original-commit: ffcd4ae4ee8b3ce5bef087f5f049c96f62f37e87 Signed-off-by: David Tran <david.tran@tvtmarine.com> | Killed | |||||
|
|
closed
Merged from upstream 19 260910 01
|
Failed | ||||||
|
|
closed
Merged from upstream 19 260910 01
|
Failed | ||||||
|
|
closed
Merged from upstream 19 260910 01
|
Failed | ||||||
|
|
closed
Merged from upstream 19 260910 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Failed | |||||
|
|
merged
[FIX] hr_skills_event, pos_loyalty: make two core tours independent of environment
|
[FIX] pos_loyalty: customer-search tours must query the server Four POS tours typed a customer's name into the partner-search box but never pressed Enter, so they only client-side-filtered the preloaded slice of at most 100 partners instead of querying the server, which searches every partner but is only triggered by pressing Enter. This made the tours fail whenever a larger partner set in the target database pushed the fixture partner outside that preloaded slice. Press Enter right after opening the partner-selection screen, using the existing PartnerList.searchCustomerValue(name, true) helper whose true argument triggers the Enter keypress and the server-side search, reusing the pattern already proven elsewhere in this module. Applies to test_not_create_loyalty_card_expired_program, PosOrderClaimReward and PosOrderNoPoints (pos_loyalty_loyalty_program_tour.js) and test_refund_does_not_decrease_points (pos_loyalty_tour.js). Test-only change, no production code touched. | Killed | |||||
|
|
closed
[FIX] pos_loyalty: stabilize customer loading in tours
|
Failed | ||||||
|
|
merged
V19 rebased from upstream 260827 01
|
[FIX] mail: RST syntax <string>:38: (ERROR/3) Unexpected indentation. <string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent. | Failed | |||||
|
|
closed
[FIX] pos_loyalty: stabilize customer loading in tours
|
Failed | ||||||
|
|
closed
[FIX] pos_loyalty: stabilize customer loading in tours
|
[FIX] pos_loyalty: stabilize customer loading in tours Keep loyalty browser tours independent from unrelated partner catalogue size by loading all partners before each tour. Add a boundary regression with zero-order partners so the existing customer-selection and refund assertions remain covered. | Failed | |||||
|
|
closed
[FIX] pos_loyalty: stabilize customer loading in tours
|
[FIX] pos_loyalty: stabilize customer loading in tours Keep loyalty browser tours independent from unrelated partner catalogue size by loading all partners before each tour. Add a boundary regression with zero-order partners so the existing customer-selection and refund assertions remain covered. | Killed | Not started | Not finished | |||
|
|
closed
[FIX] pos_loyalty: stabilize customer loading in tours
|
Killed | Not finished | |||||
|
|
merged
Rebased from upstream 19 260814 01
|
Killed | Not started | Not finished | ||||
|
|
merged
Rebased from upstream 19 260707 01
|
Failed | ||||||
|
|
merged
Merge from upstream 19 20260615 01
|
Killed | ||||||
|
|
merged
Merge from upstream 19 20260615 01
|
Failed | ||||||
|
|
merged
Merge from upstream 19 20260519 01
|
Merge remote-tracking branch 'odoo/19.0' into 19.0 | Killed | |||||
|
|
merged
Merge from upstream 19 20260512 01
|
Merge remote-tracking branch 'odoo/19.0' into 19.0 | Killed | |||||
|
|
merged
[I18N] account: correct translations
|
[I18N] *: correct translations | Killed | |||||
|
|
merged
[I18N] account: correct translations
|
[I18N] account: correct translations | Killed | Not finished | ||||
|
|
merged
Rebased from upstream 19 260312 01
|
[FIX] stock: 'stock.move.line' object has no attribute 'outermost_result_package_id' | Killed | |||||
|
|
merged
Rebased from upstream 19 260312 01
|
[FIX] stock: 'stock.move.line' object has no attribute 'outermost_result_package_id' | Revoked | |||||
|
|
closed
Rebased from upstream 19 260308 01
|
[I18N] account*: fix i18n (#1198) * [I18N] account*: fix i18n Forward-Port-Of: #1196 * Update vi.po --------- Co-authored-by: quyen <duyquyencnt55@gmail.com> Co-authored-by: Roy Le <43790414+royle-vietnam@users.noreply.github.com> | Failed | |||||
|
|
closed
Merge from upstream 19 20260305 01
|
Merge remote-tracking branch 'odoo/19.0' into 19.0 | Failed | |||||
|
|
merged
[FWD][19.0][I18N] account*: fix i18n
|
Update vi.po | Killed | |||||
|
|
merged
Merged from upstream 19 260216 01
|
apply Viindoo standard manifest | Killed | |||||
|
|
merged
V19 rebase from upstream 260210 01
|
apply Viindoo standard manifest | Killed | |||||
|
|
closed
[TEST][19.0] merged_from_upstream_260130_01
|
test runbot | Killed | |||||
|
|
closed
Merged from upstream 19 260130 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Failed | |||||
|
|
merged
Merged from upstream19 260119 01
|
Merge remote-tracking branch 'upstream/19.0' into 19.0 | Failed | |||||
|
|
merged
Merge from upstream 19 20250110 01
|
Merge remote-tracking branch 'odoo/19.0' into 19.0 | Failed | |||||
|
|
merged
Merge from upstream 19 20250110 01
|
Failed | ||||||
|
|
merged
Merge from upstream 19 20250110 01
|
Merge remote-tracking branch 'odoo/19.0' into 19.0 | Failed | Not finished |
