Friday, February 28, 2025
25 changes · 18.0
Resolved issues and error corrections
Product labels printed in Dymo format now show longer product reference numbers without cutting them off. This helps ensure labels contain complete product information and reduces confusion when scanning or identifying products.
Original PR description
**Issue:** When printing labels in Dymo format, product reference numbers longer than 10 digits are truncated, resulting in incomplete information. **Steps to Reproduce:** 1. Install the Sales app 2.…
**Issue:** When printing labels in Dymo format, product reference numbers longer than 10 digits are truncated, resulting in incomplete information. **Steps to Reproduce:** 1. Install the Sales app 2. Navigate to Sales > Products 3. Select or create a product with a reference number longer than 10 digits 4. Click Print Labels > Dynamo format > Confirm 5. Notice that the reference number is cut off after 10 digits Expected Behavior: The full reference number should be visible on the product label, regardless of length Actual Behavior: Reference numbers longer than 10 digits are truncated, showing only the first 10 digits. **Root Cause** The issue arises from a override(https://github.com/odoo/odoo/commit/2b32d1431a33dea9052be3be4f9668a92cd0422e) to the font size of the <small> tag added to Bootstrap. Previously, the font size was set to 0.875em, but it has been updated to 0.8125rem. This change affects text rendering and causes a smaller number of digits to be displayed compared to previous versions. **Fix** To maintain consistency with Odoo 17.0, the font size of the <small> tag is explicitly overridden to ensure the same number of digits is displayed as before. Opw-4578147 Opw-4568804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Non-editable buttons in Knowledge embedded views now show the expected pointer cursor instead of a text cursor. This makes menus and buttons feel clickable and reduces confusion for users interacting with embedded content.
Original PR description
In Knowledge, non-editable buttons in embedded views (cog menu, ...) use a text cursor, which is incorrect as they are not editable buttons. This is because the CSS rule that resets pointer cursors in the editor within non-editable elements only applies to .btn.btn-link elements. This commit makes it so that this rule applies for all .btn elements within non-editable elements. task-4558391
The in-store pickup availability widget is now hidden or disabled when a shopper selects a product option combination that cannot be sold. This prevents an error page and keeps the product page usable during variant selection.
Original PR description
Steps to reproduce: 1) Configure pick up in store dm and publish it 2) Go to product page of a customizable desk 3) Choose the impossible combination (Aluminium and black) 4) Observe traceback Reason: Necessary fields are absent in combination info when the combination is not possible. Solution: Do not render the widget when a combination is not possible.
This fixes a crash that could occur when manually duplicated IAP accounts shared the same token, especially for SMS-related accounts. Businesses benefit from more reliable loading of IAP account information, even when account data contains unintended duplicates.
Original PR description
If there are IAP accounts that share the same token, it would cause a crash when fetching the accounts information from the IAP server. It wasn't anticipated that two IAP account records could share the same token. This doesn't happen under normal circumstances, it can only happen if the accounts were manually duplicated (which should never be done). The error actually only happens for duplicated SMS accounts, as the function `_get_account_info` in which the crash occurs is compatible with recordset containing > 1 record in the main definition, but not in the override of the SMS module. opw-4571624
This fix makes an automated accounting walkthrough wait until a form is fully saved and closed before continuing. It reduces intermittent test failures, helping keep the accounting app validation process more stable without changing user-facing functionality.
Original PR description
Seems like the tour takes steps while there may have been a delay in the web_save... seeming like there is an open form view in edition mode. runbot-111772
Fixed a visual issue in Knowledge where the comment icon could jump around or get stuck in the wrong place when users zoomed in Chromium-based browsers. This makes commenting in Knowledge more stable and less distracting for users working at different zoom levels.
Original PR description
In Knowledge, on chromium-based browsers, zooming at certain levels will cause the comment icon to flail around the editor and lock in unwanted places. (This behavior was not reproductible in Firefox.) To circumvent this, the margin calculations for the purposes of calculating the comment icon horizontal location are now done manually. task-4558391
Changing the start date on a subscription upsell order now automatically updates the prorated discount description. This helps ensure customers and sales teams see accurate dates on upsell order details.
Original PR description
Vesrion: - 18.0 Steps to reproduce: - Create upsell order. - Change start date of upsell order. - Prorata discount description date not changed. issue: - Subscription Upsell start date is not updated fix: - The upsell description now recalculates automatically if the upsell start date is changed. OPW-4393131
The recruitment stage report now produces stable, consistent results by preventing duplicate or unpredictable internal record IDs. This helps users see reliable recruitment reporting data instead of occasional inconsistent report behavior.
Original PR description
Unexpected IDs were retrieved from the `hr_recruitment_stage_report` view because the view query uses `ROW_NUMBER()` to generate the IDs dynamically, resulting in non-deterministic behavior. An `ORDER BY` clause needs to be applied to ensure the view is ordered consistently. task-4440977
Code cleanup and technical improvements
The Vendor Bills smart button on partner records is now provided by the Accounting module instead of Purchase. This keeps the button available where accounting features are managed while avoiding duplicate buttons when both modules are installed or updated.
Original PR description
Move the Vendor Bills smart button from the `purchase` module to the `account` module. The views records in `purchase` module are kept as but made empty so that if the user updates the `account` module, it will also update the `purchase` module and hide the smart button from the `purchase` to only keep the new one from the `account` module. task-4584035
Miscellaneous changes
**Current behavior:** Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice. **Expected behavior:** With manual valuation, there should not be pdiff AMLs. **Steps to reproduce:** 1. Create a product with average costing and manual valuation 2. Receive 10 units @ $100 to establish some std price 3. Consume the 10 product qty (scrap, sale, ...)
Original PR description
**Current behavior:** Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice. **Expected behavior:** With manual valuation, there should not be pdiff AMLs. **Steps to reproduce:** 1. Create a product with average costing and manual valuation 2. Receive 10 units @ $100 to establish some std price 3. Consume the 10 product qty (scrap, sale, ...) 4. Create the invoice on the purchase order 5. Change the price unit on the bill to $120 per product -> post 6. In the journal items tab on the invoice, see the pdiff AMLs **Cause of the issue:** No consideration for valuation when creating the AMLs for pdiff. **Fix:** Check that valuation is not manual prior to creating the AMLs. opw-4492217 Forward-Port-Of: odoo/odoo#197009 Forward-Port-Of: odoo/odoo#196786
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
Original PR description
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199599
Original PR description
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199599
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196950 Forward-Port-Of: odoo/odoo#190704
To reproduce: 1. Create an Analytic Account 2. Use this Analytic Account in an account move and post it. 3. Return to the Analytic Account and delete it. The deletion goes through. 4. The move no longer has the Analytic Account. The issue: Currently, an Analytical Account can be deleted even if it has been used in an analytic item, be it a move or an analytic simulation. Hence, the move no longer has the analytic account that was added when the move was posted, without any warnings to th
Original PR description
To reproduce:
1. Create an Analytic Account
2. Use this Analytic Account in an account move and post it.
3. Return to the Analytic Account and delete it. The deletion goes through.
4. The move no longer has the Analytic Account.
The issue:
Currently, an Analytical Account can be deleted even if it has been used in an analytic item, be it a move or an analytic simulation. Hence, the move no longer has the analytic account that was added when the move was posted, without any warnings to the user.
Solution:
Make the fields "x_plan{id_}_id" on analytic lines ondelete='restrict'. An upgrade script is added to handle existing analytic accounts.
task-4567137
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#199305
Forward-Port-Of: odoo/odoo#197886**Problem**: When the editor gains `focus` for the first time, `_latestComputedSelection` is set. However, `_resetFromClient` is then called to synchronize history steps with another client, recreating the nodes in the editor. This causes new node `oid`s to be generated (so we can't match with the `oid`s), invalidating the existing `_latestComputedSelection` (its `anchorNode` and `focusNode` no longer point to valid nodes). **Solution**: Before recreating the history, save the selection pat
Original PR description
**Problem**: When the editor gains `focus` for the first time, `_latestComputedSelection` is set. However, `_resetFromClient` is then called to synchronize history steps with another client,…
**Problem**: When the editor gains `focus` for the first time, `_latestComputedSelection` is set. However, `_resetFromClient` is then called to synchronize history steps with another client, recreating the nodes in the editor. This causes new node `oid`s to be generated (so we can't match with the `oid`s), invalidating the existing `_latestComputedSelection` (its `anchorNode` and `focusNode` no longer point to valid nodes). **Solution**: Before recreating the history, save the selection path. This allows the selection to be restored accurately from the newly created nodes. **Steps to reproduce**: 1. Open a task in one browser tab and start editing. 2. Keep that tab open. 3. Open the same task in a second browser tab. 4. Click to start editing in the second tab. 5. Observe that the cursor moves back to the start of the description in the first tab. opw-4235013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191816
Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197162 Forward-Port-Of: odoo/odoo#190703
Original PR description
Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197162 Forward-Port-Of: odoo/odoo#190703
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and w
Original PR description
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting…
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and we don't want to change that in stable (or we need to backport part of https://github.com/odoo/odoo/pull/182709). #### Original commit message Explicitly prevent calling non-public ORM methods via RPC, without breaking the API The ORM contains a series of API methods found on Models and recordsets, next to the main CRUD methods. Those utility methods are very commonly used in server-side business logic code, and were historically named without the usual underscore prefix that should mark them as private (e.g. `_private_method()` vs `public_method()`). Examples: - the `browse()` method returns a recordset from a list of IDs, which is really just a proxy object prepared for other recordset operations ; - the `fetch()` and `search_fetch()` methods populate the transactional in-memory cache for a set of fields and record ; - and many more... The lack of prefix makes writing business logic code a bit simpler, but causes confusion because these methods look like they are public. Of course, calling such internal methods over RPC doesn't make sense, and may crash or cause unexpected results. This commit marks those internal methods and prevents calling them over RPC. This is preferred over renaming them with an underscore prefix, as that would break a lot of existing code without a good reason. All business logic code must still follow the best-practicce convention of prefixing non-public method with underscores, by default and by design, to avoid mixing different conventions. The `@api.private` decorator is reserved for exceptions for ORM methods. task-4505030 https://github.com/odoo/enterprise/pull/79382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199253 Forward-Port-Of: odoo/odoo#197783
This line would consistently crash with: `NameError: name '_' is not defined` Forward-Port-Of: odoo/odoo#199629
Original PR description
This line would consistently crash with: `NameError: name '_' is not defined` Forward-Port-Of: odoo/odoo#199629
- While calling `_generate_primary_snippet_templates`, `create_missing_views` fetches the existing snippet views. However, archived snippet is ignored, causing `create_missing_views` to attempt to create the snippet again, mistakenly considering it as a missing view. This leads to a traceback: ```py File "/data/build/odoo/odoo/sql_db.py", line 332, in execute res = self._obj.execute(query, params) psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_mod
Original PR description
- While calling `_generate_primary_snippet_templates`, `create_missing_views` fetches the existing snippet views. However, archived snippet is ignored, causing `create_missing_views` to attempt to create the snippet again, mistakenly considering it as a missing view. This leads to a traceback:
```py
File "/data/build/odoo/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_model_data_module_name_uniq_index"
DETAIL: Key (module, name)=(website, new_page_template_services_0_s_website_form) already exists.
```
- To prevent such errors, it's better to fetch inactive views as well during creation.
opw-4510585
upg-2452055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197107The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#59500 Forward-Port-Of: odoo/enterprise#52832
Original PR description
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#59500 Forward-Port-Of: odoo/enterprise#52832
Steps to reproduce: 1) Configure 2 rental products (product1 and product2) 2) Add at least 1 pricing period to product2 3) Set product2 as accessory product to product1 4) Go to /shop page and add product1 5) Go to the cart and observe the broken layout of suggested accessories opw-4463981 Forward-Port-Of: odoo/enterprise#80385
Original PR description
Steps to reproduce:
1) Configure 2 rental products (product1 and product2)
2) Add at least 1 pricing period to product2
3) Set product2 as accessory product to product1
4) Go to /shop page and add product1
5) Go to the cart and observe the broken layout of suggested
accessories
opw-4463981
Forward-Port-Of: odoo/enterprise#80385Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#80279 Forward-Port-Of: odoo/enterprise#78530
Original PR description
Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#80279 Forward-Port-Of: odoo/enterprise#78530
Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#78968 Forward-Port-Of: odoo/enterprise#75666
Original PR description
Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#78968 Forward-Port-Of: odoo/enterprise#75666
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80346 Forward-Port-Of: odoo/enterprise#80052
Original PR description
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80346 Forward-Port-Of: odoo/enterprise#80052
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#80147 Forward-Port-Of: odoo/enterprise#79382
Original PR description
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#80147 Forward-Port-Of: odoo/enterprise#79382