Daily updates from Odoo
Friday, May 15, 2026
106 changes
30 changes
Resolved issues and error corrections
This update ensures that when you right-click on a link within an email message in Odoo, you see the standard browser context menu options instead of the email-specific actions. The fix addresses a technical issue related to how Odoo handles right-clicks within shadow DOMs, improving the user experience.
Original PR description
Before this commit, when right-clicking on a link in a message of type email, this shows the message actions rather than the browser context menu. We expect to display the browser context menu, as…
Before this commit, when right-clicking on a link in a message of type email, this shows the message actions rather than the browser context menu. We expect to display the browser context menu, as there are many handful feature of browser context menu for links. This was handled in earlier fixes [1][2], but these fixes were not working with messages of type email. This didn't work because messages of type email are inside a shadow DOM, so `ev.target` is necessarily the shadow root and not the specific targeted element. This commit fixes the issue by using `ev.composedPath()` to pick the 1st element, so that this exposes the inner-most element inside the shadow DOM that has been right-clicked. This lets us ignore the showing of message actions in right-click when this comes from a link. opw-6110949 [1]: https://github.com/odoo/odoo/pull/244252 [2]: https://github.com/odoo/odoo/pull/258681 Before / After <img width="441" height="243" alt="before" src="https://github.com/user-attachments/assets/f274e8d2-66af-442e-9a31-27ea1ce4d9bd" /> <img width="605" height="513" alt="after" src="https://github.com/user-attachments/assets/3e241e83-93d0-47e6-970c-b5e5f339417d" /> Forward-Port-Of: odoo/odoo#263880 Forward-Port-Of: odoo/odoo#263622
This update corrects a recent issue with tax settings for Thailand, resolving problems with the tax configuration. The change ensures accurate tax calculations and reporting for Thai businesses using Odoo. This fix was implemented following a thorough review and approval process.
Original PR description
The recent commit aca2e1f introduced a change in the taxes for Thailand, which caused issues with the tax configuration. This commit fixes the misconfigured taxes for Thailand. task-6212023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where unreconciling payments on recurring invoices would incorrectly generate a new invoice for the following month. The change adds a context flag to prevent this automatic invoice creation, ensuring accurate invoice generation and reducing potential accounting errors. This improves invoice management and reporting.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/odoo#263991
This update fixes an issue where unreconciling a payment on a recurring invoice would automatically generate a new draft invoice for the following period. The change adds a context flag to prevent this behavior, ensuring invoices are created correctly after reconciliation. This improves invoice management and reduces potential errors.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/enterprise#117011
This update resolves a technical issue where the payroll calculation wasn't correctly triggered when a default value was set for a specific field. The fix ensures that the payroll computation always functions as intended, regardless of the initial value assigned to the field. This improves the reliability of payroll processing.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332 Forward-Port-Of: odoo/enterprise#115785 Forward-Port-Of: odoo/enterprise#113102
This update corrects a bug that prevented the chart type picker from functioning correctly for gauge charts (scorecards). The previous method incorrectly checked chart type support, failing when gauge charts lacked a necessary data source. This change ensures the chart picker works reliably for all chart types.
Original PR description
The chart type picker was using `chart.getSupportedChartTypes()` to check which charts the current chart can switch to. But this didn't work for gauge/scorecards, as they don't have a dataSource and `getSupportedChartTypes` would return an empty set. Task: [6179286](https://www.odoo.com/web#id=6179286&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update resolves a problem where uploaded payment proofs were being corrupted and not properly attached to employee records. The fix ensures that payment proof files are now correctly attached to chatter notifications in their original format, improving the functionality of the HK payroll module.
Original PR description
### Current behavior: Uploading a proof of payment on an employee rental record raises `binascii.Error: Incorrect padding`, and posts a corrupted attachment to the chatter. Expected behavior: The uploaded payment proof file is attached to the chatter notification with its original bytes intact. ### Steps to reproduce: - Install l10n_hk_hr_payroll - Open an HK employee's rental record - Upload a file in the Payment Proof field - Observe the RPC error, or check the attachment in the chatter ### Fix: `fields.Binary` now returns a `BinaryValue` (raw bytes wrapper) instead of a base64-encoded string. `_log_new_payment_proof` was still running `base64.b64decode` on the field value, which mangled the contents. Pass the raw bytes via `.content` directly to `message_post`, which already expects non-base64 payloads. opw-6211986
This update resolves an inconsistency in Odoo's time off reporting. Previously, employee names were displayed fully in the Gantt view of payrun time off, which didn't align with the rest of the time off application. This change hides employee names from the Gantt view, ensuring a more uniform and professional user experience.
Original PR description
In payrun time off step, we get the full name of the employee in the Gantt view. But it is inconsistent with the rest of the time off application. Hide employee names from the Gantt view of Payrun Time Off. task-6190437
This update fixes a technical issue in the Odoo Enterprise payroll testing environment. The previous system relied on the current year for payrun dates, which was unreliable. This change ensures accurate salary computations by setting a fixed year for test payruns.
Original PR description
This commit fixes year for the test payrun as relying on today's year is not reliable to verify salary computations. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/237683 Forward-Port-Of: odoo/enterprise#117204
This update corrects a visual issue on invoices where section line content was misaligned when prices were hidden and the country of origin was displayed. The fix ensures that tax and amount columns align correctly, improving invoice presentation and accuracy. This resolves a problem primarily impacting reports with origin country data.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/odoo#264118 Forward-Port-Of: odoo/odoo#263499
This update corrects a visual misalignment on invoices when product prices are hidden and the country of origin is displayed. The fix ensures that tax and amount information for section lines are correctly aligned within the invoice PDF, regardless of price visibility. This improves the professional appearance and accuracy of invoices generated with the account_intrastat module.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/enterprise#117092 Forward-Port-Of: odoo/enterprise#115442
This update removes a misleading warning that appeared when sequences didn't start at number 1. Starting sequences at 1 is a standard and accepted practice, so this change streamlines the user experience by eliminating the unnecessary notification. It improves clarity and reduces potential user confusion.
Original PR description
We don't want to warn users about their sequence not starting at 1 as it is a perfectly valid case. This removes the warning both in the list view and in the dashboard. task-5253768 Forward-Port-Of: odoo/odoo#263117 Forward-Port-Of: odoo/odoo#235117
This update resolves an error that occurred when loading sample data for work orders. The fix ensures that the system correctly handles missing BOM line information, preventing a 'NoneType' error. This improves the reliability of sample data loading and allows users to consistently utilize the work order functionality.
Original PR description
Currently, an error occurs when loading sample data in work orders. **Steps to Reproduce:** - Install `mrp_workorder` without demo data. - Go to `Settings` > `Users & Companies` > `Groups` and open…
Currently, an error occurs when loading sample data in work orders. **Steps to Reproduce:** - Install `mrp_workorder` without demo data. - Go to `Settings` > `Users & Companies` > `Groups` and open the `Manage Work Order Operations` group. - Add the `administrator` to the `users` list. - Open the `Shop Floor` and, if you see `Activate your Work center`, click on it and then click `Configure Later`. - Click on `Load Samples`. `AttributeError: 'NoneType' object has no attribute 'id'` After this [recent commit], sample data loading in mrp_workorder started linking Quality Points to a specific BOM line [1] using the provided sample data [2]. However, some sample entries contain None [3] as the bom_line, which raises the error [1]. This commit ensures that the BOM line ID is only set when a BOM line exists. [recent commit]: https://github.com/odoo/enterprise/commit/c2a3e89c3ff5bc201bf7307b3b7d322d7bd0eecc [1]- https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L233 [2]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L251 [3]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L242 sentry-7475493233
This update allows all Point of Sale users to record cash inflows and outflows, regardless of their invoicing access rights. Previously, this functionality was restricted, which created a bottleneck. This change simplifies the cash management process within Point of Sale and ensures consistent operation for all users.
Original PR description
Cash In/Out was gating on `account.group_account_invoice` even though the backend operation (`account.bank.statement.line` creation) is no different from what session closing already does under sudo(). Lower `_has_cash_move_perm` to `point_of_sale.group_pos_manager`, add `sudo()` to the create call. opw-6192176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263580
This update resolves an issue where users would lose focus when searching in the company switcher dropdown. The fix ensures the search input remains focused, providing a smoother and more reliable experience for selecting companies. It prevents interruptions during typing and improves usability.
Original PR description
If a user leaves their mouse resting over a company in the dropdown and starts typing in the search bar, the search bar loses focus, interrupting their typing and removes focus from the search input. Update the `onSearch` method to: - Remove focus from the highlighted dropdown item. - Put focus immediately back into the search input. - Briefly disable mouse events on the menu (for 100ms). This prevents the system from registering a fake mouse hover while the list updates. Forward-Port-Of: odoo/odoo#259369
This pull request updates the core spreadsheet component within Odoo. It addresses several minor bugs and improvements related to chart functionality, named ranges, and overall stability. These changes ensure a smoother and more reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1dc7b420e5 [REL] 19.3.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1dc7b420e5 [REL] 19.3.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9fcc001827 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050) https://github.com/odoo/o-spreadsheet/commit/8434bc3e93 [FIX] chart: cannot change chart type with gauge/scorecard [Task: 6179286](https://www.odoo.com/odoo/2328/tasks/6179286) https://github.com/odoo/o-spreadsheet/commit/43a43780cc [FIX] named range: keep dropdown open on hover [Task: 6167171](https://www.odoo.com/odoo/2328/tasks/6167171) https://github.com/odoo/o-spreadsheet/commit/a68a53df3e [FIX] composer: add flex-grow-1 to value container [Task: 6159426](https://www.odoo.com/odoo/2328/tasks/6159426) https://github.com/odoo/o-spreadsheet/commit/9a27e65347 [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/35017e4aba [REL] 19.3.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/02d9577708 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/72ec725781 [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a bug preventing users from correctly selecting gauge chart types (like scorecards) within the spreadsheet edition. The previous system incorrectly identified these charts, leading to a limited selection of available chart types. This change ensures all chart types are accessible, improving usability.
Original PR description
The chart type picker was using `chart.getSupportedChartTypes()` to check which charts the current chart can switch to. But this didn't work for gauge/scorecards, as they don't have a dataSource and `getSupportedChartTypes` would return an empty set. Task: 6179286
This update corrects a visual issue in the Treehouse theme where the payment confirmation message was incorrectly styled, appearing compressed. The fix ensures the message is displayed properly and aligns with the theme's design, improving the user experience for customers using this theme. This resolves a specific problem isolated to the Treehouse theme.
Original PR description
Steps to reproduce: 1) Select the Treehouse theme from the website editor 2) Add a product to the cart and proceed to payment 3) Complete the payment and reach the confirmation page Issue: - The payment success alert message is not displayed properly and appears slightly below the alignment. - Also this particular issue is coming in this Treehouse theme only in rest of the themes the alert message is coming correctly. opw-5976602 Forward-Port-Of: odoo/odoo#257768
A bug was preventing the 'Two-factor authentication Disabled' filter from working correctly in the user list. This update corrects a technical issue within Odoo's database search functionality, ensuring the filter accurately displays users without two-factor authentication. Tests have been added to verify the fix.
Original PR description
Issue: In the user view list, the "Two-factor authentication Disabled" filter doesn't work (return the same result than the "Two-factor authentication Enabled").
Explanation: The ORM normalises `=`/`!=` to `in`/`not in` with list values (commit odoo/odoo#191549 - 92301a5b300d). `_totp_enable_search` only handled the legacy scalar form: `value` is now always a list of boolean then always truthy then `[('totp_enabled', '=', False)]` returned users *with* a totp secret, the opposite of what was asked.
Fix it and add tests for it.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264412
Forward-Port-Of: odoo/odoo#264027This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. It addresses a previous memory leak and leverages newer PDF library versions for better performance, particularly with large reports. The result is faster report creation and smaller file sizes.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#264550 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF document generation by compressing files after merging, resulting in significantly smaller file sizes. It also addresses a memory issue in the PDF processing, leading to improved performance, particularly with large documents. The change reduces storage needs and speeds up document creation.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117372 Forward-Port-Of: odoo/enterprise#115550
This update prevents Odoo servers from crashing when the registry fails to load, specifically during worker startup. Previously, timeout errors would cause disruptions. Now, the system handles these errors gracefully, ensuring smoother operation and preventing unnecessary downtime.
Original PR description
When the registry fails to load, don't log the error when the query timeouts. The error is already raised and will be handled or logged appropriately. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
**[FIX] base: avoid evaluating true domains when validating domain** During validating, the domain validation may trigger a search on the comodel to ensure the domain is valid. After [1], the validation still performs the search with Domain True [here] because it ``search_domain`` is override because of [comodel_domain] is False with ``Domain.True`` to handle this checking if already ``search_domain`` is False or not ```py Traceback (most recent call last): File "/home/odoo/src/odoo/
Original PR description
**[FIX] base: avoid evaluating true domains when validating domain** During validating, the domain validation may trigger a search on the comodel to ensure the domain is valid. After [1], the…
**[FIX] base: avoid evaluating true domains when validating domain**
During validating, the domain validation may trigger a search on the comodel to ensure the domain is valid.
After [1], the validation still performs the search with Domain True [here] because it ``search_domain`` is override because of
[comodel_domain] is False with ``Domain.True`` to handle this checking if already ``search_domain`` is False or not
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.3/odoo/service/server.py", line 1643, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/func.py", line 67, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/registry.py", line 224, in new
load_modules(
File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 467, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 222, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/saas-19.3/odoo/modules/loading.py", line 61, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 716, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 815, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 686, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 639, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/saas-19.3/ai/security/security.xml:4
Invalid domain ['|', ('attachment_id.public', '=', True), ('attachment_id.res_access_read', '=', True)]: Cannot search, too many attachments
View error context:
'-no context-'
```
[here]: https://github.com/odoo/odoo/blob/4561e703128963d566a16ab1356c7ef12e44256a/odoo/addons/base/models/ir_attachment.py#L643
[1]: https://github.com/odoo/odoo/pull/260753
[comodel_domain]: https://github.com/odoo/odoo/blame/afca863b750ec58f5414a5d47e2e2a64e3eba598/odoo/orm/domains.py#L1440-L1442
**[FIX] base, mail: Fix UserError checking field desciption**
during opening menu if field is comodel with ``ir.attachment`` it do fail on checking description field is groupable while
``res_access_read`` search do call because big database can have more attachment. So it will equal with search limit which is used.
To fix,
Value error is raised to prevent blocking
```py
41239- File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 344, in crawl_menu
41240- self.mock_action(action_vals)
41241- File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 357, in mock_action
41242- return self.mock_act_window(action)
41243- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41244- File "/tmp/tmpci4qg_2w/migrations/base/tests/test_mock_crawl.py", line 441, in mock_act_window
41245- views = get_views(
41246- ^^^^^^^^^^
41247- File "/home/odoo/src/odoo/saas-19.3/addons/mail/models/mail_thread.py", line 489, in get_views
41248- res = super().get_views(views, options)
41249- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41255- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41256- File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_ui_view.py", line 2947, in get_views
41257- result['models'][model] = {"fields": self.env[model].fields_get(
41258- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
41259- File "/home/odoo/src/enterprise/saas-19.3/web_studio/models/ir_model.py", line 77, in fields_get
41260- return super().fields_get(allfields, attributes=attributes)
41261- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41262- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2637, in fields_get
41263: description = field.get_description(self.env, attributes=attributes)
41264- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41265: File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 933, in get_description
41266- value = value(env)
41267- ^^^^^^^^^^
41268- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 989, in _description_groupable
41269- model._read_group_groupby(Query(model).table, groupby)
41270- File "/home/odoo/src/odoo/saas-19.3/addons/analytic/models/analytic_mixin.py", line 145, in _read_group_groupby
41271- return super()._read_group_groupby(table, groupby_spec)
41272- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41273- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2080, in _read_group_groupby
41274- sql_expr = field.join(table, only_ids=True).id
41275- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41276- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields_relational.py", line 1773, in join
41277- coquery = comodel._search(codomain, bypass_access=self.bypass_search_access)
41278- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41279- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4778, in _search
41280- sec_domain = sec_domain.optimize_full(self_sudo)
41281- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41305- File "/home/odoo/src/odoo/saas-19.3/odoo/orm/domains.py", line 484, in _optimize
41306- previous, domain = domain, domain._optimize_step(model, next_level)
41332- ^^^^^^^^^^^^^^^^^^^^^^
41333- File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_attachment.py", line 478, in <lambda>
41334- search=lambda self, operator, value: self._search_res_access('read', operator),
41335- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41336- File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_attachment.py", line 645, in _search_res_access
41337- raise UserError(self.env._("Cannot search, too many attachments"))
41338- odoo.exceptions.UserError: Cannot search, too many attachments
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an error that occurred when users attempted to provide feedback within live chats managed by chatbots. The issue stemmed from a configuration mismatch within the livechat system, which was corrected to ensure proper feedback processing. This prevents a technical error from appearing in the terminal.
Original PR description
Currently an error occurs when user tries to give feedback on livechat that has a chatbot. Steps to replicate: - Install `im_livechat` with demo. - Open Livechat > On Support Bot, Click `Configure…
Currently an error occurs when user tries to give feedback on livechat that has a chatbot.
Steps to replicate:
- Install `im_livechat` with demo.
- Open Livechat > On Support Bot, Click `Configure Channel` from Kebab menu (3 dots menu).
- Go to Widget page > Copy the support link (bottom one) > and open it in an incognito tab.
- Open the chat > chat atleast once > Close the chat.
- Click on any of the smileys (i.e. give feedback) and click send.
- The error will occur on the terminal.
Error:
```
File '/home/odoo/src/odoo/saas-19.3/addons/mail/tools/discuss.py', line 228, in __init__
assert bus_channel or not (notification_payload or notification_type), (
AssertionError: Notification parameters only make sense when a bus channel is passed.
```
Cause:
- As the livechat was managed by chatbot, it has no `livechat_agent_partner_ids` linked. This causes `rated_partner` [1] to be an empty recordset.
- So when initializing the Store [2] `rated_partner.sudo().user_ids` becomes an empty recordset. This causes the error to occur as the assertion fails [3] as the `bus_channel` is an empty recordset.
Solution:
- Updated the assertion to keep the behavior similar to the `bus_send()` method.
[1]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/im_livechat/models/discuss_channel.py#L740
[2]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/im_livechat/models/discuss_channel.py#L760-L770
[3]: https://github.com/odoo/odoo/blob/2b486f35235974584b3434c2ca93297db802ae81/addons/mail/tools/discuss.py#L228-L230
sentry-7477572896
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA previous error prevented users from selecting a website theme after setting their company logo. This fix resolves the issue by correctly handling the logo data, ensuring a smooth website configuration process. The change was necessary due to a recent update in how logos are processed.
Original PR description
Currently an error is generated when the user tries to choose theme during configure the website after set the logo of the company. Steps to produce an error - Initilalize DB and set Logo (e.g. [1])…
Currently an error is generated when the user tries to choose theme during configure the website after set the logo of the company. Steps to produce an error - Initilalize DB and set Logo (e.g. [1]) - Install a website and build a website with click `Let's do it` and all input your choice - The error occurs when finally choosing the theme Error:`UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte'` This issue occurs because assigning the existing company logo using `company.logo` returns a `LocalBinaryFile` object instead of raw bytes after the recent refactor changes with [2]. Attempting to decode this `LocalBinaryFile` object causes the error. This commit fix the above issue by using `BinaryBytes(company.logo.content)`, which returns the expected raw bytes required to set the website logo from the company logo. [1]: https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png [2]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1 Sentry- 7475955377
This update fixes an issue where event tickets with 'Fixed Price' rules were incorrectly showing a struck-through original price, making them appear as discounts. The change ensures that fixed prices are displayed accurately, aligning with how discounts are shown in the eCommerce shop. This improves the user experience and prevents confusion regarding pricing.
Original PR description
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.…
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior. ### Steps to reproduce 1. Create an event with a paid ticket (e.g., 100 EUR). 2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR). 3. Open the event registration page. 4. The 100 EUR appears struck-through next to 80 EUR. ### Cause Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts. ### Fix Rationale A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount. opw-5993477 Forward-Port-Of: odoo/odoo#264470 Forward-Port-Of: odoo/odoo#263586
This update resolves an issue where surveys would freeze after a network loss during submission. The fix ensures the submission lock is released, allowing users to retry submitting their answers after reconnecting. This improves the survey experience and prevents data loss.
Original PR description
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even…
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers. Steps to reproduce: 1. Start a survey that includes a time limit. 2. Disconnect your device from the internet just before the timer runs out. 3. Wait for the timer to reach zero, triggering the auto-submit. 4. Reconnect to the internet and attempt to click "Submit" manually. 5. The action is ignored and the form remains stuck. Cause: To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen. Solution: Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure. Task-5787410 Forward-Port-Of: odoo/odoo#249514
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income'. The change ensures that depreciation entries (expenses) are now correctly classified in the 'Other Operating Expenses' section, improving report accuracy.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update ensures that completion and refusal emails sent to signers now use the correct email address calculated during the sign request process. Previously, emails were sent using the signer's partner email, which could lead to misdirected notifications. This change improves communication accuracy and ensures signers receive important updates.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update streamlines the reconciliation process in Odoo by eliminating unnecessary checks when no changes are needed. Previously, the system performed redundant queries even when no reconciliation actions were required, leading to slower performance. This change improves the overall responsiveness of the accounting module.
Original PR description
Since `write` is often done record by record because the values written are different on all lines, the call to `action_undo_reconciliation` is actually not batched. Even if there is nothing to do, some queries are still done to make sure that there is nothing to do... Forward-Port-Of: odoo/odoo#264476
21 changes
Resolved issues and error corrections
This update fixes an issue where unreconciling a payment on a recurring invoice would automatically generate a new draft invoice for the following month. The change adds a context flag to prevent this behavior, ensuring invoices are created correctly after reconciliation. This improves invoice management and reduces potential errors.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/enterprise#117011
This update fixes a problem with the test payrun date in the Odoo Enterprise system. Previously, the test relied on the current year, which wasn't reliable for verifying salary calculations. This change ensures accurate and consistent payrun date testing, improving payroll accuracy.
Original PR description
This commit fixes year for the test payrun as relying on today's year is not reliable to verify salary computations. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/237683 Forward-Port-Of: odoo/enterprise#117204
This update resolves an issue where surveys would freeze after a network interruption during submission. The fix ensures the submission lock is released, allowing users to retry submitting their answers after reconnecting. This improves the survey experience and prevents data loss.
Original PR description
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even…
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers. Steps to reproduce: 1. Start a survey that includes a time limit. 2. Disconnect your device from the internet just before the timer runs out. 3. Wait for the timer to reach zero, triggering the auto-submit. 4. Reconnect to the internet and attempt to click "Submit" manually. 5. The action is ignored and the form remains stuck. Cause: To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen. Solution: Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure. Task-5787410 Forward-Port-Of: odoo/odoo#249514
This update corrects a visual misalignment on invoices when section prices are hidden and the country of origin is displayed. The fix ensures that tax and amount information within section lines are correctly aligned in the invoice PDF, regardless of price visibility. This improves invoice presentation and accuracy.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/odoo#264118 Forward-Port-Of: odoo/odoo#263499
This update corrects a visual issue on invoices where section line content wasn't properly aligned when prices were hidden and the country of origin was displayed. The fix ensures that tax and amount information within hidden section lines are correctly formatted, improving invoice presentation. This resolves a misalignment problem impacting how invoices are printed.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/enterprise#117092 Forward-Port-Of: odoo/enterprise#115442
This update resolves an issue where service templates imported with 'tracking=none' incorrectly showed a 'Quantity on Hand' value. The fix ensures that service templates without tracking are not marked as storable, leading to more accurate stock reporting. This improves data consistency and reliability.
Original PR description
_set_tracking does write(is_storable=bool(tracking)) without looking at type. A service template imported manually with tracking='none' thus flips to is_storable=True. Restrict the inverse to consu templates. Steps to reproduce: - Import a CSV with type=service,tracking=none - You will visually see the Quantity on Hand field on the form view opw-6203593
This update allows all Point of Sale users to record cash inflows and outflows, regardless of their invoicing access rights. Previously, this functionality was restricted, which created a bottleneck. This change simplifies the cash management process within Point of Sale and aligns with existing security protocols.
Original PR description
Cash In/Out was gating on `account.group_account_invoice` even though the backend operation (`account.bank.statement.line` creation) is no different from what session closing already does under sudo(). Lower `_has_cash_move_perm` to `point_of_sale.group_pos_manager`, add `sudo()` to the create call. opw-6192176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263580
This pull request updates the core spreadsheet component to the latest version (19.2.13). It includes fixes for a color picker issue and updates to Odoo dependencies, ensuring the spreadsheet functionality continues to operate smoothly and reliably. This is a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fece642d7c [REL] 19.2.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fece642d7c [REL] 19.2.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5117146ce2 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050) https://github.com/odoo/o-spreadsheet/commit/0f6ba0d72e [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/5282e3c377 [REL] 19.2.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/dfb655d7b9 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/5231677171 [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a recurring issue in the meeting tour test that caused it to fail intermittently. The change ensures a key action is completed before the next, preventing a timing conflict that previously led to unpredictable test results. This improves the reliability of our testing process.
Original PR description
The `test_04_meeting_view_tour` test sometimes fails. A race condition occurs between the initial mark as unread action, which may or may not be triggered depending on whether the thread composer has time to gain focus before the meeting view is opened, and the later mark as unread action triggered during the test. This commit ensures the initial mark as read action is completed before proceeding to the mark as unread steps, thus resolving the issue. runbot-239936 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 update fixes an issue where demo data didn't correctly populate the 'Device Installation and Maintenance' worksheet in Field Service products. By loading a demo data file, the system now ensures the appropriate worksheet is used, improving the accuracy of demo data setup.
Original PR description
Load product_product_demo.xml in the 'planning_field_service_sale_worksheet' module so that the `Device Installation and Maintenance` worksheet is correctly set in Field Service product when demo data is loaded, instead of using the default worksheet.
This update fixes a potential error in the HR holidays module that could occur when using the demo user. The fix ensures that the demo user always references the correct existing employee, preventing a database constraint violation. This improves stability and reliability of the holiday reporting feature.
Original PR description
Issue: The test was creating a new employee linked to the demo user, but if the demo user already had an employee, it would violate the (user_id, company_id) uniqueness constraint. Fix: Before creating a new employee, we check if the demo user already has one. If not, we create it, otherwise we use the existing one. task-6050719
This update fixes a visual issue in the Treehouse theme where the payment confirmation message was incorrectly displayed, appearing compressed. The fix ensures the message is properly aligned and visible, providing a consistent and professional user experience for customers using this theme. This resolves a specific problem impacting only the Treehouse theme.
Original PR description
Steps to reproduce: 1) Select the Treehouse theme from the website editor 2) Add a product to the cart and proceed to payment 3) Complete the payment and reach the confirmation page Issue: - The payment success alert message is not displayed properly and appears slightly below the alignment. - Also this particular issue is coming in this Treehouse theme only in rest of the themes the alert message is coming correctly. opw-5976602 Forward-Port-Of: odoo/odoo#257768
This update fixes an issue where Colorado state income tax calculations resulted in a positive value on payslips. This ensures accurate withholding of taxes, aligning with standard tax regulations. The fix was inspired by a previous change for Alabama state taxes and validated by payroll experts.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#116831
Forward-Port-Of: odoo/enterprise#112724This update resolves a problem where users couldn't link invoices to the chatter feature in Odoo. The fix prevents a security check from failing when copying attachments, ensuring users with appropriate permissions can successfully link documents. This improves the usability of the chatter feature for sales and accounting workflows.
Original PR description
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now…
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now go back to the SO, and try to link the INV document to the chatter. **Cause:** When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document. **Solution:** Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework. opw-5916364 Forward-Port-Of: odoo/enterprise#107723
A bug was preventing the 'Two-factor authentication Disabled' filter from working correctly in the user list. This update corrects a technical issue within Odoo's database search functionality, ensuring the filter accurately displays users without two-factor authentication. This ensures users can properly see and manage their two-factor authentication settings.
Original PR description
Issue: In the user view list, the "Two-factor authentication Disabled" filter doesn't work (return the same result than the "Two-factor authentication Enabled").
Explanation: The ORM normalises `=`/`!=` to `in`/`not in` with list values (commit odoo/odoo#191549 - 92301a5b300d). `_totp_enable_search` only handled the legacy scalar form: `value` is now always a list of boolean then always truthy then `[('totp_enabled', '=', False)]` returned users *with* a totp secret, the opposite of what was asked.
Fix it and add tests for it.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264412
Forward-Port-Of: odoo/odoo#264027This update resolves an issue where test emails sent through the Email Marketing app would leave a related attachment visible in the chatter of contact records. The fix ensures that test emails are properly cleaned up after sending, preventing these attachments from appearing in the Chatter. This improves the clarity and usability of the Email Marketing interface.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Upload a file in Settings > Attach a file - Click on the test button to send a test mail to any mail - Go to the first contact record - Related attachment appears in the chatter **Issue:** Before 18.2, messages created for testing were ignored by the Chatter as they were empty (and not unlinked). But if an attachment was provided, it was linked to the test message and not deleted afterwards (which means it shows up in the record chatter). **Fix:** Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to False to trigger the `unlink` logic and remove the related attachments at the same time. backport of: https://github.com/odoo/odoo/commit/526b3d73886558315f2435714b2ed82fec313e78 opw-6168632 Forward-Port-Of: odoo/odoo#262152
This update resolves a technical error that prevented users from paying multiple expense bills simultaneously. The issue stemmed from incorrect data being passed during payment creation, triggering a database error. This fix ensures that users can now correctly process payments for multiple expenses without encountering this problem.
Original PR description
**Steps to reproduce:** - Install Accounting and Expenses - Create an expense: * Category: [any] * Total: [any] * Employee: [create or select one without a bank account] * Paid by: Employee (to reimburse) - Submit - Post Journal Entries (in Purchases journal) - Create another expense, submit it and post its journal entries - Go to the bills list - Select both bills created from the expenses - Click on "Pay" and then on "Create Payments" **Issue:** A traceback is raised while creating a payment. **Cause:** In the values used to create the payment, "partner_bank_id" is an empty "res.partner.bank" recordset instead of False, which leads to a SQL error because the type of the value is invalid. opw-6206315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The change ensures that depreciation expenses are now correctly classified within 'Other Operating Expenses,' improving the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update resolves an issue where a warning message persisted after canceling a payslip in the HR payroll module. The change ensures that the warning disappears correctly, providing a smoother user experience. This improves the reliability and usability of the payroll system.
Original PR description
. Clear payslip warning after cancelling the payslip . Add corresponding tests task-6199148 Forward-Port-Of: odoo/enterprise#117289 Forward-Port-Of: odoo/enterprise#116859
This update streamlines the reconciliation process in Odoo by preventing unnecessary checks when no changes are needed. Previously, the system performed extra queries even when reconciliation wasn't required, leading to slower performance. This change improves the overall responsiveness of the accounting module.
Original PR description
Since `write` is often done record by record because the values written are different on all lines, the call to `action_undo_reconciliation` is actually not batched. Even if there is nothing to do, some queries are still done to make sure that there is nothing to do... Forward-Port-Of: odoo/odoo#264476
This change fixes an error that prevented users from being created correctly when Studio and Livechat were installed and configured. The issue stemmed from a timing problem during user setup, causing a required field to be missing. The fix ensures the 'Color Scheme' field is always populated with a default value, allowing successful user creation.
Original PR description
Steps to reproduce: 1. Install Studio and Livechat 2. In user's form view change the location of Theme field after the livechat fields. 3. Now, try to create a user from name and email only Issue: - It throws an error: The operation cannot be completed: Missing required value for the field 'Color Scheme' (color_scheme). Cause: - During user creation after studio modification, im_livechat inverse methods access res.users.settings before it is fully initialized. then later write a falsy `color_scheme` value to that settings record, violating the required constraint on res.users.settings.color_scheme. Solution: - Ensure that when creating or updating `res.users.settings`, if `color_scheme` is empty or false, It is automatically set to the default value "system" opw-5918538 Forward-Port-Of: odoo/enterprise#109062
18 changes
Resolved issues and error corrections
This update fixes a translation error in the Argentine localization (l10n_ar) module, ensuring fiscal position names accurately reflect their purpose. Previously, a confusing duplicate translation was used, now all domestic fiscal positions are correctly labeled, avoiding confusion and improving data accuracy.
Original PR description
### Description of the issue/feature this PR addresses: Fix fiscal position spanish translation to match with its real purpose. ### Current behavior before PR: * We have a fiscal position name that does not match with its purpose: Represent the local operations inside argentina (country: Argentina) but the name is " Purchases / Sales abroad" * Two fiscal positions have the same translation value and this is confusing ### Desired behavior after PR is merged: * we do not have duplicated fiscal position anymore * Domestic fiscal position is taged with the correct name --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248462
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The fix ensures that depreciation entries (expenses) are now correctly classified in the 'Other Operating Expenses' section, improving report accuracy.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update fixes an issue where unreconciling payments from recurring invoices would incorrectly generate a new draft invoice for the next month. The change adds a context flag to prevent this behavior, ensuring invoices are created accurately and avoiding unnecessary invoice generation. This improves invoice management efficiency.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice > Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice > Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/enterprise#117011
This update corrects a misleading warning message that appeared when a payslip was cancelled in the HR payroll module. The change ensures users receive accurate information and a smoother cancellation process. This improves the overall user experience and data integrity.
Original PR description
. Clear payslip warning after cancelling the payslip . Add corresponding tests task-6199148 Forward-Port-Of: odoo/enterprise#116859
This update resolves an issue where surveys would freeze after a network loss during submission. The fix ensures the submission lock is released, allowing users to retry submitting their answers after reconnecting. This improves the survey experience and prevents data loss.
Original PR description
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even…
Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers. Steps to reproduce: 1. Start a survey that includes a time limit. 2. Disconnect your device from the internet just before the timer runs out. 3. Wait for the timer to reach zero, triggering the auto-submit. 4. Reconnect to the internet and attempt to click "Submit" manually. 5. The action is ignored and the form remains stuck. Cause: To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen. Solution: Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure. Task-5787410 Forward-Port-Of: odoo/odoo#249514
This update resolves a test failure caused by a timing issue in the Live Chat sidebar. The fix ensures the system fully processes data before the timer is checked, making the test reliable. This improves the overall stability of the Live Chat feature.
Original PR description
Since this [PR](https://github.com/odoo/odoo/pull/252738), The test `show looking for help duration in the sidebar` was failing due to a race condition. With the following error: ``` expected at…
Since this [PR](https://github.com/odoo/odoo/pull/252738), The test `show looking for help duration in the sidebar` was failing due to a race condition. With the following error: ``` expected at least 1 element after 200ms and found 0 elements: 5 matching :text(Visitor #1) (1 element containing selector :text(Visitor #1) > 0 text elements) ``` The test was going through the join flow, which triggers `discuss.channel/joined` and then `fetchChannel()`. Since `fetchStoreData()` is debounced, the resulting `/mail/data` fetch could race with the later `/im_livechat/session/update_status` call and the corresponding bus/store updates. Because the test was asserting the timer while those async updates were still settling, it could sometimes observe an intermediate client state and fail. This commit fixes the race condition to wait for the `/mail/data` RPC to fully complete, before clicking the `Looking for help` button. This ensures the store is fully settled before the LFH timer assertion, making the test deterministic. runbot-[242278](https://runbot.odoo.com/odoo/error/242278) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical bug that could cause sorting issues within the Discuss channels feature. The fix ensures a consistent and reliable comparison of channel data, preventing potential infinite loops and improving overall stability. This change focuses on the core sorting logic.
Original PR description
In order to work properly, a comparison function must be anti-symmetric, that is, if `compareFn(a, b)` gives `-1`, then `compareFn(b, a)` should give `1`. In the case of `sortChannels`, whenever `c1.displayName` is undefined, it falls back to comparing ids, but no such behavior is implemented when `c2.displayName` is missing, breaking the antisymmetry property. This flaw in the comparison function can potentially lead to infinite loops. This commit solves the issue, explicitly handling both `c1.displayName` and `c2.displayName`, in an antisymmetric fashion.
This update ensures the "Save Order" button is consistently displayed for users. This allows them to seamlessly save their order progress and resume it later, regardless of which device they're using within the same session. This improves the user experience and workflow for point-of-sale transactions.
Original PR description
The "Save Order" button is now always available, allowing users to easily save and resume their orders on different devices within the same session. task-id: 5966678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250405
A bug was preventing the 'Two-factor authentication Disabled' filter from working correctly in user lists. This update corrects a technical issue within the Odoo system's database filtering logic, ensuring the filter accurately displays users without two-factor authentication. The fix includes new tests to verify the functionality.
Original PR description
Issue: In the user view list, the "Two-factor authentication Disabled" filter doesn't work (return the same result than the "Two-factor authentication Enabled").
Explanation: The ORM normalises `=`/`!=` to `in`/`not in` with list values (commit odoo/odoo#191549 - 92301a5b300d). `_totp_enable_search` only handled the legacy scalar form: `value` is now always a list of boolean then always truthy then `[('totp_enabled', '=', False)]` returned users *with* a totp secret, the opposite of what was asked.
Fix it and add tests for it.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264027This update allows all Point of Sale users to record cash inflows and outflows, regardless of their invoicing access rights. Previously, this functionality was restricted, which created a bottleneck. This change simplifies the cash management process within Point of Sale and ensures consistent operation.
Original PR description
Cash In/Out was gating on `account.group_account_invoice` even though the backend operation (`account.bank.statement.line` creation) is no different from what session closing already does under sudo(). Lower `_has_cash_move_perm` to `point_of_sale.group_pos_manager`, add `sudo()` to the create call. opw-6192176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263580
This update fixes an issue where event tickets with fixed prices were incorrectly showing a struck-through original price, making them appear as discounts. The change ensures that fixed price rules are displayed accurately, aligning with how discounts are shown in the eCommerce shop. This improves the user experience and prevents confusion regarding pricing.
Original PR description
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.…
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior. ### Steps to reproduce 1. Create an event with a paid ticket (e.g., 100 EUR). 2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR). 3. Open the event registration page. 4. The 100 EUR appears struck-through next to 80 EUR. ### Cause Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts. ### Fix Rationale A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount. opw-5993477 Forward-Port-Of: odoo/odoo#264240 Forward-Port-Of: odoo/odoo#263586
This update fixes an issue where the sale average price calculation was inaccurate due to handling tax inclusion/exclusion. Now, the sale average price uses the net price (price_subtotal) from the invoice line, ensuring accurate calculations regardless of whether taxes are included or excluded. This improves the reliability of sales reporting.
Original PR description
The price_unit of a account.move.line can be with or without tax. The sale_avg_price should be either incl. or excl. tax. To ensure the avg price is always excl. tax the price_subtotal can be used. Forward-Port-Of: odoo/odoo#263671 Forward-Port-Of: odoo/odoo#199209
This pull request updates the core spreadsheet component used in Odoo. It includes several bug fixes and improvements to the underlying infrastructure, ensuring a more stable and reliable spreadsheet experience for users. The changes also optimize the component's performance and dependency management.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b6a68b89c1 [REL] 19.1.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b6a68b89c1 [REL] 19.1.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9087d404c4 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050) https://github.com/odoo/o-spreadsheet/commit/6255eb07a6 [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/aea4a8c55f [REL] 19.1.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/addcd227d8 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/5e333513e4 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/dedcb6a12c [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e267f5db92 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1d4311e3d2 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/dfff07841c [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2e87404919 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent test for live chat duration was unreliable due to a race condition in how the system handles agent state transitions. This fix addresses this issue by splitting the test to avoid the problematic rapid state changes, ensuring the test is consistently reliable. This improves the overall stability of the live chat feature.
Original PR description
The `show looking for help duration in the sidebar` test has been flaky since [1]. The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately…
The `show looking for help duration in the sidebar` test has been flaky since [1]. The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`. This creates several race conditions: - Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data. - Channel state fetched after the user joins via `/mail/data`. The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed. This commit splits the test to preserve coverage while avoiding the problematic rapid state transition. runbot-242278 [1]: https://github.com/odoo/odoo/pull/252738 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 update fixes an issue where the payment confirmation message appeared incorrectly in the Treehouse theme. The message was compressed and misaligned, impacting the user experience. This change ensures consistent and proper display of the confirmation message across all themes, improving the checkout process.
Original PR description
Steps to reproduce: 1) Select the Treehouse theme from the website editor 2) Add a product to the cart and proceed to payment 3) Complete the payment and reach the confirmation page Issue: - The payment success alert message is not displayed properly and appears slightly below the alignment. - Also this particular issue is coming in this Treehouse theme only in rest of the themes the alert message is coming correctly. opw-5976602 Forward-Port-Of: odoo/odoo#257768
This update fixes issues where list markers weren't consistently applying text and font sizes, particularly when list items had trailing empty lines or complex formatting. The changes ensure that font sizes and colors are correctly applied to list items regardless of their content or formatting, improving the overall user experience.
Original PR description
### Steps to reproduce: **Issue 1:** - Create a list with multiple items and leave the last item empty. - Press Ctrl + A to select all content. - Apply a text color from the toolbar. - The list…
### Steps to reproduce: **Issue 1:** - Create a list with multiple items and leave the last item empty. - Press Ctrl + A to select all content. - Apply a text color from the toolbar. - The list marker of the last item does not receive the color. **Issue 2:** - Create a list and type some text. - Press Ctrl+A to select all. - Apply a font size via the font-size input (inline style=`font-size: ...`). - Then apply a font size via the font-size dropdown (class-based). - Font size from the dropdown is not applied. **Issue 3:** - Create a list item and type some text. - Convert the text into a link. - Copy the link. - Press Enter and paste the link. - Select the entire list using the mouse. - Apply font size & observe that font size is not applied to some list items. **Issue 4:** - Go to Todo and create a list. - Select all items (Ctrl + A). - Apply a background color class from the toolbar. - Apply a font color using inline styling. - Observe that the font color is not visible. ### Description of the issue/feature this PR addresses: - Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled. - Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect. - Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied. - Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden. ### Desired behavior after PR is merged: - List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder. - Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly. - Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application. - When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li. task - 5454639 Forward-Port-Of: odoo/odoo#264381 Forward-Port-Of: odoo/odoo#241827
This update resolves a problem where users couldn't link invoices to the chatter feature in Odoo Enterprise. The fix prevents an access error that occurred when copying attachments, ensuring users with appropriate permissions can now successfully link documents to the composer.
Original PR description
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now…
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now go back to the SO, and try to link the INV document to the chatter. **Cause:** When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document. **Solution:** Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework. opw-5916364 Forward-Port-Of: odoo/enterprise#107723
This update streamlines the reconciliation process in the accounting module by preventing unnecessary checks. Previously, the system performed redundant queries even when no reconciliation actions were needed. This change improves performance and reduces the time it takes for reconciliation operations to complete.
Original PR description
Since `write` is often done record by record because the values written are different on all lines, the call to `action_undo_reconciliation` is actually not batched. Even if there is nothing to do, some queries are still done to make sure that there is nothing to do... Forward-Port-Of: odoo/odoo#264476
2 changes
Resolved issues and error corrections
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to differing currency settings. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This improves financial reporting accuracy.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#116426 Forward-Port-Of: odoo/enterprise#114590
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The change ensures that depreciation entries (expenses) are now correctly classified in the 'Other Operating Expenses' section, improving report accuracy.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
5 changes
Resolved issues and error corrections
This update corrects an issue where pressing Enter after a styled heading created a new paragraph with the same styling. The fix now ensures that newly created paragraphs are empty and without inherited styles, aligning with the expected behavior. This improves the consistency and predictability of the HTML editor.
Original PR description
Problem: Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles. This is no longer the expected behavior. The new paragraph should be empty and without inherited styles. Solution: When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles. Steps to reproduce: - Add a heading. - Apply a style (e.g., color). - Place the caret at the end of the heading. - Press Enter. - Observe that the new paragraph still has the heading color. task-6147897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262150
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income'. The fix ensures that depreciation entries (expenses) are now correctly classified in the 'Other Operating Expenses' section, improving the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update resolves an issue where automatic updates to IoT Boxes were failing due to a random error. The system now intelligently skips the update process if the previous branch is 'master', ensuring smoother and more reliable updates. This prevents disruptions to Odoo's operation on IoT devices.
Original PR description
If `git ls-remote origin <db_branch>` randomly fails, we assume `db_branch` is `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`. Forward-Port-Of: odoo/odoo#264215 Forward-Port-Of: odoo/odoo#264126
This update resolves an issue where the Microsoft SwiftKey keyboard caused incorrect table cell selections, leading to unexpected focus movement. The fix caches the selection to ensure accurate tracking of the user's intended selection, improving the editor's stability and usability.
Original PR description
Problem: When using the Microsoft SwiftKey keyboard, placing the caret at the beginning of a table cell and triggering a `beforeinput` event can result in `getSelection()` returning an incorrect selection. Notably, the selection immediately before the event is correct, but it changes unexpectedly without firing a `selection_change` event. Solution: Cache the selection whenever a `selection_change` event fires, ensuring we keep the last correct selection set by the user or editor. Steps to reproduce: - Edit a table with an empty cell. - Place the caret inside the empty cell. - Press Backspace. - Observe that the focus moves to the previous cell unexpectedly. task-6150731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264479 Forward-Port-Of: odoo/odoo#259798
This pull request updates the core spreadsheet component within Odoo. It includes several bug fixes and improvements to the underlying infrastructure, ensuring the spreadsheet functionality remains stable and reliable. These changes address issues with color selection, package installation, and workflow processes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/70e2c8e1f7 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050) https://github.com/odoo/o-spreadsheet/commit/e2d2b3493f [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/8b8bc44b6a [REL] 18.3.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1a3ac11b2f [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/c970c1de54 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d2fa06ba7f [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
2 changes
Resolved issues and error corrections
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The change ensures that depreciation entries (expenses) are now correctly classified within 'Other Operating Expenses,' providing accurate financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update fixes a bug where previously validated manual transactions could incorrectly be matched with new transactions. The change ensures that manual counterpart lines are no longer suggested for matching with subsequent transactions, improving the accuracy of bank reconciliation. This resolves a potential issue with financial reporting.
Original PR description
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Adding test for community branch opw-6045050 Forward-Port-Of: odoo/enterprise#115847
11 changes
Resolved issues and error corrections
This update resolves an error that occurred when users removed the 'Source Entity Id Type' setting in Super Contributions. The fix ensures the system correctly handles this removal, preventing a calculation error and maintaining data integrity. This improves the reliability of the Australian Super Contributions reporting.
Original PR description
Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions. **Steps to Reproduce:** - Install `l10n_au_hr_payroll_account` with demo data. - Switch to an…
Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions. **Steps to Reproduce:** - Install `l10n_au_hr_payroll_account` with demo data. - Switch to an `Australian` company. - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`. - Open an existing record or create a new one. - Remove the `Source Entity Id Type` value and click anywhere. `ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id` After [change] in the selection field behavior, when the user removes the Source Entity Id Type, the compute method is triggered to compute the Source Entity ID. However, the condition in the compute method is not match, so no value is assigned. As a result, the method fails and raises an error. This commit ensures that if the condition is not match, the Source Entity ID is explicitly set to False. [1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65 [change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef Forward-Port-Of: odoo/enterprise#115466
This update corrects a technical error that prevented the proper registration of end-of-service payments on payslips. The fix ensures that the departure registration action can now be executed on the same day as the action_date is set, resolving a test failure. This improves payroll processing accuracy.
Original PR description
Setting action_date allows to execute departure.action_register on the same day. runbot error: https://runbot.odoo.com/odoo/runbot.build.error/242533 task: 6187007 Forward-Port-Of: odoo/enterprise#116531
This update fixes an issue where PDF manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF manager. This improves the user experience and overall presentation.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#117157 Forward-Port-Of: odoo/enterprise#116382
This update fixes an issue in the payroll testing environment by setting a fixed year for payrun dates. Relying on the current year for verification was unreliable, impacting the accuracy of salary calculations. This ensures consistent and dependable testing of the payroll system.
Original PR description
This commit fixes year for the test payrun as relying on today's year is not reliable to verify salary computations. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/237683 Forward-Port-Of: odoo/enterprise#117204
This update resolves a problem where uploaded payment proofs were being corrupted and not properly attached to employee records. The fix ensures that payment proof files are now correctly attached to chatter notifications, maintaining their original file format. This improves the reliability of recording payment information.
Original PR description
### Current behavior: Uploading a proof of payment on an employee rental record raises `binascii.Error: Incorrect padding`, and posts a corrupted attachment to the chatter. Expected behavior: The uploaded payment proof file is attached to the chatter notification with its original bytes intact. ### Steps to reproduce: - Install l10n_hk_hr_payroll - Open an HK employee's rental record - Upload a file in the Payment Proof field - Observe the RPC error, or check the attachment in the chatter ### Fix: `fields.Binary` now returns a `BinaryValue` (raw bytes wrapper) instead of a base64-encoded string. `_log_new_payment_proof` was still running `base64.b64decode` on the field value, which mangled the contents. Pass the raw bytes via `.content` directly to `message_post`, which already expects non-base64 payloads. opw-6211986 Forward-Port-Of: odoo/enterprise#117191
This update corrects a misalignment issue in invoices when section prices are hidden and the country of origin is displayed. The fix ensures that tax and amount information within section lines are correctly aligned in the invoice PDF, regardless of price visibility. This improves invoice presentation and accuracy.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/enterprise#117092 Forward-Port-Of: odoo/enterprise#115442
This update resolves an issue where the chart type picker wasn't correctly displaying options for gauge and scorecard charts. The fix ensures that these chart types are properly recognized and selectable, enhancing the user experience when creating and modifying charts. This improves usability for users working with these specific chart types.
Original PR description
See https://github.com/odoo/odoo/pull/264650
This update fixes a display issue where the number of ECOs listed on a Bill of Materials (BoM) was incorrect. The fix ensures that only ECOs directly associated with the current BoM version are counted, resolving a mismatch between the displayed count and the actual number of ECOs. This improves the accuracy of BoM management.
Original PR description
Steps to Reproduce (Fresh Database): -------------------------------------- 1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules 2. Create a product > New -- Name: "Test Product" > Save 3.…
Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
- Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
- Add component: any
4. Create and apply ECO 1 on BoM v1
- Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
- BoM: Test Product (v1) > Confirm > Apply Changes
- This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
- Same as step 4 but select BoM v2
- This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
- Go to Manufacturing > Bills of Materials > New
- Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
- Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
- BoM: select the separate BoM from step 6 > Confirm
Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)
Explain:-
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.
Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.
Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />
```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
('bom_id',
'in',
[710,
1991,
2049,
1913,
1840,
1823,
1676,
1759,
1794,
1651,
1604,
1544,
1537,
1527,
1506,
1460,
1265,
1259,
1196,
1221,
1223,
1060,
1029,
960,
858,
850,
791,
739,
723,
698]),
('type', '=', 'bom')]
```
With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />
```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
1991: set(),
2049: set(),
1913: set(),
1840: set(),
1823: set(),
1676: set(),
1759: set(),
1794: set(),
1651: set(),
1604: set(),
1544: set(),
1537: set(),
1527: set(),
1506: set(),
1460: set(),
1265: set(),
1259: set(),
1196: set(),
1221: set(),
1223: set(),
1060: set(),
1029: set(),
960: set(),
858: set(),
850: set(),
791: set(),
739: set(),
723: set(),
698: {710}}
In [18]: relevant_bom_ids = [
...: bom_id
...: for bom_id, current_bom_set in previous_boms_mapping.items()
...: if labo.id in current_bom_set
...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```
Task-6065020
Forward-Port-Of: odoo/enterprise#117149
Forward-Port-Of: odoo/enterprise#114039This update corrects a display issue in the Payrun Time Off Gantt view, where employee names were showing inconsistently compared to other time off applications. The change hides employee names from this specific view, ensuring a more uniform and professional appearance across all time off reporting. This improves the user experience and data clarity.
Original PR description
In payrun time off step, we get the full name of the employee in the Gantt view. But it is inconsistent with the rest of the time off application. Hide employee names from the Gantt view of Payrun Time Off. task-6190437 Forward-Port-Of: odoo/enterprise#116365
This update addresses a potential issue where incorrect domain warnings could occur when using equality comparisons (=) within Odoo's collection-based filtering. The changes enhance the reliability of domain filtering, preventing unexpected behavior and ensuring data accuracy across several Odoo modules. This improves the overall stability and performance of the system.
Original PR description
https://github.com/odoo/odoo/pull/264706
This update optimizes PDF generation by compressing files after merging, resulting in significantly smaller output sizes. It also addresses a memory leak in the PDF processing, leading to more efficient resource usage. The changes improve PDF generation speed and reduce storage needs.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117404 Forward-Port-Of: odoo/enterprise#115550
4 changes
Resolved issues and error corrections
This update resolves an issue where overtime calculations weren't correctly accounting for lunch breaks. The fix adjusts the overtime check to consider lunch hours, ensuring more accurate overtime tracking. This change was prompted by a related update in the Odoo community repository.
Original PR description
**Version:** - 19.0 **Issue:** - test_14_overtime_rule_per_day_period test case was failing due to the changes in the community PR. **Fix:** - Updated the overtime check_work_entries to take lunch hours in consideration. **Community PR:** - https://github.com/odoo/odoo/pull/257079 **Task-6064081**
This update corrects a technical error that occurred when loading paid orders. The previous process incorrectly referenced an account move, which was already being handled by another part of the system. This change ensures paid orders load correctly and efficiently.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467
This update fixes a reporting issue in the Peruvian Profit & Loss report. Previously, depreciation entries were incorrectly categorized as 'Other Income'. The change ensures that depreciation entries (expenses) are now correctly classified within the 'Other Operating Expenses' section, providing accurate financial reporting for Peruvian businesses.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a necessary data state within the test file, ensuring the tests now run successfully. This prevents disruptions to the Italian reporting functionality.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#117001 Forward-Port-Of: odoo/enterprise#112794
5 changes
Resolved issues and error corrections
This update fixes an issue where refused overtime was incorrectly included in work entry calculations. Previously, the system was adding validated overtime hours, leading to inaccurate work time records. Now, refused overtime is properly excluded, ensuring accurate attendance-based work entries are generated.
Original PR description
- While fixing the bug where refused overtime in `no_validation` mode was still retaining validated overtime hours, this exposed an issue in attendance-based work entry generation. Refused overtime was being excluded using `validated_overtime_hours`. - After the previous fix, `validated_overtime_hours` becomes `0` on refusal, causing the full attendance duration to be included in generated work entries. **Example**: ``` Attendance: 13:00–20:00 Overtime: 2h Overtime status: refused Validated overtime: 0h ``` **Before**: `Generated work entry = 7h` **Expected**: `Generated work entry = 5h` ### Fix - For refused overtime, subtract `overtime_hours` from the attendance interval instead of `validated_overtime_hours`, ensuring refused overtime remains excluded from attendance-based work entries. task-5949741
This update corrects a bug where old manual bank statement entries were incorrectly suggested as matches for new transactions. The change ensures that only relevant, current manual operations are considered during automated reconciliation, improving the accuracy of bank statement matching. This prevents potential errors in financial reporting.
Original PR description
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create…
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Analysis: During the retrieval of possible aml to match we only look at the aml reconciliation state. Manual counterpart lines created during the validation of a previous statement line are still selectable candidates, causing false positive matches in automated reconciliation models. Test in Enterprise: https://github.com/odoo/enterprise/pull/115847 opw-6045050 Forward-Port-Of: odoo/odoo#262295
This update corrects a bug where previously validated manual transactions could incorrectly be matched with new transactions. The change ensures that manual counterpart lines are no longer suggested for matching with subsequent transactions, improving the accuracy of reconciliation reports. This resolves a potential issue with financial reporting.
Original PR description
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Adding test for community branch opw-6045050 Forward-Port-Of: odoo/enterprise#115847
This update resolves an issue where a notification badge remained visible on the 'Send to Kitchen' button after a general note was removed from the Point of Sale (POS) system. The fix normalizes empty notes to an empty string, ensuring the badge disappears correctly when a note is deleted. This improves the user experience by removing unnecessary notifications.
Original PR description
Steps to reproduce:
-----------
- Open POS Restaurant
- Add a General Note
- Remove the General Note
- The message badge on “Send to Kitchen” remains visible
Issue:
-----------
Removing a General Note set `general_note` to `undefined`, which was
detected as a change and kept the badge visible.
Fix:
--------------
Normalize empty General Notes to an empty string ("") so removing a note
restores the correct initial state.
Task-6101501
Related PR: odoo/enterprise#113514This update corrects a technical issue where archived delivery carriers were being unintentionally included in the carrier selection process. Previously, the system would pass information about inactive carriers, leading to incorrect carrier choices. This change ensures that only active carriers are used, improving data accuracy and reliability.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263819
2 changes
Resolved issues and error corrections
This update resolves an issue where the SD Worx report would fail when generating data for employees without working schedules. The fix ensures the report gracefully handles cases where an employee isn't found, preventing errors and ensuring accurate report generation. This improves the reliability of payroll reporting.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll_sd_worx module - Create a public holiday in one company without a working schedule - Create an employee that doesn't have a working schedule nor a contract - Try to generate the sd worx report - A traceback will pop-up ## Cause: Since we fetch all employees if we have a public holiday with no schedule, this puts us in a scenario where we try to access a key in that doesn't exist and it will trigger a KeyError ## Fix: Make sure we fallback on an empty recordset in case we don't have the employee in the key list of the dict we are checking opw-5500070
This update clarifies how Helpdesk articles are searched, particularly when a non-root article is selected as the main article. The team has addressed an issue where searching didn't include descendant articles and a related problem with dropdown behavior. The solution focuses on improving user guidance rather than a technical fix.
Original PR description
*: website_helpdesk_knowledge Steps to reproduce: --- - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
Steps to reproduce:
---
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
- First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
- Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
Issue:
---
The domain used to find the articles to match the search uses the current id
as the `root_article_id``:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],`
which was previously working in every case as it was not possible to set
a non-root article in the team setting.
This was later changed to allow any article as the default website page.
As a result, when a non-root article is selected, the search domain only
applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"`
which is not properly reset when the dropdown is removed, and triggers the creation
of an empty dropdown.
Fix:
---
Doesn't seem easy to fix to allow the search on all the descendants of
the given article as we can't use the article `root_article_id` and filter out
the unwanted results in a clean way (and it doesn't seem doable with a direct domain).
Instead clarify the situation in the help of the article.
Also manually reset the attribute when there is no results.
Backport of https://github.com/odoo/enterprise/pull/107438
task - 5360265