Monday, March 25, 2024
38 changes · 17.0
Resolved issues and error corrections
This change corrects an internal test import in the Accounting module so upgrade checks can run without failing. It helps keep upgrade validation reliable and avoids false failures caused by a misplaced reference.
Original PR description
During upgrade got the import name error: ```ImportError: cannot import name 'code_translations' from 'odoo.addons.account.models.chart_template' ``` `code_translations` function defined in…
During upgrade got the import name error:
```ImportError: cannot import name 'code_translations' from
'odoo.addons.account.models.chart_template' ```
`code_translations` function defined in odoo.tools.translate
and there is function `get_python_translations`
by mistake give `from odoo.tools.translate import code_translations`
to correct that.
```
File "/home/odoo/src/odoo/17.0/addons/stock_account/tests/test_account_move.py", line 4, in <module>
from odoo.addons.account.tests.common import AccountTestInvoicingCommon
File "/home/odoo/src/odoo/17.0/addons/account/tests/__init__.py", line 22, in <module>
from . import test_chart_template
File "/home/odoo/src/odoo/17.0/addons/account/tests/test_chart_template.py", line 4, in <module>
from odoo.addons.account.models.chart_template import code_translations
ImportError: cannot import name 'code_translations' from 'odoo.addons.account.models.chart_template' (/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py)
```
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-prThis fix prevents accounting journals from failing when a renamed journal leaves behind an email alias that conflicts with a new journal name. Odoo now makes the alias unique using journal details, reducing setup errors during journal creation or upgrades.
Original PR description
Bad branch name, moved to https://github.com/odoo/odoo/pull/159037 Steps to reproduce: - Create an account journal. - Rename the created journal (let's say from A to B). - Create a new account journal named A. Changing the name of a journal doesn't change the name of the alias, An error caused by duplicate mail alias names will occur. Additionally the error can happen if the user has manually added aliases with the same name before upgrading to 17.0. Adding the code and company id of the journal to the alias to ensure uniqueness when an alias with the same name is already in the DB (as the combo `company_id`,`code` is unique). 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
This fix resolves a bug in the barcode scanning system where updating a product quantity in inventory adjustments would incorrectly change the product's storage location. Users can now update quantities without unintended location changes, ensuring accurate inventory tracking.
Original PR description
Before this commit, scanning a source location then update a product's line by pressing the +1 qty button will update the quant's location. The issue is: we can't edit source of an existing quant. How to reproduce: - Activate storage locations settings; - Go to Inventory > Operations > Physical Inventory; - Select all lines and press "Request a count" assigned to Mitchell Admin; - Go to Barcode > Inventory Adjustments; - Scan shelf1 (barcode is 2601892); - Click on existing line from WH/Stock then press +1 :arrow_right: The line's location is updated to Shelf 1, it shouldn't happen. OPW-3792605 Forward-Port-Of: odoo/enterprise#58655 Forward-Port-Of: odoo/enterprise#58427
Fixed an issue where tax reports generated for a VAT Unit were incorrectly displaying the company's VAT number instead of the VAT Unit's number on the PDF output. Now when users select a specific VAT Unit for reporting, the correct VAT Unit number will appear on the printed report.
Original PR description
**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number.…
**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number. **Expected behavior:** The VAT Unit number will be written to the PDF if a report is being generated with that option selected. **Steps to reproduce:** 1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it 2. In the Accounting app, go to the `Tax Report` view under the `Reporting` menu 3. Select the newly created VAT Unit for the `Tax Unit` option in the top right of the view 4. Select the `PDF` button to print the report, observe that the `VAT:` label on the report shows the Company VAT number instead of the Unit's **Cause of the issue:** The XML template for the PDF report is only setup to show the company VAT number here. **Fix:** Use the selection for the `Tax Unit:` configuration to inform the VAT number that is shown on the final report. opw-3747319 Forward-Port-Of: odoo/enterprise#59185 Forward-Port-Of: odoo/enterprise#58361
A test for tax reports was failing intermittently when run at midnight due to timing mismatches between invoice and reversal dates. The fix ensures the reversal is created on the same date as the invoice, preventing the test from failing when the system clock crosses midnight during test execution.
Original PR description
The test creates an invoice, then a reversal, then checks the report values on the day of the invoice. But currently, there is no date for the reversal, s o if the invoice is created at 23:59:59 and the reversal at 00:00:01, the reversal won't be in the report values and so, the test will fail. The solution proposed is just to create the reversal at the invoice date Linked to runbot error 59289 Forward-Port-Of: odoo/enterprise#59157 Forward-Port-Of: odoo/enterprise#58644
This fix resolves an issue where custom email text added when sending appraisals was not being saved or displayed. Users can now add personalized messages to appraisal emails, and those messages will properly appear in both the system record and the sent email.
Original PR description
## Issue:
- when you create an appraisal and you click on 'send by email' and add some text on the body of the email, it doesn't appear
nor in the chatter, nor in the email sent.
## Steps To Reproduce:
- create an appraisal
- click on SEND BY email
- add email body
- notice missing email body in the chatter.
## Solution:
- add user_body to "_compute_body" dependencies to trigger it otherwise it wont be computed and body is kept empty.
opw-3787796
Forward-Port-Of: odoo/enterprise#58374This fix corrects the identification number used when submitting Dutch tax reports to the tax authorities (Belastingdienst) through the SBR system. Previously, the wrong number was being used, which could cause submission failures or misidentification. The fix introduces a new field to properly capture and use the correct omzetbelastingnummer (VAT identification number) for accurate tax report submissions.
Original PR description
The wrong number was used for identifying the user to the Belastingdienst through SBR when submitting their Tax Report. This new field has to be added through a new module but will be correctly merged in master. opw-3786956 Forward-Port-Of: odoo/enterprise#58872 Forward-Port-Of: odoo/enterprise#58485
This update fixes performance test failures in the appointment system by removing record links from the menu header before running tests. Record links in the header were preventing proper cache behavior and causing unnecessary database queries during automated testing, which is now resolved.
Original PR description
Com PR: https://github.com/odoo/odoo/pull/157897 --- We must disable the cache for the header when there are record links in it. When the runbot performs enterprise tests, "Helpdesk" appears in the header, which includes a record link. This commit removes record like urls in the menu before doing the performance test to prevent increasing the query count. opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/enterprise#58853
This fix resolves an issue where shipper and receiver reference information was not being populated on commercial invoices created during DHL shipments. When users set up DHL shipping for sales orders and validate deliveries, the required shipper and receiver details will now be correctly included on the generated commercial invoice.
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59208
Fixed an issue where DHL commercial invoices were being created in the company's default currency instead of the sales order's currency. Now the system correctly uses the sales order currency when available, ensuring accurate invoicing for international orders with different currencies.
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177
This fix corrects incorrect depreciation board values that were being displayed for assets with a one-month depreciation period, even though the underlying depreciation records were accurate. The issue occurred when an asset's acquisition date was set to the first day of a month and used the same account for both fixed assets and depreciation. The fix ensures the board calculations properly reflect the actual depreciation values.
Original PR description
When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we enter in a condition meant for set the value of closing entry when needed, which is not the case here. As there is no way, at the moment we enter this condition, to check if the asset is ment to be closed (state is still set to 'open'), the solution is to add a context key to achieve that. opw-3750254 Forward-Port-Of: odoo/enterprise#58595
This update fixes a memory issue that was preventing large Winbooks file imports from completing on standard servers. By optimizing how data is processed during import, the memory requirement has been cut in half—from 3.1GB down to 1.6GB—making it possible to import large files on typical 2GB worker systems. The update also provides a clearer error message when files are imported incorrectly.
Original PR description
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This…
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfrecords iterator. That's because frozendict are hashable. By removing the intermediate recs and result local variables in `_import_move`, the memory peak drops to 1.6Gb, allowing to import the winbooks export on a 2gb worker. Add a more user-friendly error when there is no sub_zips in the main zip container. This can happen if the customer extracts the winbooks archive and tries to import the sub_zip directly. #### Benchmark Customer v17 database importing a 102Mb zip winbooks export containing 357825 moves. ##### Memray stats before PR, peak at 3.1Gb  ##### Memray stats after PR, peak at 1.6Gb  Forward-Port-Of: odoo/enterprise#56059
Certifications completed through surveys were incorrectly showing as expired immediately after completion because the end date was set to the completion date. This fix corrects the visual display of certifications in the reporting view and employee resume to prevent them from appearing expired when they shouldn't be. A more comprehensive fix will be implemented in the next major version.
Original PR description
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do…
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do the certification through the received link - As admin, go to "Employee" and got to "Reporting -> Certifications" - You will see the certification in red under "Marc Demo" This means that the certification is already expired and should not. When completing a certification (survey), a hr_resume_line is inserted in the database with a start_date and an end_date set to the completion date, causing the certification to be expired right away. We only do "cosmetic" correction here as the real fix will be done in master to avoid multiple upgrade: - to avoid existing certification to be displayed in red in the reporting view, we correct the display (by avoiding adding danger decoration to the line if the date_start equals the date_end). That correction won't avoid to find those certifications as expired as we can't correct the computed field as it is stored. Also, if the expiration_status column is shown (hidden by default), it will display expired on those certifications. - We do a similar correction in the display of the employee resume. Note: the end_date problem is anterior to v17 but the resume line expiration has been introduced in v17. Task-3389395
This fix resolves a crash that occurred when users tried to apply "On Hover" animations to images in blog posts. The issue happened because the animation feature requires image shapes to work, but some images couldn't support this. The fix now only shows the hover animation option when it's actually compatible with the selected image.
Original PR description
Steps to reproduce: - Go to website in "Edit" mode (on a blog post page). - Select one of the default images in the blog content. - Click on the "Animation" option and select "On Hover" > Traceback! Starting from [1], the "On hover" image animation was implemented to be able to pick an animation that triggers when hovering an image. This feature is setting a default "Square" shape (required for the hover effects to work) on the target. Which means that an error can always occur if the "On Hover" animation option is available while the targeted image is not linked to an attachment and can't support image shapes (which is the case here). The goal of this commit is to fix this issue by only allowing the "On Hover" animations when it's possible to apply shapes to the image. [1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85 opw-3795599
This fix corrects a rounding error that occurred when applying 100% loyalty discounts to orders. Previously, orders would show a remaining balance of $0.01 instead of $0.00 due to how tax calculations were being performed. The fix improves the precision of discount calculations by using a more accurate tax computation method, ensuring loyalty discounts are applied correctly.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Set tax rounding method to global; 2. create a loyalty program offering 100% discount on orders; 3. create a SO with the following line subtotals & 15% tax:…
Versions
--------
- 16.0+
Steps
-----
1. Set tax rounding method to global;
2. create a loyalty program offering 100% discount on orders;
3. create a SO with the following line subtotals & 15% tax:
1. $5.60
2. $8.92
3. $44.91
4. $217.26
5. $2400.00
4. apply the 100% discount program.
Issue
-----
Total comes down to $0.01 instead of $0.00.
Cause
-----
To calculate the `discountable` amount, the `_discountable_order` method uses the `_compute_taxes` method from `account.tax` for each line, which doesn't check for global rounding method. This can introduce small rounding errors. When calculating the discount factor by dividing the `max_discount` (total amount of the order) by `discountable`, the result will be 0.999... instead of 1 if `discountable` is off by one cent.
Solution
--------
Use the `compute_all` method instead, which factors in the tax rounding method by using increased precision.
opw-3710365
Forward-Port-Of: odoo/odoo#156897This fix resolves an issue where the product page editor was requesting to reload twice when users changed image settings, causing potential race conditions and errors. The fix ensures the page reloads only once after image changes are saved, and waits for the server request to complete before reloading. This improves the stability and responsiveness of the product editing experience.
Original PR description
Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this…
Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this was done, a data-reload was also added in the XML template of the options. This was not necessary as the data-reload only works for some methods which are not used in the image settings. Therefore, the data-reload did nothing. However, with commit [2], the settings were moved and combined with page options. So the image settings automatically inherited the page options behavior, which is to save and reload the page when a method with data-reload is called. This caused the editor to ask for a reload twice. This did not cause a problem as somehow, the second reload was ignored. But with the conversion of the SnippetsMenu to OWL, it seems like the race condition introduces an error. This commit fixes the behavior by removing the reload request after applying image settings. [1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3 [2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858 Forward-Port-Of: odoo/odoo#156658
This fix prevents users from modifying the rounding setting while a point of sale session is open. Previously, changing this setting during an active session could cause accounting discrepancies and result in unbalanced financial records. This change ensures data integrity by locking the rounding configuration until the session is closed.
Original PR description
Prior to this commit, the rounding setting could be modified while a session was open. This could potentially cause accounting discrepancies and lead to unbalanced account moves. opw-3677480 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157690 Forward-Port-Of: odoo/odoo#157447
This update corrects how the Point of Sale system calculates free product rewards when "Buy X get Y" promotions are combined with products that have specific tags. Previously, the discount calculation could be inaccurate in these scenarios, which has now been fixed to ensure customers receive the correct promotional benefits.
Original PR description
Prior to this commit, if a "Buy X get Y" promotion was in place, with a free product reward associated with a specific tag, the computation of the free product reward could be incorrect in the Point of Sale when combined with products carrying the tag. opw-3753994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157395 Forward-Port-Of: odoo/odoo#157133
This update ensures that system administrators can properly edit expenses in the HR Expense module, even when using elevated access methods. Previously, certain admin access scenarios were not recognized, preventing legitimate administrative actions. The fix now correctly identifies both system administrators and delegated admin users as having the proper permissions to manage expenses.
Original PR description
## Context: During the refactor 68fbdc964038ef6a1cf0d3df773db101ca81794a, expense rights were improved but two cases were forgotten. ## Before this commit: 1. sudo would not work as the rights were checking the groups 2. system admins were considered as being expense admins too, which may not be the case if the system admin user changes and the correct group `group_hr_expense_manager` is not given. System admins should always be able to edit expenses when it make sense. ## After this commit: Sudoed and group_system users are considered as expense admins (thx @jepbarasgarov for raising the issue ) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where calendar meeting activities were incorrectly linked to document records instead of their original tasks. When creating calendar events with attendees, the system was mistakenly updating activity links to point to newly created ICS file documents rather than maintaining the original task association. The fix prevents document creation for ICS file attachments, ensuring activities remain properly connected to their intended records.
Original PR description
Steps to reproduce: ------------------- - install calendar, project and documents; - create an activity for a task (project.task) with meeting type; - change attendee to the meeting; - save; Issue:…
Steps to reproduce: ------------------- - install calendar, project and documents; - create an activity for a task (project.task) with meeting type; - change attendee to the meeting; - save; Issue: ------ The activity is not linked to the right task. Cause: ------ When we create a `calendar.event`, when the event is at a future date, we send an email to the attendees. This email must include an attachment corresponding to the ICS file. Depending on the `no_document` context key, we may or may not create a document. When we create the document, we have a value for the `activity_ids` field (one2many) which is the ORM command for linking the newly created document. This will result in the document id being written to the `res_id` field of the `mail.activity` record. Unfortunately, the activity contains a `res_model` which is not `documents.document`. The result is that the activity is linked to a `res_id` which is not that of the model previously set for it (i.e. `project.task`). Solution: --------- Add context key `no_document` when creating an attachment for ICS files. opw-3746857 Forward-Port-Of: odoo/odoo#155873
This update fixes an inconsistency where the Sales Order Line field was not editable in task forms for users without sales access, even though it was editable in other related views. The change makes the field consistently editable across all task-related pages, improving the user experience and workflow consistency.
Original PR description
Before this commit sol field wasn't editable when user don't have any sales access and it was editable for timesheet page and project form view. This commit make SOL field in task form editable to be consistant with project form and timesheet page of tast form. task-3764793 Forward-Port-Of: odoo/odoo#158359 Forward-Port-Of: odoo/odoo#155339
This fix corrects how tax categories are assigned in electronic invoices when a supplier without VAT registration issues invoices with 0% tax rates. Previously, the system would use incorrect tax codes that violated compliance rules. Now it uses the "Exempted" category, ensuring invoices comply with international electronic invoice standards.
Original PR description
Bug: When an irish company without VAT invoices a Norvegian company with a 0% tax, the category of the tax is "K" in the Bis 3 xml, which will raise: "[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48)." Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Export outside the EU" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63)." Fix: We should only use "G" or "K" when the supplier has a VAT. If a supplier without a VAT invoices with a 0% tax, we should use the tax category "E" (Exempted). opw-3785810 Forward-Port-Of: odoo/odoo#158549
This fix improves how Odoo handles an impossible field configuration where a required field is set to delete its linked record by setting the value to null. Previously, the system would silently fail to create the database column without alerting users. Now it displays a clear error message when someone attempts this invalid setup, making it easier to identify and fix configuration mistakes.
Original PR description
Before this commit, when creating a many2one field from an xml, with an impossible combination "`required=True` - `on_delete='set null'`", the column was not created in the database without any notice to the user. This commit adds a constraint checking that any attempt to create a field with this configuration would raise a ValidationError. This constraint replaces the previous onchange method.
Fixed an issue where chat conversations remained marked as unread even after being opened, if the newest message had been deleted. Users can now properly mark chats as read regardless of whether recent messages have been deleted, improving the chat experience and reducing confusion about unread message counts.
Original PR description
Before this commit, when a user of in chat posted a message and deleted it, all other users kept the chat as unread. Steps to reproduce: - Connect as Admin and March Demo - Send a message to Admin as Demo in DM chat - Demo deletes this message - Marc opens the chat => the unread counter is 1 and cannot be removed This happens because when a message is deleted, there's still a trace of it but the message is empty. However, empty messages could not be candidate of setting the last message being seing by a member, thus members were unable to mark the chat as read until someone else posted a newer message (and did not delete it). This commit fixes the issue by taking empty messages into account for setting last message message of member, which allow to mark thread as read even when newer messages have been deleted. opw-3764410
This fix resolves an issue where ZPL labels printed for products without barcodes would display "False" as the barcode value instead of leaving it blank. Users can now print labels for products without barcodes without seeing this erroneous text on the physical labels.
Original PR description
Current behavior: When printing a ZPL label for a product without barcode, the label was printed with a barcode containing the "False" value Steps to reproduce: - Install the stock module - Create a product without barcode - Print a ZPL label for this product - The label contains a barcode with the "False" value (You can check the rendering on labelary.com) opw-3797462 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158668 Forward-Port-Of: odoo/odoo#158386
This fix prevents the critical admin user account from being accidentally deleted, which was causing thousands of support tickets. The admin user is referenced throughout the system in group configurations, and deleting it breaks application installations and causes errors. Users can still archive the account if needed for billing purposes, but deletion is now blocked to maintain system stability.
Original PR description
Purpose ======= Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin has been removed and is referenced everywhere, leading to tracebacks or the impossibility to…
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin has been removed and is referenced everywhere, leading to tracebacks or the impossibility to install a new application as res.group configurations all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness but this won't prevent developer from introducing new use cases + the user can be archived instead if we want to remove him from the pricing.
TaskID: 3802440
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#158620
Forward-Port-Of: odoo/odoo#158068This fix prevents users from accidentally deleting the default website menu, which was causing critical issues when installing new modules or creating new websites. The default menu is essential infrastructure that new features like shop and event pages depend on, so protecting it ensures the system remains functional.
Original PR description
Purpose ======= Lots of tickets (e.g. 3775298) are created because the default menu as been deleted, leading to the impossibility to install a new module, as the parent_id for new menus like /shop or /event are directly referencing the website.main_menu record, or to the impossibility to create a new website. TaskID: 3802440 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#158595 Forward-Port-Of: odoo/odoo#158070
This fix prevents users from accidentally removing master account tags, which are critical data used to define your chart of accounts. By protecting these essential tags from deletion, the system ensures your accounting structure remains intact and prevents operational issues that could arise from missing account definitions.
Original PR description
This data is used in the chart of account definition and could put the end user into a bad situation. Related ticket: 3790614 Forward-Port-Of: odoo/odoo#158367 Forward-Port-Of: odoo/odoo#157571
This update resolves crashes that occur when WebRTC video connections experience high stress. The fix leverages a browser feature now available across all major browsers (Chrome, Firefox, and Safari) that automatically handles connection state management, eliminating the need for manual error handling in these edge cases.
Original PR description
This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by…
This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by browser bugs (both in [Firefox](<https://bugzilla.mozilla.org/show_bug.cgi?id=1628139>) and in [Chromium](<https://issues.chromium.org/issues/40132342>) due to an [error](<https://github.com/w3c/webrtc-pc/issues/2508>) in the webrtc spec) that occur under stress. To prevent this sort of issue, a solution was provided in the form of an [implicit rollback](<https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setRemoteDescription#browser_compatibility>) on the remote description setter. This solution has recently become available everywhere (since Safari adopted it in [2022](<https://caniuse.com/mdn-api_rtcpeerconnection_setremotedescription_implicit_rollback>) for desktop and iOS). This allows us to simply rely on the remote description setter to handle the rollback if needed. \* Traceback: InvalidStateError: Cannot rollback local description in stable. task-3823100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the active menu item highlighting wasn't updating correctly when navigating between different product pages in the website menu. The fix disables caching for menus that contain links to product or record pages, ensuring the correct menu item is highlighted as users navigate. This maintains performance for standard menus while solving the highlighting problem for menus with product links.
Original PR description
Since [this other commit], the style indicating the active nav item stopped working if the user added record pages to the navbar. This was due to the cache system not being invalidated when switching…
Since [this other commit], the style indicating the active nav item stopped working if the user added record pages to the navbar. This was due to the cache system not being invalidated when switching from one record page to another. This commit fixes the issue by disabling the cache for the navbar if there is a record page in the menu. Other potential solutions were considered but ultimately rejected: 1. Using the record as a t-cache key. However, this would mean that if you have 60,000 visible forum posts, you would end up with 60,000 different caches. 2. Activate the correct element using JavaScript. This would lead to a duplicate logic in the JavaScript and the Python code, and it would introduces a slight lag to add the active class on the correct nav item (due to the time it takes to load and execute the JavaScript). The chosen solution is the best compromise, as it maintains the cache for most cases (website menu without records page links in it), nothing change with this commit. For problematic cases (record pages in the website menu), this commit disables the cache, which is a reasonable trade-off. Steps to reproduce the bug fixed by this commit: - Edit a website's menu - Add a link to a product page (e.g., customizable-desk) - Add a link to another product (e.g., chair-floor-protection) - Save the menu - Click on the menu link to go to customizable-desk => At this point, the active menu element is correct - Click on the menu link to go to chair-floor-protection => The active menu element does not update This commit fixes the issue (a update of the website module is needed) and adds a test to prevent regressions. Notes: - To see the issue locally, remove the --dev xml or --dev all arguments. - The same issue was occurring with other record pages (blog posts, ..). [this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/odoo#157897 Forward-Port-Of: odoo/odoo#154358
Fixed a crash that occurred when using Japanese character input with the composition menu open and pressing backspace. The fix also removes an unintended '#' character that was being inserted during certain text operations. This improves the stability and reliability of the web editor for users typing in Japanese and other languages with composition menus.
Original PR description
When typing in Japanese with Romaji input, a traceback occurred when hitting backspace to remove the only character in the editable while the Japanese character selection menu was open. This is because that case triggers an `insertCompositionText` input event with an empty string, and tries to delete the editable, which is unremovable. Since we called `_applyRawCommand` without wrapping it in `_protect`, the unremovable error caused a traceback instead of a rollback. When fixing that, an other bug appeared, which was the insertion of a `#` character. This was due to the fact that `insertText` was called with empty content, and `insertText` defaulted to the character `#` for no particular reason since the early proof of concept of the editor. task-3134566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158795
Fixed an issue where resequencing journal entries would incorrectly show an error message when a bank journal had the "Dedicated Payment Sequence" setting disabled. The system was treating payment and non-payment entries as having different sequences even though they should use the same sequence when this setting is turned off. This fix allows users to resequence mixed payment and non-payment entries without encountering an error.
Original PR description
Resequencing entries that come from payment and non payment raise a UserError, even if the journal has `payment_sequence` set to False Steps to reproduce: 1) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal with type "Bank" and "Dedicated Payment Sequence" in False. 2) Create a "Bank Statement Line" in the journal created in step "1". 3) Create and confirm a customer payment using the journal created in step "1". 4) Go to "Accounting / Accounting / Journals / Journal Entries". Select journal entries created on step "2" and "3" and then click on Action --> Resequence. Then a User Error is being show "The sequences of this journal are different for Payments and non-Payments but you selected some of both types." it is not correct as the journal created on step "1" has the field "Dedicated Payment Sequence" set to "False". opw-3763500 Forward-Port-Of: odoo/odoo#157988
This fix enables the system to find states using their display name, which aligns with how states are exported from the system. This makes data import and lookup processes more consistent and user-friendly, reducing errors when working with state information across different parts of the application.
Original PR description
That is how states are (might be?) exported, so it should be possible to find them the same way. Task-Id: 3644762 Forward-Port-Of: odoo/odoo#158376 Forward-Port-Of: odoo/odoo#157428
This fix prevents unexpected errors in the web editor that could cause the editor to crash and delete all content before saving. The issue occurred when resetting editor content, which could trigger a chain of errors leading to data loss. The fix ensures the editor handles edge cases gracefully without crashing.
Original PR description
A traceback was spotted when `unserializeNode` was called as a result of a call to `resetContent`. That traceback could lead to other tracebacks (including one when trying to read a history step's ID in `_historyMakeSnapshot`). A traceback at that moment could remove all the content of the editor before saving. This commit ensures the argument passed to `unserializeNode` is defined, that `unserializeNode` returns `undefined` if it couldn't return anything valid, and that when such is the case the caller handles that undefined return value properly. task-3677431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158009
This fix resolves an issue where product traceability history was lost after unpacking items from a package. When users unpacked a package, the system was clearing package information from inventory records, causing the history lookup to fail. Now the system properly maintains traceability information so users can view the complete movement history of products even after unpacking.
Original PR description
In Inventory Settings activate packages and storage locations. Create a storable product [TEST] with tracking by lot Create a PO for [TEST] with a [QTY] larger than one. Receive the products (lot [A]) and put them in a package [PKG]. Create and process an internal transfer of the whole package [PKG] from the input location to any location. Unpack [PKG]. Go to Stock > Reporting > Locations Locate the received product, hit 'History' Issue: traceability is empty. This occurs because the 'unpack' operation clean the information relative to the package from the stock quant. When accessing the history, the system lookup for move lines having the same package (none in this case), so nothing is found opw-3769752 Forward-Port-Of: odoo/odoo#158840 Forward-Port-Of: odoo/odoo#158410
Fixed a bug in the web editor where applying text formatting (like bold, italic, etc.) to unbreakable inline elements without classes would immediately undo the formatting. The editor was incorrectly trying to remove the unbreakable element when applying the format, causing the change to be rolled back. This fix ensures formatting is properly applied and retained.
Original PR description
When applying a format in an unbreakable inline (without a class), the format was immediately rolled back as we tried to remove split the unbreakable in order to remove its style. task-3768157 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158138 Forward-Port-Of: odoo/odoo#155510
This update fixes two issues with table editing in right-to-left languages like Arabic. First, it corrects the column move function so the action matches the label and icon direction. Second, it fixes column resizing functionality which was not working properly in RTL mode. These fixes ensure a consistent and intuitive experience for users working with tables in Arabic and other RTL languages.
Original PR description
Issue 1: ====== The icons does match the direction of the move but it doesn't match the label in the ltr language. Steps to reproduce the issue: ============================= - Install arabic - Go to…
Issue 1: ====== The icons does match the direction of the move but it doesn't match the label in the ltr language. Steps to reproduce the issue: ============================= - Install arabic - Go to notes and insert a table - write something in a column in the middle - Click on the top of the column on the 3 points. - The first item of the dropdown have the label in arabic meaning `Move to left` but the direction of the icon and clicking on it will move it to the right. Origin of the issue: ==================== - The icon is being flipped because we are in rtl but in realtity left is the same for rtl or ltr direction. - We need to call `_onTableMoveLeftClick` when we are moving to the right in rtl because the left of rtl direction is the visible right. Issue 2 : ====== resizing columns doesn't work properly in rtl direction. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - insert a table - Try to resize columns Solution: ========= We will handle the cases one by one: Start: We need to update the `marginRight` prop instead of `marginLeft` and calculate `sizeDelta` correctly which `clientX - (rect.x + rec.width)`. Middle: We will handle this the same as ltr direction, since it's the reverse direction, we swap `previous` with `next` and `next` with `previous`. Columns are sorted from right to left so we need to swap columns when we recalculate them from the columns array so `item` will be the one on the left and `neighbor` the one on the right. last: We calculate correctly `sizeDelta` which is `rect.x - clientX` task-3721794 Forward-Port-Of: odoo/odoo#157508
This update brings the spreadsheet component to the latest version with multiple bug fixes and improvements. The changes address issues with formula input, data export, undo/redo functionality, and user interface elements to provide a more stable and reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9b128f8c [REL] 17.0.16 https://github.com/odoo/o-spreadsheet/commit/389177f9 [FIX] Composer: weird behavior of…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9b128f8c [REL] 17.0.16 https://github.com/odoo/o-spreadsheet/commit/389177f9 [FIX] Composer: weird behavior of autocomplete dropdown https://github.com/odoo/o-spreadsheet/commit/7e7b0692 [FIX] formula assistant: localize argument separator Task: 3789860 https://github.com/odoo/o-spreadsheet/commit/2f96ca07 [FIX] TopBar: Remove hidden functions from the `insert` menu Task: 3810284 https://github.com/odoo/o-spreadsheet/commit/fa60ddf1 [FIX] Composer: force light mode of the formula assitant Task: 3806513 https://github.com/odoo/o-spreadsheet/commit/69ccee4f [FIX] cf_editor: remove broken css rule Task: 3806513 https://github.com/odoo/o-spreadsheet/commit/dd7584ec [FIX] Spreadsheet: split button style to form/color https://github.com/odoo/o-spreadsheet/commit/fe4ffe1d [FIX] export: export non-Excel formulas as value https://github.com/odoo/o-spreadsheet/commit/0be37a0d [FIX] FigureComponent: Undo/Redo broken after pasting figure https://github.com/odoo/o-spreadsheet/commit/d1e41517 [FIX] evaluation: accept 1x1 result array in sub-formula