Thursday, April 24, 2025
16 changes · 17.0
Resolved issues and error corrections
The document layout setup no longer crashes when a company uses an unusually tall, narrow logo. This helps users configure company documents reliably without needing to resize or replace valid logo images first.
Original PR description
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the…
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current logic in `base_document_layout.py`, where the width (w) is computed using int(50 * base_w / base_h). For highly vertical images (e.g., width = 8, height = 901), this calculation results in w = 0, which subsequently causes a ValueError when passed to the resize() function. This commit resolves the error by using `math.ceil` to compute the width (w) instead of int, ensuring that the value is never zero, even for extremely vertical images. Sentry-6516888945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adds missing identifiers for Buckaroo payment methods so they can be recognized correctly during payment processing. It helps reduce setup or transaction issues for businesses using Buckaroo as a payment provider.
Original PR description
Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures website robots.txt settings are applied correctly when a site is accessed through an internationalized domain name, whether entered in encoded or readable form. This helps businesses using non-English characters in their domain names keep search engine crawling rules consistent and accurate.
Original PR description
When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are not reflected. This commit ensures the correct handling of punycode domains so that the robots.txt is properly served, regardless of whether the domain is accessed in Unicode or punycode form. opw-4641081
Kitchen preparation tickets now clearly show which items belong to a combo order. This prevents restaurant staff from mistaking combo components for separate standalone items, helping reduce preparation errors.
Original PR description
When sending a combo to a preparation printer, the combo items where not indented correctly. This was leading to a preparation ticket that made it look like all items were normal items, instead of being part of a combo. Steps to reproduce: ------------------- * Create a combo product A * Setup a kitchen printer in the PoS * Open PoS and add the combo product A * Send the order to the kitchen printer > Observation: The preparation ticket does not show the combo items > indented correctly Why the fix: ------------ We add a new fields in the `changes` that state if the line is part of a combo. If it is part of a combo, we add a css class that will indent the line accordingly. opw-4459211
This fixes an issue where Romanian VAT validation compared the first tax number twice instead of checking the second one. It helps prevent incorrect VAT validation results for Romanian business partners.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale customer search now finds contacts even when a phone number is typed without spaces but saved with spaces. This makes customer lookup faster and more reliable at checkout, reducing missed matches for cashiers.
Original PR description
Before this commit, searching for a customer in the PoS using a phone number without spaces (e.g. "0612345678") would return no results if the number was stored with spaces (e.g. "06 12 34 56 78"). opw-4683209 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents duplicate future public holiday leave records from being created when an employee is unarchived even though they are already active. It avoids incorrect time-off balances and cleanup work after contract signing workflows update employee records.
Original PR description
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and force unarchiving the employee even if it's already active. This commit ensure that unarchiving an already active employee does not create duplicate *future* public holidays. opw-4134712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The GST reporting process now checks whether a company has a valid GST token before running scheduled GST API calls. This prevents failed or unnecessary background processing and keeps GST reporting automation aligned with the existing manual validation flow.
Original PR description
This PR adds a validation check for a company's GST token before making GST API calls via cron. These validations already exist when making GST API calls through the GST return period but were missing in the cron execution. This ensures that no unnecessary cron execution and api call takes place. task-4350780
Mexican electronic invoice files will no longer include an unused trade-related namespace in the generated XML. This keeps the document output cleaner and avoids confusion when reviewing or validating invoice files, without changing invoice behavior.
Original PR description
With this commit we remove the namespaces that are not used in the cdfi document. Steps: - Create an invoice and send the edi document - Look at the xml -> namespace `xmlns:cce20="http://www.sat.gob.mx/ComercioExterior20"` is included but unused opw-4493568
Miscellaneous changes
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#195958
Original PR description
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#195958
**Problem:** Newly created users on the portal can click the 'verify email' button multiple times quickly, leading to the generation of multiple verification emails without refreshing the page. **Steps to Reproduce:** 1. Create a new user on the website. 2. Sign in as the new user and navigate to the 'Forum' page. 3. Click the 'verify email' button multiple times quickly. 4. Check Mailhog / Network requests for multiple verification emails. **Requires https://github.com/odoo/odoo/pull
Original PR description
**Problem:** Newly created users on the portal can click the 'verify email' button multiple times quickly, leading to the generation of multiple verification emails without refreshing the page. **Steps to Reproduce:** 1. Create a new user on the website. 2. Sign in as the new user and navigate to the 'Forum' page. 3. Click the 'verify email' button multiple times quickly. 4. Check Mailhog / Network requests for multiple verification emails. **Requires https://github.com/odoo/odoo/pull/183894 to be merged** opw-4122195 Forward-Port-Of: odoo/odoo#181628
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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 Forward-Port-Of: odoo/odoo#
Original PR description
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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 Forward-Port-Of: odoo/odoo#206420
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi
Original PR description
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205323
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 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 Forward-Port-Of: odoo/odoo#203254
Original PR description
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 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 Forward-Port-Of: odoo/odoo#203254
The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time. ## How to reproduce - Create product P, storable, tracked in Kg - Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg -> Stock Valuation is updated by 0.02Kg OPW-4734980 --- Test result without fix: ``` 2025-04-22 13:40:45,088 38626 ERROR oes_tes
Original PR description
The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced…
The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.
## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg
OPW-4734980
---
Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206884In this commit: - Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory. - Previously, all HSN summary data was pushed into Table 12 without distinction. - Now, HSN summary is categorized into B2B and B2C for accurate reporting. Task ID: 4465102 Forward-Port-Of: odoo/enterprise#80738
Original PR description
In this commit: - Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory. - Previously, all HSN summary data was pushed into Table 12 without distinction. - Now, HSN summary is categorized into B2B and B2C for accurate reporting. Task ID: 4465102 Forward-Port-Of: odoo/enterprise#80738