Odoo Changelog — 2024-10-01

Tuesday, October 1, 2024

40 changes · saas-17.4

Bug Fixes(5)

Resolved issues and error corrections

[FIX] *: fix some broken tests

Coresaas-17.4test_base_importbase

This update fixes broken automated tests caused by assumptions about unavailable fields and patching behavior. It helps keep Odoo's quality checks reliable without changing end-user functionality.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#tests#quality#stability

[FIX] mail: 'object-fit: cover' on all persona avatar in discuss

PR #182262

Coresaas-17.4mailwebsite_livechat

Fixes how profile images appear across Discuss and live chat so non-square photos are cropped neatly instead of being stretched or squeezed. This makes conversations look more polished and consistent for users without changing functionality.

Original PR description

Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous.

This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them.

Before / After
<img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00 50 44" src="https://github.com/user-attachments/assets/f3d1937c-3a3a-4a8c-aa01-d91e25bceaac">


Before / After
<img width="1280" alt="Screenshot 2024-10-01 at 00 51 40" src="https://github.com/user-attachments/assets/983aa74f-2904-4037-a373-517b13a014d9">
<img width="1280" alt="Screenshot 2024-10-01 at 00 49 40" src="https://github.com/user-attachments/assets/4227137a-aab4-48be-bbf0-803704cb9575">

#avatars#discuss#live-chat#visual-fix

[FIX] industry_fsm: project field showing non fsm projects.

PR #70850

Enterprisesaas-17.4industry_fsm

Field Service tasks now correctly show only Field Service projects in the project selection field. This prevents users from accidentally linking tasks to unrelated projects, keeping operational data cleaner and aligned with Field Service workflows.

Original PR description

Steps to Reproduce:

- Open Field Service app
- Open any task
- Click on the Project Field

Issue:

- You can select any project which should not be possible because we dont use non fsm projects.

Reason:

- Change in structure of form.
- A new label is added before the project field which makes the current xpath being used to become obsolete.

Fix:

- Updated the xpath.

Issue from https://github.com/odoo/odoo/pull/131015

task-4204896

#field-service#projects#task-management

[FIX] stock_barcode: hide lot name on single line

PR #70917

Enterprisesaas-17.4stock_barcodestock_barcode_picking_batch

The barcode picking screen now respects the setting to hide reserved lot or serial numbers when there is only one line and it has not been picked or scanned yet. This prevents warehouse users from seeing lot details that should stay hidden under that operation type configuration.

Original PR description

When 'Show reserved lots/SN' is unticked on the operation type, we don't 
want to show the lot/serial name when there's only a single line and 
it's not picked/scanned yet.

#barcode#inventory#lots#serial numbers

[FIX] *: fix some broken tests

PR #70302

Enterprisesaas-17.4sale_purchase_inter_company_rulessale_purchase_stock_inter_company_rules

This fixes failing automated tests for inter-company sales and purchase workflows by avoiding an unnecessary currency field update. The change helps keep quality checks reliable without changing business behavior for users.

#tests#inter-company#sales#purchase

Other(35)

Miscellaneous changes

[FW][FIX] mrp: not unreserve twice during mass production

PR #182279

Coresaas-17.4mrp

Original PR description

### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…

### Steps to reproduce:

- Enable Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Change your warehouse settings to Manufacturing in 2 steps
- Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock)
- Create and confirm an MO for 10 units of P
- Validate the delivery from stock to pre-production
- Click on `Mass Produce` > `Generate` only 7 SN
- Click No back order (split and generate only 7 MO's)
#### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be
- validate one of the 7 MO
#### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be

### Cause of the issue:

By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice

opw-4145680
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#181864
Forward-Port-Of: odoo/odoo#181255

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous. This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them. Before / After <img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00 50 44" src="https://github.com/user-attachments/assets/f3d1937c-3a3a-4a8c-aa01-d91e25bceaac"> Before / After <img width="1280" alt="Screenshot 2024-10-01 at 00 51 40" src="https://github.com/user-attachments/assets/983aa74f-2904-4037-a373-517b13a014d9"> <img width="1280" alt="Screenshot 2024-10-01 at 00 49 40" src="https://github.com/user-attachments/assets/4227137a-aab4-48be-bbf0-803704cb9575">

Steps to Reproduce: - Open Field Service app - Open any task - Click on the Project Field Issue: - You can select any project which should not be possible because we dont use non fsm projects. Reason: - Change in structure of form. - A new label is added before the project field which makes the current xpath being used to become obsolete. Fix: - Updated the xpath. Issue from https://github.com/odoo/odoo/pull/131015 task-4204896

### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's) #### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be - validate one of the 7 MO #### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be ### Cause of the issue: By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice opw-4145680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181864 Forward-Port-Of: odoo/odoo#181255

### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN #### > However raw moves are **picked with a consumed_qty of 0** ### Cause of the issue: Since the stockpocalypse commit 7dda6bb the `_split_productions` did not consume quantities anymore. This behavior was fixed by commit 4be8cac for mass production notably by the addittion of these lines: https://github.com/odoo/odoo/blob/6995d65437ba6b2cd0df7503d589260bedcce67d/addons/mrp/models/mrp_production.py#L1879-L1887 However, in our flow, when we assigned the firt serial number by clicking on the [+] button we had set the quantity of the `initial_move` to 1 and associated a `move_line` with the corresponding quantity to it. As such, none of the move line of the raw moves of the back order is going to be created and the issue remains. opw-4119702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182216 Forward-Port-Of: odoo/odoo#179062

Currently when invoicing through pos, multiple values related to price discounts are incorrect. Steps to reproduce: ------------------- * Go to the **Point of sale** app * Under **Configuration**, select **Settings** * Enable **Flexible Pricelists** * Select **Advanced price rules** * Create a pricelist, 10% discount on all products, visible on the invoice * Go to the **Products list** * Select any product and apply a tax (price excl) * Open shop session * Select the product with the tax * Pay and invoice it > Observation: In some cases the line "Price discounted from" does not appear on the invoice. And when it appears, values are not correct. If you also plied a discount on the product line in addition to the pricelist, values are completely mixed. Why the fix: ------------ We see that we are curently comparing `line.price_subtotal_incl` with `line.product_id.lst_price * line.qty`. https://github.com/odoo/odoo/blob/b49159db74cf4c8212a7bd3dfe551eb852df99f3/addons/point_of_sale/models/pos_order.py#L213-L219 To simplify, we consider a quantity of 1. * `line.price_subtotal_incl` includes discounts (order line discounts and pricelist) and always represent a price with taxes included. * `line.product_id.lst_price` reprensents the price set on the prodcut form. It does not account for any sort of discount. If the tax applied on the product is tax excl(resp. incl) it will be a price tex excl(resp. incl). In the case where the pricelist discount is smaller than the tax amount, for products with tax excl, the `line.price_subtotal_incl` will still be greater than `line.product_id.lst_price` and that's why the invoice does not have the line "Price discounted from". I asked MOBT the behavior expected. For the line "Price discounted from", this should only reflect discounts related to pricelist, and should represent the price tax excl/incl depending on the tax set up on the product page. Line discounts are already reflected on the invoice with `Disc.%`. We choose to compare two values that reflect the same price tax configuration. We compare `line.product_id.lst_price` with `line.price_unit` as both will be tax excl(resp. incl) if the tax applied on the product is tax excl(resp. incl). We also remove the `line.qty` as both represent a price per qty. opw-4170357 Forward-Port-Of: odoo/odoo#181674 Forward-Port-Of: odoo/odoo#181007

## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181971

**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate fashion. **Expected behavior:** The price_unit should be accurate. **Steps to reproduce:** 1. Enable another currency, set an exchange rate on it that is very small (like < 0.01) 2. Enable automatic valuation, create a product with both average costing method and real time valuation on its category, give it some initial cost e.g., 500 3. Create a new purchase order, add a line like: - product_id: from step 2 - quantity: 13 - discount: 1% 4. Set the currency on the purchase order to be the one from step 1, so it is different from the active company's 5. Confirm the purchase order and validate the receipt, look at the SVL generated and note its remaining value 6. Create a bill for the purchase order, post the invoice, then look at the SVL's remaining value again -> it changed **Cause of the issue:** The price unit being converted between currencies and rounded causes some discrepancy with the final value, also the calculation for gross price unit on AML model is somewhat primitive. **Fix:** Stop rounding base and update the formula used when calculating gross price unit. opw-4103167 Forward-Port-Of: odoo/odoo#181866 Forward-Port-Of: odoo/odoo#181527

Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on the last day of the month > Save - Management > Allocations > New - Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan - Set the start date to today - 0 days of allocation for 'Time off type' of your choice > Validate - My time > Dashboard > Use 'Balance at the mm/dd/yyyy' The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead. The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid re-computations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves. This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute. Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway. opw-4192703 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181115

Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy; 5. open link in a private window/different browser; 6. pay invoice. Issue ----- The access token is invalid, which is important if you as user don't have regular access to the document (or are logged out). Cause ----- When a subscription payment flow is followed via an invoice, it sets the `access_token` in the controller and adds a `transaction_route_subscription` value. The `access_token` is valid for the `transaction_route_subscription`, but this route is only followed when payments are automated (added in 36b238b934f). Initially, the invoice token was passed, which worked for non-automated payments getting passed as regular invoices to `account_payment`. Commit 60fd12a6c65 changed this to a subscription token, to allow automated payments, but broke non-automated payments in the process, as those still go via `account_payment`, which expects an invoice token. Solution -------- Concatenate the access tokens, and decide which one to use in the `_submitForm` override. Also partially undo 2b34ba49ef7: `payment_utils.check_access_token` expects a payment access token, the commit made it pass a invoice access token instead. opw-4152257 Forward-Port-Of: odoo/enterprise#70503

Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior - Component: - C1: - Routes: “Resupply Subcontractor on Order” - Create a purchase order for one unit of “P1” - Confirm the PO - Create a second PO for one unit of “C1” and receive it - Confirm the resupply picking of C1 - Confirm the receipt of P1 **Problem:** A validation error is triggered: “You cannot end up with a negative stock quantity.” We added a constraint to prevent negative stock quantities in internal locations for a company in Kenya. However, the location linked to subcontracting is internal but has no warehouse, so we don’t care if its quantity is negative, and it should be ignored. This could also happen with other internal locations that don’t have a warehouse. Additionally, when reporting stock quantities, we only consider quantities in locations that have a warehouse: https://github.com/odoo/enterprise/blob/9dea0f2696084235ee1192b0a14adfa43eb732ef/l10n_ke_edi_oscu_stock/models/product.py#L47 opw-4184857 Forward-Port-Of: odoo/enterprise#70808

Bug Fixes(5)

[FIX] *: fix some broken tests

[FIX] mail: 'object-fit: cover' on all persona avatar in discuss

[FIX] industry_fsm: project field showing non fsm projects.

[FIX] stock_barcode: hide lot name on single line

[FIX] *: fix some broken tests

Other(35)

[FW][FIX] mrp: not unreserve twice during mass production

Bug Fixes(5)

[FIX] *: fix some broken tests

[FIX] mail: 'object-fit: cover' on all persona avatar in discuss

[FIX] industry_fsm: project field showing non fsm projects.

[FIX] stock_barcode: hide lot name on single line

[FIX] *: fix some broken tests

Other(35)

[FW][FIX] mrp: not unreserve twice during mass production

[FW][FIX] mrp: fix _split_productions set consumed_qty 2

[FW][FIX] hr_attendance: Fix overtime computation with adjustments

[FW][FIX] account: no quick encoding on section/note

[FW][FIX] sale_project: avoid stop iteration issue

[FW] 17.0 opw 3977674 fix agr

[FW][FIX] mail: fix prefetch of fields

[FW][FIX] product: catalog ux manual edit

[FW][FIX] point_of_sale: fix MoneyDetailsPopup prop def

[FW][FIX] website: prevent website search box cache

[FW][FIX] point_of_sale: fix discount values from pricelist on incoice

[FW][FIX] account: keep valid attachments on bill

[FW][FIX] web: allow drag and drop elements in mass_mailing

[FW] PRHOOT 24

[FW][FIX] mail: allow SA to send emails on any model

[FW][FIX] stock_dropshipping: wrong vendor selected

[FW][FIX] {purchase{,_stock},stock_account}: more accurate price unit calc

[FW][FIX] hr_holidays: accrual start gain time granted immediately

[FW][FIX] survey: hide test warning banner on survey results

[FW][FIX] l10n_pe: invoice label

[FW][FIX] sale: price rules form behavior

[FW][FIX] sale_planning: fix Schedule by Sales Order menu visible to planning users

[FW][REF] industry_fsm_sale: add hook for inheritance of so values

[FW][FIX] timesheet_grid: remove stray test display

[FW][FIX] sale_subscription: resolve payment access token conflict

[FW][FIX] {appointment}_hr: traceback on duplicating the appointment

[FW][FIX][draft] helpdesk: allow quick_create from ticket kanban view

[FW][FIX] {,l10n_be_}hr_payroll: Explicitly reset `is_unforeseen`

[FW][FIX] industry_fsm : Add AM or PM when having 12-hour time format

[FW][FIX] spreadsheet_dashboard_documents: tour wasn't run

[FW][FIX] l10n_ke_edi_oscu_stock: allow negative qty subcontracting location

[FW][IMP] l10n_mx_edi: display fiscal folio for vendors and payments

[FW][FIX] account_accountant: bank account creation

[FW][FIX] l10n_mx_hr_payroll: compute paid amount correctly

[FW][FIX] account_reports: prevent modification of dict during iteration