Daily updates from Odoo
Friday, May 15, 2026
44 changes · saas-19.3
Enhancements to existing features
This update automatically sends email reminders to users 7 days before an account return deadline. This improves the process of submitting returns by proactively notifying users and reducing the risk of missed deadlines. It's a small improvement to our reporting system.
Original PR description
Send reminder mail to submit an account return 7 days before the deadline. task-4752152 Forward-Port-Of: odoo/enterprise#112576
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 fixes an issue where early payment discounts with cash rounding were incorrectly calculating tax amounts in payment journal entries. The change ensures that tax amounts are accurately added when using the 'Modify tax amount' cash rounding strategy, leading to more precise financial reporting. This improves the reliability of payment processing.
Original PR description
Issue: When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal…
Issue: When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal entry will be far off from the correct amount Steps to reproduce: 1. Create a sales tax for 8.1% 2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method 3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date 4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier 5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied Cause: tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount Solution: In tax_amounts, add to the accumulating value if a tax repartition line id already exists as a key otherwise, insert it into tax_amounts opw-5998497 Forward-Port-Of: odoo/odoo#259025
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 resolves an issue that prevented consolidated POS invoices from being created correctly when multiple orders were included for the same customer. The fix ensures that all refund reason values are safely collected and validated, preventing errors and maintaining consistency with existing processes. This improves the reliability of invoice generation for multi-order POS transactions.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update resolves an issue where users with the Payroll Assistant role were encountering errors when opening the Payroll app. The change prevents these access errors, ensuring all users can access this critical functionality. This improves the reliability and usability of the Payroll module.
Original PR description
* = hr_work_entry_attendance This commit prevents access errors that are triggered when a user with Payroll Assistant role tries to open the Payroll app. TaskID-6143823
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 fixes an issue where Kanban progress bars for date/time grouped data were consistently grey, regardless of task status. The fix ensures that progress bars accurately reflect the distribution of tasks within grouped time ranges, resolving a visual inconsistency. This improves the clarity and usability of Kanban views.
Original PR description
Steps to reproduce 1. Open any kanban view declaring a <progressbar> (e.g. Project > Tasks, or Field Service > My Tasks). 2. Group by a date or datetime field with a granularity (e.g. Creation Date:…
Steps to reproduce 1. Open any kanban view declaring a <progressbar> (e.g. Project > Tasks, or Field Service > My Tasks). 2. Group by a date or datetime field with a granularity (e.g. Creation Date: Year, planned_date_begin:day). 3. Have records spread across several groups with different state values (done, in progress, canceled, ...). 4. Observe the colored progress bar at the top of each column. Issue Every column's progress bar renders as a uniform grey block regardless of the actual state distribution of its records. The effect is visible only when grouping by a date/datetime field; grouping by stage or assignees still works. The kanban relies on two separate RPCs whose keys must match: formatted_read_group (used by web_read_group) returns the columns the client stores, and the client uses each column's formatted groupby value as the lookup key; read_progress_bar returns a dict mapping that same key to per-state counts. For a datetime group by with a time granularity, formatted_read_group goes through _web_read_group_groupby_formatter, which localizes the naive timestamp in the user's timezone and then converts it to UTC before strftime, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/models/models.py#L698-L726. On the client, serializeDateTime also formats in UTC, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/core/l10n/dates.js#L455-L462, so group.serverValue is the UTC-shifted string the server sent, e.g. "2025-01-01 08:00:00" for a Pacific-tz user on a 2025-year group. read_progress_bar called _read_group directly, which returns the raw naive datetime out of date_trunc, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/odoo/orm/models.py#L1764, so its dict was keyed by str(datetime(2025, 1, 1, 0, 0)) = "2025-01-01 00:00:00". The UTC-formatted key the client looks up in _pbCounts[groupValue], see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L69, never matched, per-state counts stayed at zero, and the synthetic "Other" bucket with color "200" (grey) absorbed the whole group.count, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L88, hence the uniform grey bar. Non-date groupbys (many2one, selection, boolean) are unaffected because their keys are scalar ids / selection codes that round-trip identically on both sides. The "None" column also works because both sides emit the literal string "False". The regression was introduced by d5a6e97abab04282c7a69093cd790b539a958241 when read_progress_bar was switched from self.read_group(...), whose output was pre-formatted the same way the client received it, to self._read_group(...) Solution Route read_progress_bar through formatted_read_group, the same method web_read_group uses to build groups for the client. Both sides now run through _web_read_group_groupby_formatter, so the keys are produced by the same code path and match by construction for every field type, including date/datetime granularities. formatted_read_group wraps relational and date/datetime groupby values as (id, display_name) / (utc_str, label) tuples, so the adapt helper unwraps the first element to restore the scalar key shape the result dict expects. opw-6148736 Forward-Port-Of: odoo/odoo#261024
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 fixes an issue where the sale average price calculation was inaccurate due to inconsistent tax inclusion/exclusion settings on invoices. The change ensures the sale average price always uses the net amount (after discounts) from the invoice line, resulting in more accurate reporting and pricing. This improves the reliability of sales data.
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 update fixes an issue where employees with overlapping flexible shifts were incorrectly reporting double the hours worked in attendance reports. The fix ensures that the report accurately reflects the total planned time for shifts, regardless of overlap, improving the reliability of attendance data. This impacts employees using flexible scheduling.
Original PR description
__ ## Short functional explanation of the error When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours. ##…
__ ## Short functional explanation of the error When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours. ## Reproduction Steps 1. Create an employee with a flexible schedule and with Work Entry Source set at Planning. 2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it. 3. Click on the Reporting tab > Planning / Attendance Analysis. ### Expected behavior The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot. ### Unexpected behavior The total for this Month for this employee under the Planned Time field is equal to 16 hours. ## Origin of the issue This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated. __ opw-6146052 Forward-Port-Of: odoo/enterprise#117128 Forward-Port-Of: odoo/enterprise#115447
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
This update fixes an issue where packaging unit information disappeared from delivery slips after a transfer was validated. Now, the delivery slip accurately displays the packaging unit and quantity, regardless of whether the transfer is validated, ensuring accurate reporting for products tracked by lot and serial numbers. This improves inventory visibility and reporting accuracy.
Original PR description
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the…
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report. Steps to Reproduce: ========================= 1. Install stock and sale_management modules. 2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings. 3. Create a product with tracking by lot/serial number and configure a packaging unit. 4. Create a SO using this product with a packaging unit and confirm it. 5. Open the related transfer and print the delivery slip before and after validation. Cause of the Issue: ========================= The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure. With This Commit: ========================= This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing) opw-6142052 Forward-Port-Of: odoo/odoo#264235 Forward-Port-Of: odoo/odoo#262722
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 fixes a bug preventing users from selecting custom date ranges in accounting reports. The recent date filter refactor caused a discrepancy in how options were displayed, leading to missing comparison choices. This change ensures users can accurately filter reports by custom date ranges.
Original PR description
**Problem:** The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports. **Steps to reproduce:** 1. Go to Accounting > Reporting > Profit…
**Problem:** The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports. **Steps to reproduce:** 1. Go to Accounting > Reporting > Profit & Loss 2. Click the Comparison dropdown 3. Only "No Comparison", "Previous Period", and "Same Period Last Year" are visible — "Custom Dates" is missing **Current behavior:** Custom date comparison options are not rendered. **Expected behavior:** "Custom Dates" (for range reports) and "Specific Date" (for single date reports) should appear in the Comparison dropdown. **Cause of the issue:** The date filter refactor (40484f985f5) restructured how the date mode is stored in options. Previously, `options.date.mode` held 'range' or 'single'. After the refactor, this key no longer exists — the mode is now stored as a boolean in `options.filter_date.range_mode`. The comparison filter template still checks `controller.cachedFilterOptions.date.mode`, which is now undefined, so both the range and single conditions always evaluate to false and the custom comparison options are never rendered. **Fix:** The comparison template was the only consumer not updated during the refactor. Aligning it to the new data path restores the options without any behavioral change. opw-6070402 Forward-Port-Of: odoo/enterprise#113391
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 resolves a bug that prevented the Account Asset module from successfully updating, leading to database instability. The fix avoids unnecessary data loading and ensures updates proceed smoothly, maintaining database accessibility. This improves module reliability and prevents disruptions to business operations.
Original PR description
This commit fixes the account asset error when updating the module. The problem was the `account.depreciation.model.csv` was being loaded again and if there was a `running` asset, it causes an error that we can't update a depreciation model that has running asset. As a result gets the module stuck in the to upgrade state which means that on every request to the Odoo db it will attempt the module upgrade again, which will keep failing, rendering the database inaccessible. Bug introduced in https://github.com/odoo/enterprise/pull/110143. A new condition in the write is added to make sure that the module is not in `install_mode` to bypass the update condition. opw-6216476
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 now allows users to cancel Stripe payments directly from the payment terminal, both on the standard POS system and self-order kiosks. Previously, cancellations could only be processed through the POS interface, creating a frustrating experience for customers. This change improves customer satisfaction and streamlines the payment process.
Original PR description
Before this commit, when making a payment on a Stripe terminal, the only way to cancel the payment was from the POS interface. In the self order kiosk, it was impossible to cancel the payment. After this commit, a cancel button will appear on the payment terminal for both POS and kiosk Stripe payments. task-6166789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264665 Forward-Port-Of: odoo/odoo#264270
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 corrects a problem that was causing invoices with many items to fail SAT validation checks (CFDI40111 & CFDI40108). The issue stemmed from currency precision when applying discounts across multiple lines, leading to discounts being hidden. This ensures invoices comply with Mexican tax regulations and avoids potential payment issues.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117375 Forward-Port-Of: odoo/enterprise#117297
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
This update resolves an error that prevented users from being created correctly when Studio and Livechat were installed and the user form layout was modified. The fix ensures that the 'Color Scheme' field is always populated with a valid value, preventing the creation process from failing. This improves user onboarding and data integrity.
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
This update resolves a technical issue that could cause sorting processes to become stuck. The fix ensures that channel comparisons are consistently handled, regardless of whether a channel name is available, preventing potential infinite loops and improving overall system stability. This enhances the reliability of channel organization within the platform.
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. Forward-Port-Of: odoo/odoo#264398