Tuesday, February 25, 2025
14 changes · 18.0
Resolved issues and error corrections
Odoo now includes the required authentication header when returning a 401 response for bearer-token protected routes. This improves standards compliance and helps integrations handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate https://github.com/odoo/odoo/pull/199063
Updating account translations can encounter tags that were added after a release. This change prevents the process from crashing in that situation and records an error instead, helping language updates continue more reliably.
Original PR description
Sometimes, a tag is added after the release (e.g. f221381fbdf8) and this lead to an error when load_account_translations is executed (e.g. when updating a language translations). Do not crash but log an error instead.
This fixes an issue where Point of Sale managers could not see margin and cost information in the product information pop-up, even when they had the expected advanced access rights. After the change, authorized managers can access the same profitability details as intended, improving visibility during sales operations.
Original PR description
Description of the issue/feature this PR addresses: - Create POS, set login with employees, assign an employee as advanced user (manager) - Disable margin & costs configuration - Open POS, click the information icon in Product Screen - Margin & costs is not visible Current behavior before PR: - In POS the margin & costs is not visible with advanced access rights (manager) Desired behavior after PR is merged: - Show the margin & costs information in product information pop up --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Odoo returns the proper authentication instruction when bearer-token access is denied. It improves standards compliance for API integrations and helps external systems handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the…
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate 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
Section lines in generated PDF reports now show the expected gray background again instead of appearing only in bold. This restores the previous visual distinction for grouped sections in sales quotations and other reports, making documents easier to read and consistent with earlier versions.
Original PR description
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections…
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections lines were gray ### Cause: It was removed during a refactoring. Section lines with the "boxed" template were still supposed to be gray, but the code was `&.o_line_section td` inside of a `tbody` element, so the `&` referenced `tbody` and not `tr` on which the class `o_line_section` is added: https://github.com/odoo/odoo/blob/ddb03a55ac94b9fd48ae6ce138e70c0070bedd36/addons/account/views/report_invoice.xml#L131 ### Solution: Replace `&` by `tr` and move the change of background color to all tables, so affecting all reports. ###Before / After: "Light" template   "DIN5008" template   opw-4572732
Fixes an issue that prevented users from filtering account placeholder codes from the interface. Searches such as "starts with" and "ends with" now work correctly, avoiding invalid filter errors.
Original PR description
Current behavior before PR: - After this [fix](https://github.com/odoo/odoo/commit/56d5c9f4861b3509043660c97a702bfe0e636e3f) , any type searching is not possible for `placeholder_code` field. - For every filter applied, it just return `invalid domain error`. - this is because ` _search_placeholder_code` uses `=like` operator, but this makes it, unsearchable from frontend, as filters supports `ilike` and its related operators.  Desired behavior after PR is merged: - This PR fixes this issue, by changing the operator from `=like` -> `=ilike` - `placeholder_code` field can now be searched for filters like `starts with` and `ends with` .  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IAP module now handles connection failures more cleanly when external Odoo services cannot be reached. This prevents low-level connection errors from surfacing and helps keep error handling consistent for users and support teams.
Original PR description
This error occurs when the `IAP` service is `unreachable` when calling the JSON-RPC in IAP. ConnectionError: HTTPSConnectionPool(host='extract.api.odoo.com', port=443) At [1] `ValueError` is now raised and handled connection errors separately because this can also be raised from `requests.post` This commit will raise a `ValueError` instead of the `ConnectionError` Link [1] : https://github.com/odoo/odoo/blob/62ca36f5a347a230eda3cec2d31797fef0c7a13d/addons/iap/tools/iap_tools.py#L140 Sentry - 6280660773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several automated guided tests more reliable by adding waits and timing adjustments where pages or editors were not ready yet. It also modernizes barcode test coverage, helping reduce false failures and improve confidence in future changes without changing customer-facing features.
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
Delivery reports now show the shipping weight based only on products that are actually set to ship, even before the delivery is completed. This prevents overstated package weights when some items on an order have zero quantity to deliver.
Original PR description
Steps to reproduce the bug:
- Create two storable products:
- P1, weight: 1KG
- P2, weight: 2KG
- Create a delivery order:
- 1 unit of P1 and P2
- Mark it as "To Do"
- Set the quantity to 1 for P1 and 0 for P2
- Print the operation type
Problem:
Only product P1 appears in the report, but the total weight is 3KG instead of 1KG.
opw-4547704This fixes an unreliable automated test in the inventory batch picking area by ensuring the test updates the intended single-line picking. It helps keep validation builds stable and reduces false failures during development, with no expected impact on end users.
Original PR description
This commit avoids random error in test_group_by_country_and_product For more information: - https://runbot.odoo.com/odoo/action-573/114881 - https://runbot.odoo.com/odoo/runbot.build.error/116798 The error is caused because there are two pickings: one with a single move and the other with two moves. In the test, we should modify the move line that is alone. Since the order was not checked, the action done for the wave could return a wizard to create a backorder because we modified the quantity of a move line to 0 in a picking that has multiple move lines.
This pull request mainly streamlines internal test setup across several Odoo Enterprise apps, reducing unnecessary mail-related test data and making tests easier to maintain. It also prevents marketing automation processes from committing database changes during test mode, improving reliability and supporting future scalability work.
Manufacturing planning cells now stay on one line unless their contents would overflow, making the view cleaner while still readable. The update also improves demand cell colors for dark mode and preserves spacing around separators.
Original PR description
Due to input cell overflow, a stopgap solution was to always display demand and replenish cells on 2 lines when actual and forecasted/replenish were both activated. This is considered sub-optimal and this fix was made. When the view is loaded or reloaded due to manual changes, the DOM is updated depending on if overflow is detected in input cells. task 4420441
This update makes an automated test for Ecuador electronic delivery guides use a fixed date. That prevents date-related failures and helps ensure future checks remain reliable without changing user-facing behavior.
Original PR description
In 33509a095 we introduced a check on the data sent to the SRI. The data depends on the current date, but the test didn't execute in a `freeze_time` block. We now fix this. task-none
Spreadsheet pivot tables now match day-of-week values correctly for users in languages where weeks do not start on Sunday. This prevents users from opening the wrong underlying records when reviewing pivot results.
Original PR description
See community PR Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993