Monday, January 12, 2026
51 changes · saas-19.1
Resolved issues and error corrections
A bug was causing the timer to malfunction when switching between views with sample timesheet data. This update ensures all sample records have their timers paused, preventing data conflicts and improving the reliability of the timesheet display. This resolves a technical issue impacting user experience.
Original PR description
Steps to reproduce: - Open Timesheets app, - Click on search(magnifying lens) to open on cell with no records. - Let sample record be loaded. Issue: - Timer is already started. If you switch back to grid view and stop the time it throws traceback as it has data of sample records. Reason: - The sample records can have record states that are running. Fix: - Make sure all the sample records created have their timer paused using field `is_timer_running`. - Update condition in time display to check if time is running instead using `is_timer_running` not using `time_start` and `time_pause` as `time_pause` is not an active field. task-5267303 Forward-Port-Of: odoo/enterprise#102035
This update strengthens the security of our Point of Sale (POS) system by ensuring that data is accessed securely. Previously, unauthorized access attempts could cause errors and crashes. Now, the system checks permissions before reading POS data, preventing disruptions and improving stability.
Original PR description
**: pos_hr Before this commit: --- - POS data was read directly from records without validating read access. - This could raise `AccessError` when the user lacked permissions, breaking POS data loading. After this commit: --- - Check read access on records before calling `read`. - Prevent POS crashes caused by unauthorized model reads. runbot-231708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226421
A recent issue preventing the completion of a key tour test for holiday allocation has been resolved. The problem stemmed from an empty leave type value causing form saving failures and timeouts. The fix ensures a valid leave type is always selected, guaranteeing the tour test runs successfully and accurately demonstrates the holiday allocation process.
Original PR description
Step to reproduce: - Install hr_holidays. - Run the time_off_allocation_warning_tour tour test. - The following error occurs: '(.o_form_readonly, .o_form_saved) has not been found. TIMEOUT: step failed to complete within 10000 ms'. Cause: - The leave type value is coming empty, causing the form to fail to save and resulting in a timeout. Fix: - Ensure holiday_status_id picks a valid leave type from selector. - Provide start dates and set the end dates to check the functionality. Task - 5264183 Forward-Port-Of: odoo/odoo#236639
This update resolves a technical issue within the HTML editor that could cause errors when content is completely removed after being inserted. The fix ensures the editor doesn't attempt to set a selection on a node that no longer exists in the DOM, improving stability and preventing unexpected errors. This primarily impacts the user experience when pasting and editing content.
Original PR description
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`,…
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`, and some specific `<br>` nodes. Ultimately, the selection is set after the last inserted node. In some cases, none of the inserted content remains after the clean up. When this happens, the selection is being set after the last inserted node, which is not part of the DOM anymore, and therefore leads to an error. This commit prevents this from happening by detecting when all inserted content was actually already removed. Steps to reproduce: - In a plain web page, copy a <br> into the clipboard - In an editor, put a character on a line - Paste => An error popup was displayed task-5429909 [FIX] html_editor: avoid failing when selection nodes are disconnected This commit addresses a traceback that was spotted but for which the actual scenario remains undetermined. The only possible way this traceback may occur is if nodes inside a selection are disconnected. The test added by this commit produces the same traceback as the observed one. task-5429909 Forward-Port-Of: odoo/odoo#242941 Forward-Port-Of: odoo/odoo#242488
This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that tax calculations are handled correctly when creating these expense reports, preventing inaccurate accounting entries. This improves the reliability of expense tracking for company-paid expenses.
Original PR description
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2. Confirm and generate the expense report. 3. Reset the expense’s journal entry to draft and add an analytic account on the first line. → An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited. ## Cause For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*. In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes. However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`. This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines. As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate. ## Solution Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`. **opw-5166707** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243052 Forward-Port-Of: odoo/odoo#233841
This update resolves an inconsistency in the SLSP reports by standardizing the order of data lines within the reports. Previously, test failures occurred due to varying data presentation. Adding a default order by clause to the SQL queries ensures a consistent and reliable report output.
Original PR description
A recent test was added that tests the lines of the SLSP reports. Up until now, all tests were either testing specific lines (not the report structure) or the export, which uses different queries. This new test is now failing inconsistently due to the order in which the data is being displayed. We add default orderby in SQL queries of the SLSP (using the models default orderby) in order to make the order consistent and avoid further issues.
This update fixes an issue where the barcode app on mobile devices displayed stock locations in a list view, which wasn't ideal for small screens. The change prioritizes a more user-friendly kanban view for mobile, ensuring product information is easily accessible on smaller devices.
Original PR description
Issue ===== On mobile, we should prioritize kanban views over list views because kanban views are usually more suitable for small device screen. That said, when a product's barcode is scanned in the Barcode app main menu, we show this product's stock locations but we do that with a list view, no matter if the user is on a big screen or a small screen. How to reproduce ================ On mobile device: - Enable location and have a product with a barcode and with quantities in two different locations; - Open Barcode app; - Scan the product's barcode => The product's stock locations are displayed in a list view, which is not very pratical on small device. Fix === The action key `mobile_view_mode` was not set, with this key, we can define what view type we want to prioritize for mobile device. [opw-5180783](https://www.odoo.com/odoo/project/49/tasks/5180783) Forward-Port-Of: odoo/enterprise#101957 Forward-Port-Of: odoo/enterprise#101336
This update resolves a bug where image styles (like width and transform) were incorrectly applied to new media types after an image was replaced. Now, styles are automatically cleared when switching between image and other media types, ensuring consistent and accurate media display.
Original PR description
**Current behavior before PR:** - When an image had styles applied to it (such as transform or width) and was replaced with another media type like an icon or document, those styles were incorrectly carried over to the replaced media. **Desired behavior after PR is merged:** - Since transform and width styles are meant to apply only to images, they are now removed when an image is replaced with other media types. task-5373362 Forward-Port-Of: odoo/odoo#240284 Forward-Port-Of: odoo/odoo#238319
This update fixes a potential issue where invoices generated from sales orders didn't always align with the correct fiscal partner information. Now, invoices use the invoice partner's details, ensuring consistent fiscal calculations across sales orders and their corresponding invoices. This improves accuracy and avoids discrepancies in financial reporting.
Original PR description
## Before this commit Fiscal position on Sale Orders was computed based on `partner_id` and `partner_shipping_id`. However, during invoice creation from a Sale Order, We uses `partner_invoice_id` as the invoice’s `partner_id`. This mismatch caused fiscal inconsistencies between the Sale Order and the generated Invoice in certain edge cases. ## After this commit Fiscal position is now computed using `partner_invoice_id` to ensure that both the Sale Order and its Invoice use the same fiscal partner reference. This aligns fiscal determination across documents and avoids inconsistencies in scenarios where the invoice partner differs from the order’s main or shipping partner. opw-5367523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239806
This update clarifies the call settings interface for users who have muted participants. Previously, the interface was confusing, showing the 'deafen' icon with the 'unmute' label. Now, only the 'undeafen' button is displayed when a participant is muted, providing a clearer and more intuitive experience.
Original PR description
Before this commit, the hint in the call settings was not taking into account if it was deafen or mute. On top of that the icon in the menu was showing the deafen icon but with the unmute label. When deafened, this was redundant with the undeafen button as well since unmute and undeafen are practically doing the same thing. Now, when deafen is activated, only the undeafen button is shown in the call menu and the hint in the call actions is undeafen not unmute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242519
This update resolves issues that could lead to data inconsistencies when uninstalling the 'mail' module. Specifically, it ensures that model and field definitions are properly cleaned up during uninstallation and adds warnings to alert developers to potential problems with deleted records.
Original PR description
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled. It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator. ### Add warnings…
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled.
It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator.
### Add warnings when some model/field could not be deleted
The uninstallation process tries to delete all the records created by the modules being uninstalled. It uses a best-effort strategy, i.e., it skips the records that cannot be deleted, whatever the reason. But some records are very likely to cause problems, namely `ir.model` and `ir.model.fields` records, because skipping them implies not cleaning up their corresponding table's schema.
For instance, if a column is not dropped, reinstalling the corresponding module will possibly cause inconsistencies, because
- the column contains old values for existing records, which won't be recomputed (if the field is computed);
- the column contains NULLs for records created between the uninstallation and the reinstallation of the module.
We therefore add a warning in those cases, in order to detect and fix those potential issues as soon as possible.
### Make ondelete decorator work as documented
A method decorated with `@api.ondelete(at_uninstall=False)` should be called except when the method's module is being uninstalled. Currently the method is skipped when *any* module is uninstalled.
The fix consists in adding the set of modules being uninstalled in the attribute `registry.uninstalling_modules`, which may be used to detect uninstallation and determine which modules are being uninstalled.
### Replace MODULE_UNINSTALL_FLAG by new conventional flag 'force_delete'
We turn constant `MODULE_UNINSTALL_FLAG` into an explicit conventional flag, and rename it `force_delete` for the sake of simplicity. The idea is to decouple the flag from uninstallation. The caller simply uses
```py
records.with_context(force_delete=True).unlink()
```
to bypass some deletion hooks, which typically prevent deletion by raising some exception, in order to avoid data inconsistencies. On the callee's side, one has to explicitly detect the flag and skip the checks, like in:
```py
@api.ondelete(at_uninstall=False)
def _prevent_deleting_confirmed(self):
if self.env.context.get('force_delete'):
return
if any(record.state == 'confirm' for record in self):
raise UserError(_("You cannot delete confirmed records!"))
```
Note that the uninstallation process uses the convention by automatically adding `force_delete=True` in the `context` for deleting records.
### Fix issue module mail uninstallation
Two overrides of `unlink()` on models `ir.model` and `ir.model.fields` fail when uninstalling module "mail", because their code relies on some columns and those columns have been dropped already. This causes some table and column to remain after uninstallation. When reinstalling module "mail", errors like follows are logged:
```
column "mail_message_id" of relation "mail_tracking_value" contains null values
```
The fix consists in turning the overrides in proper "ondelete" methods, which are skipped when module "mail" is uninstalled.
https://github.com/odoo/enterprise/pull/103651This update resolves an issue that could cause errors during the removal of certain Odoo modules. The changes ensure that data is handled correctly when a module is deleted, preventing potential data loss or system instability. This improves the overall reliability of the Odoo Enterprise platform.
Original PR description
Companion of https://github.com/odoo/odoo/pull/242777
This update resolves an issue where pressing "Enter" in a form containing a Kanban-displayed x2many field would cause the system to crash. The fix ensures the Kanban renderer handles optional properties correctly, preventing errors and improving form stability. This ensures a smoother user experience when working with related records.
Original PR description
Be in a form view containing an x2many field displayed as a kanban view. Press "Enter". Before this commit, it crashed, because the kanban renderer tried to access it's `quickCreateState` props which was undefined. The props is indeed optional, so we must be careful when reading/using it. Issue introduced by https://github.com/odoo/odoo/pull/228632 Spotted by task~5441808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that all MOA (Monthly Accounting) values within the French accounting module are positive integers. Previously, the system could generate negative values, which caused errors. This change improves data accuracy and reliability for French tax reporting.
Original PR description
All MOA fields should be positive integer. task-5380637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242976 Forward-Port-Of: odoo/odoo#239587
This update corrects a discrepancy in the calculation of employment bonuses for the Belgian payroll module (l10n_be_hr_payroll). The changes ensure bonus calculations are accurate up to March 2026, aligning with the latest tax regulations. This update maintains accurate financial reporting and compliance for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update fixes an issue where the timesheet timer wasn't correctly associated with the task being worked on. The fix ensures the timer uses the correct task or project from the list view, providing a more accurate and user-friendly timesheet experience. This prevents timesheets from being incorrectly linked to the user's favorite project.
Original PR description
### Issue: When looking at the list of timesheet for a task, we can start the time but the timer have default values that don't correspond to the task. ### Cause: `startTimer` in the `timesheetTimerService` is called from the timesheet timer hook without vals. It then makes an orm call to `action_start_new_timesheet_timer` to retrieve the fields (project or task) but as nothing is given in the vals, the selected project is the one returned by `_get_favorite_project_id()`. ### Solution: Get the context of the list view to retrieve the task or the project and input it in `vals`. opw-5342525 Forward-Port-Of: odoo/enterprise#102152
This update corrects a technical issue that prevented users from accessing bank accounts correctly when signing contracts within the HR module. The fix ensures a smooth and reliable process for managing contract signatures and associated banking permissions. This resolves a potential disruption to business operations.
Original PR description
Forward-Port-Of: odoo/enterprise#103807
This update resolves a bug impacting how absences are tracked within the HR Attendance module. The fix ensures accurate recording and reporting of employee absences, improving the reliability of attendance data. This change primarily affects the HR Attendance and HR Holidays Attendance modules.
Original PR description
Task: 5470030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242567
This pull request addresses an issue with the way absences are managed within the HR Work Attendance module. The fix ensures accurate tracking and reporting of employee absences, improving the reliability of HR data. This update resolves a technical bug impacting the core functionality of this module.
Original PR description
Task: 5470030 Forward-Port-Of: odoo/enterprise#103781
This update resolves an issue where empty popups remained open and displayed incorrect options after content was removed. The fix ensures that popups are correctly closed when empty, preventing errors and improving the user experience. This improves the reliability of the website builder.
Original PR description
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed…
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed element are still displayed and produce an error if the user interacts with them. **How to reproduce** Drop the snippet `s_popup`, and remove the "Block" element. Problems: 1. the popup is still open but empty, 2. the "Block" options are still displayed. **Origin of the problems** Problem 1 happens simply because nothing takes care of removing empty popups. Problem 2 happens because `RemovePlugin.removeCurrentTarget` set the `nextTargetEl` without first checking if the element is activable or not. Thus, when removing the last block in a popup, the next target is set to the `.o_we_no_overlay` close button, despite it being not activable. As a result, when `BuilderOptionsPlugin.updateContainers` is called, it does not update containers because the target is not activable. Thus, the "Block" options are still displayed despite the element being removed. **Fix** Both problems are fixed by changing `RemovePlugin.isEmptyAndRemovable` such that empty popups are marked as removable. task-5401692 Forward-Port-Of: odoo/odoo#242377 Forward-Port-Of: odoo/odoo#239507
This update fixes minor inaccuracies in the German Point of Sale (POS) reporting process by ensuring the correct net value is used for pricing and by sending amounts as strings to the payment processor, Fiskaly. The changes also improve rounding precision to meet Fiskaly's requirements, and adjust order amounts for customer payments.
Original PR description
In this commit: ------------------ - Transferred **net value** instead of **gross value** for `price_per_unit`. - Included **cash statement business cases** that were prepared earlier but not sent to Fiskaly. - Ensured all **amount fields are sent as strings** to Fiskaly. - Fixed rounding precision using `toFixed()` to maintain **2–5 decimal places**, as required by Fiskaly (e.g., `4.70` should not become `4.7`). - Adjusted logic for **customer account payments** to send the **adjusted order amount** instead of the original total. task: 5122652 Forward-Port-Of: odoo/enterprise#99643
This update fixes an issue where refund alerts in the Point of Sale (POS) system could be triggered incorrectly due to rounding differences in order totals. The change ensures that the system accurately compares refund amounts against original order amounts, preventing false alerts and improving the reliability of the POS system. This update enhances the accuracy of financial reporting within the POS module.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240 Forward-Port-Of: odoo/enterprise#103758 Forward-Port-Of: odoo/enterprise#102224
This update prevents users from creating new POS sessions when multiple online payment methods are linked to a single POS configuration. Previously, a workaround involving deleting payment methods was required. Now, a constraint ensures only one online payment method can be associated with a POS config, improving session stability.
Original PR description
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are…
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session. In addition, if a session is already open, it is no longer possible to resolve the situation: * From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method. * From `pos.config`: the payment methods field is read-only when there is an open session. We had to delete one of the online payment methods from the database directly to be able to open the POS session again. To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method. Forward-Port-Of: odoo/odoo#240343
This update addresses several issues impacting the accuracy of the social balance sheet calculations for Belgian payroll. Specifically, the system now correctly handles employees without certificates, avoids double-counting, and prevents incorrect gender checks on payslipless employees. These fixes ensure more reliable reporting for HR and accounting teams.
Original PR description
Forward-Port-Of: odoo/enterprise#103786
This update resolves a technical issue that caused warnings and potential crashes when searching for delayed production orders in the Manufacturing Orders list view. The change ensures the filter functions correctly and avoids future compatibility problems with Odoo's database system.
Original PR description
Issue before this commit: ========================= Searching for Delayed Productions in the MRP list view triggered: - A deprecation warning in saas-18.4 → 19.0: `warnings.warn("Since 19.0, use…
Issue before this commit:
=========================
Searching for Delayed Productions in the MRP list view triggered:
- A deprecation warning in saas-18.4 → 19.0:
`warnings.warn("Since 19.0, use Domain.custom(to_sql=lambda model, alias, query: SQL(...))", DeprecationWarning)`
- A traceback in master:
`Failed to cast TableSQL('mrp_production', -, None).date_finished into a datetime`
Steps to Reproduce:
=========================
- Install mrp module.
- Open the Manufacturing Orders list view.
- Filter by Delayed Productions.
- Observe the warning (saas-18.4 → 19.0) or traceback (master).
Cause of the issue:
=========================
Recent ORM changes in [PR](https://github.com/odoo/odoo/commit/f811af2c52df798b6ba0fc18e3f45944abdb7a12) disallow using raw SQL expressions as values inside normal domains.
Only Domain.custom() is permitted for injecting custom SQL.
The previous _search_is_delayed implementation used a deprecated pattern,
which caused the warning in current versions and a crash in the master version.
With This Commit:
=========================
- Rewrite the delayed production filter using Domain.custom() to safely generate the SQL.
- Preserve functional behaviour: the filter still returns delayed productions correctly.
- Avoid deprecation warnings and prevent traceback.
TaskID:- 5404547
Forward-Port-Of: odoo/odoo#243134
Forward-Port-Of: odoo/odoo#239574This update resolves a problem where the sign flow's dropdown menu wouldn't display all available styles correctly. Previously, users had to wait for a background process to complete before selecting options, leading to a limited selection. This change ensures all styles are consistently available in the dropdown.
Original PR description
In this tour, when we want to select the third dropdown item in style list menu, we must wait that the rpc get_fonts/ is done, or else, it has only one item in the menu. When the menu is opened before the call is completed, there is only one style. When it is opened after, there is all styles loaded. runbot-error-id~232652 Forward-Port-Of: odoo/enterprise#103813
This update corrects a display issue where the CFDI button was incorrectly shown on payruns that didn't meet Mexican tax requirements. The change ensures the button only appears for payruns containing Mexican payslips, improving the user experience and preventing unnecessary complexity. This fix enhances the accuracy of payroll reporting.
Original PR description
Before this commit, the computed fields `l10n_mx_cfdi_primary` and `l10n_mx_cfdi_secondary` would return True for payruns containing only non-Mexican payslips. This happened because `all()` returns True for empty iterables, causing the CFDI button to appear on payruns that have no Mexican payslips. This commit: - Adds explicit check for Mexican payslips existence before evaluating the CFDI state conditions - Hides `l10n_mx_edi_cfdi_origin` field for non-Mexican payslips - Adds test coverage for CFDI visibility on non-Mexican payruns task-5478038
This update resolves an issue where the attendance app would crash when an employee didn't have a linked calendar. The fix ensures the app handles employees with flexible schedules properly by skipping calendar periods when a calendar isn't assigned, aligning with existing flexible calendar functionality.
Original PR description
Steps to reproduce: - Create an employee - Remove the calendar to have fully flex - Open the attendance app -> traceback When an employee has no resource calendar (resource_calendar_id=False), the _gantt_unavailability method would crash with a TypeError when trying to create a ZoneInfo from calendar.tz (which is False/None). This fix adds a check to skip calendar periods where the calendar is not set, consistent with how flexible calendars are already handled. task-5462208
This update resolves an issue with how hourly wages are calculated, ensuring greater accuracy for payroll processing, particularly for employees with variable working schedules. The changes also eliminate a technical dependency issue that previously caused unexpected validation errors when managing offers.
Original PR description
- All percentage fields now use self.env.remove_to_compute to break circular dependencies, so UIs no longer need the ad-hoc skip_percentage_calc context. - _l10n_in_get_montly_wage now derives monthly hours from the version’s or its company’s resource calendar via hours/week previously it was static to 22 days. - fix raises validation when opening offer after changing working schedule it raise validation error which isn't expected behaviour. task-5421228 Forward-Port-Of: odoo/enterprise#102488
This update removes a confusing and unnecessary filter option (Templates) from project selection screens in other apps. Previously, the filter appeared globally due to a shared search view. This change simplifies the user experience and ensures consistency within the project module.
Original PR description
**Steps to reproduce:** - Open the Planning app or any app where project_id field - Click New - Click on the Project field - Click Search More - Look at the search filters - The Templates filter is visible **Issue:** The Templates filter shows up when choosing a project from there, even though it is not useful there. **Cause:** They uses the same project search view as the main project app, so the templates filter appears everywhere. **Fix:** Add a condition check in filter to make invisible in other module and show only in project. **Dev Notes (sale_project):** The context was already used for milestone display name computation, but it was missing in the sale_project override. Due to this, when Project Stages were enabled, the milestone display name did not include the deadline. task-5255295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241797
This update fixes an issue where milestone deadlines weren't shown in the Project list view. The fix ensures that milestone names now accurately include the associated deadline, providing users with clearer project timelines. This improves the usability of the Industry FSM module for project management.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the overrided action's context, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295 Forward-Port-Of: odoo/enterprise#103157
This update fixes a visual issue where long product names in the combo configurator popup caused misalignment of product cards. The change ensures all product cards remain consistently aligned and sized, regardless of the length of their names, improving the overall user experience and consistency of the configurator.
Original PR description
Before this commit: ================= Product cards with long names caused a slight vertical misalignment in the combo configurator popup, resulting in inconsistent card sizes within the grid. After this commit: ================== Ensure all product cards remain uniformly aligned and maintain consistent dimensions in the combo configurator popup, even when product names are long. Task:5447320 Forward-Port-Of: odoo/odoo#243089 Forward-Port-Of: odoo/odoo#241720
This update fixes a technical issue that caused users to see confusing tracebacks when errors occurred during the ZATCA onboarding process. Now, users receive clear, user-friendly alerts with the actual error message returned by ZATCA, improving the onboarding experience and ensuring compliance.
Original PR description
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace…
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace result in exactly 127 bytes; see refs [1] and [2])—the system returns a traceback to the user instead of a clear and user-friendly error message. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType' This is due to the check-in `_l10n_sa_request_production_csid` for an 'error' key, not present in the response when an OTP is invalid because in these cases, the `_l10n_sa_call_api` returns the response_data directly. This fix improves the behaviour by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback. This ensures a better experience and compliance with CCSID onboarding flows. [1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571 [2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960 sentry-7169834710 Forward-Port-Of: odoo/odoo#242810
This update resolves an issue where using many2many filters with archived records caused errors. The fix ensures that the system gracefully handles inactive records, preventing exceptions and maintaining filter functionality. This improves the stability and reliability of the calendar view.
Original PR description
Description of the issue/feature this PR addresses: In fa56409 support was added for many2many filters in the calendar arch. Since X2many fields use the many2one formatter (see makeFilterDynamic) filters need to be passed in the following format [id, display_name]. Since x2many records are not automatically fetched in this format fa56409 added an additional step wherein colors and display names are fetched (by calling searchRead) and filters are properly formatted. An issue arises though if a record is archived and therefore not found by searchRead. In this case the filter will not be properly formatted and formatMany2one will raise an exception. Current behavior before PR: Using a x2many filter with an archived record raises an exception. Desired behavior after PR is merged: Using a x2many filter with an archived record will not raise an exception. (ref: #241522) Forward-Port-Of: odoo/odoo#243030
This update corrects a mistake in how taxes are aggregated for the French (l10n_fr) version of Odoo. Specifically, a calculation error in 'box 15_1' was identified and resolved. This ensures accurate tax reporting for French businesses using Odoo.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/869f80b466ec2246f27e11fa823eb32ac664fb01 we made a mistake in the box 15_1. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243099 Forward-Port-Of: odoo/odoo#243013
This update prevents non-administrator users from accessing the Discuss settings. Previously, they would receive an error message when attempting to change configuration options. Now, the settings menu is hidden, ensuring that sensitive configuration options are only accessible to authorized administrators.
Original PR description
**Steps to reproduce:** Open Discuss > Configuration > Settings. **Current behavior before PR:** Non-admin users encounter an access error when clicking 'Settings'. **Desired behavior after PR is merged:** The 'Settings' menu item is now hidden for users who are not part of the 'Role / Administrator' group. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue where the test button on the IoT device dashboard incorrectly reported successful connections even when errors were present. The fix standardizes the data format used for IoT device status checks, ensuring accurate reporting and a more reliable user experience. This improves the overall stability of the IoT integration.
Original PR description
This commit fixes several situations where a positive status would be given by the test button despite the presence of an error: - If the websocket connection was used but there was a timeout - If the websocket connection was used but there was any other error - If any 6-digit error code was returned when using the stable IoT box To fix these issues, we stop using the `data['message']` field, since it gets ignored by the websocket confirmation controller. We now use the same result format as the other requests (and the stable IoT box). We also add a check for the `"timeout"` that we receive when a websocket request times out. Forward-Port-Of: odoo/enterprise#103861 Forward-Port-Of: odoo/enterprise#103817
This update corrects a bug where the FAIA XML reports generated for l10n_lu companies with products having multiple taxes were missing a crucial element, `TaxBase`. This change ensures compliance with Luxembourg tax reporting requirements and prevents potential reporting errors. The fix impacts the generation of General Ledger → FAIA XML reports.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103862 Forward-Port-Of: odoo/enterprise#101178
This update fixes an issue where cancelling a backorder MO also incorrectly cancelled related 'post -> stock' pickings in multi-step production routes. The change ensures that pickings are only cancelled if no MOs have been completed, preventing unnecessary disruption to inventory management. This improves the reliability of the production process.
Original PR description
Issue ----- For multi step routes, cancelling the backorder MO also cancels the (post -> stock) picking for the produced quantity. Steps to reproduce ----- - Activate routes - Go to the main warehouse and activate 3 step production - Creation of a MO for 100 units - Validate the pre production picking - Produce 40 units and create a backorder for remaining quantity - Cancel the backorder > The "post -> stock" picking is cancelled as well Cause ----- The picking is in "ready" state, so it gets cancelled by https://github.com/odoo/odoo/blob/083d53c688a0d18a1f4594b9fcbbfa738aa5e86d/addons/mrp/models/mrp_production.py#L1743-L1744 Desired behaviour ----- > Only cancel related MO pickings (pre prod/post prod) if no MO (or MOs) done yet. Don't cancel related MO pickings if any MO validated. ----- Ticket: opw-5405024 Forward-Port-Of: odoo/odoo#242969 Forward-Port-Of: odoo/odoo#239865
This update resolves an issue that previously prevented users from creating attendance records when the 'Planning' work entry source was selected. The fix corrects errors related to date and time calculations during attendance creation, ensuring accurate attendance tracking when using the planning feature. This improves the reliability of the attendance management process.
Original PR description
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to…
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):** - Install the `hr_work_entry_planning_attendance` module. - Go to `Employees` and create a `new employee` or open an `existing one`. - In the `Payroll` section, set `Work Entry Source` to `Planning`. - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%. - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates. **Error 1:** `AttributeError: 'method_descriptor' object has no attribute 'min'` **Error 2:** `TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given` **Cause:** When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot. If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples. **Fix:** This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format. [1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57 [2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60 **No Task ID** Forward-Port-Of: odoo/enterprise#103662
This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the correct 'OUT' operation for multi-step deliveries. The fix ensures the wizard now selects the final, customer-facing 'OUT' operation, streamlining the return process and improving data accuracy.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a…
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134 Forward-Port-Of: odoo/enterprise#103883 Forward-Port-Of: odoo/enterprise#93154
A bug preventing the 'Total Cost' field from appearing in pivot views within the Stock reporting module has been resolved. This update corrects a technical issue related to how data aggregation was handled in pivot views, ensuring the reporting functionality works as expected. This fix improves the usability of the Stock reporting feature.
Original PR description
Steps to reproduce: 1) Make sure "Developer mode" is on, go to "Inventory" -> "Reporting" menu -> "Stock" 2) Click "bug" icon -> select "Action" -> add "pivot" to "View Mode" field 3) Refresh page…
Steps to reproduce: 1) Make sure "Developer mode" is on, go to "Inventory" -> "Reporting" menu -> "Stock" 2) Click "bug" icon -> select "Action" -> add "pivot" to "View Mode" field 3) Refresh page and go back to "Stock" report 4) Go to "pivot" view -> click "Measures" -> select "Total Cost" Expected behavior: The field should be added to the view as an aggregate. Current behavior: An error is thrown, due to a bad SQL query. This is because previously, pivot views used `_read_group` to fetch the data, but now after #194413, it uses the new method `_read_grouping_sets` instead. The issue was that the SQL-computed fields defined in `product_margin` were handled in a special way in an override of `_read_group`. However, when `_read_grouping_sets` was introduced, their special implementation was not implemented, so aggregating on any of those special fields, resulted in a broken SQL query. This commit fixes this issue by overriding `_read_group_sets` for those sepcial fields in a similar way to `_read_group`. opw-5345013 Forward-Port-Of: odoo/odoo#238679
This update fixes a minor discrepancy in sales order tax calculations, specifically when discounts are applied. Previously, a small tax difference ($0.01) could appear in the order total due to a discount. The fix ensures that the tax delta is correctly distributed even with zero tax totals, improving overall financial accuracy.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set tax rounding to "Round Globally"; 2. create a 19.99% tax; 3. create a new sales order; 4. add a line with a $19.99 unit price & 19.99% tax; 5. add a second line with identical values; 6. apply a 100% global discount (-$38.98 subtotal, -$47.97 total). Issue ----- The order total is $0.01 due to VAT. Cause ----- The `_round_tax_details_tax_amounts` method distributes the "tax delta" across the tax details, but currently it only does this if there's a non-zero target tax amount. In our scenario, we have a $0.01 tax delta, but because our tax total is $0.00 due to the 100% discount, the delta doesn't get distributed, leading to the $0.01 difference not getting corrected. Solution -------- When deciding whether to distribute a tax delta, check the tax delta value instead of the target tax amount. opw-5345538 opw-5097907 Forward-Port-Of: odoo/odoo#243172 Forward-Port-Of: odoo/odoo#240633
This update resolves an issue where changing a commission plan's effective dates would erase associated targets and forecasts. Now, the system correctly checks if new dates are within the plan's range and removes outdated targets, ensuring accurate reporting and planning. This improves the reliability of commission calculations.
Original PR description
Before this commit, changing the Effective Period of a Commission Plan was erasing all the targets and forecast linked to that plan. After this commit, this is no longer the case as we compare if the new targets are within the range and delete the out-of-period targets. task-5469817 Forward-Port-Of: odoo/enterprise#103363
A bug in the website tour testing process was causing tests to fail due to snippets being dropped into open popups. This update ensures that popup snippets are automatically removed after being dropped, resolving the issue and improving test reliability. This prevents disruptions to the website tour experience.
Original PR description
**Problem** Before this commit, the tour `test_03_snippets_all_drag_and_drop` could fail with the error `Element (:iframe .o_snippet_preview_wrap[data-snippet-id="s_popup"]) has not been found`. The failure was reproducible locally and appeared non-deterministically on runbot. **Cause** The tour steps could occasionally execute too quickly, leading to non-determinist behavior where snippets were dropped inside a popup that had been inserted but not yet closed. When the dropzone is inside an open popup, some snippets (e.g. `s_popup`) are excluded from the Snippet Viewer, resulting in the error reported above. **Solution** The tour flow is modified such that popup snippets are removed after being dropped, as already happens for every other snippet category. This completely removes the risk that new snippets are dropped into a popup. runbot-233328 Forward-Port-Of: odoo/odoo#242231
This update fixes an issue where users could hide a channel during an active call. The change prevents this action from appearing, ensuring channels remain visible and accessible throughout ongoing conversations. This improves the user experience and prevents disruption during calls.
Original PR description
Purpose: When a call is active in a channel, the “Hide until new message” action is still available, which does not make sense since the channel should remain visible throughout the call. This commit hides the “Hide until new message” action from the action list when an active call is ongoing, preventing users from hiding the channel mid-call. task-5469844
This update fixes a display issue where the customer order total incorrectly showed prices excluding taxes. The change ensures that the customer display always shows the total price including taxes, aligning with the main PoS product display. It also provides a more detailed breakdown of prices – subtotal and taxes – for better transparency.
Original PR description
Steps to reproduce ------------------ 1. In PoS settings, set the "Tax Display" to "Tax-Excluded Price" 2. Enable customer display 3. Open a PoS session, and open the customer display simultaneously…
Steps to reproduce ------------------ 1. In PoS settings, set the "Tax Display" to "Tax-Excluded Price" 2. Enable customer display 3. Open a PoS session, and open the customer display simultaneously 4. Add products, notice that the total in PoS is price included as expected. However, the total in cusromer display is tax excluded, so customer thinks he will be pay less. Why it happens ---------------- In the refactors done in 9538698f13d5763b4, we mistakenly set the order.amount (i.e. total amount) to follow the config "Tax Display". However, that price should always be tax incl. In this PR, we now use the `currencyDisplayPriceIncl` getter, instead of the config dependent `currencyDisplayPrice`. Additional enhancements ------------------------- In additional to total price, we also display the taxes amount not. And In case of "Tax-Excluded" price config, also display the subtotal (total price excluded). **That follows exactly the UI of the main cart in the products page**. So now we have ---------------- Tax included: <img width="558" height="659" alt="image" src="https://github.com/user-attachments/assets/51415c5c-2234-48dd-a974-572a6b090714" /> Tax excluded: <img width="550" height="661" alt="image" src="https://github.com/user-attachments/assets/2c664716-49ab-44eb-bb30-ad42206bc849" /> opw-5401560 Forward-Port-Of: odoo/odoo#239250
This update fixes an issue where inline code blocks wouldn't fully disappear when deleting the last character. Now, removing the final character of an inline code block correctly removes the code style and the block itself, improving the user experience when editing text with code snippets. This ensures consistent formatting and cleaner content.
Original PR description
Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140 Forward-Port-Of: odoo/odoo#240805 Forward-Port-Of: odoo/odoo#238552
This update fixes a minor issue in the HTML editor's testing process. The previous method sometimes duplicated selection actions, leading to inconsistent test results. This change ensures the selection process is more reliable and accurate, improving the overall stability of the HTML editor.
Original PR description
The `simulateArrowKeyPress` method used in hoot tests performs both an actual `press` and modifies the selection. However, in some cases, the `press` already updates the selection because of our own listeners, which leads to a selection similar to performing the action twice. This commit avoids this by making sure the default `press` did not get prevented by our own custom listeners before modifying the selection. task-5438683 Forward-Port-Of: odoo/odoo#243108 Forward-Port-Of: odoo/odoo#241604
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures that the deduction amount accurately reflects the latest tax regulations up to the year 2026, improving payroll accuracy for Belgian users. This is a critical fix to ensure compliance with local tax laws.
Original PR description
Forward-Port-Of: odoo/enterprise#103891 Forward-Port-Of: odoo/enterprise#103824
This update clarifies the terminology used for payroll input types, renaming 'Other Input Types' and 'Payslip Other Input Types' to 'Salary Input Types'. This change enhances user understanding and simplifies the payroll configuration process, improving overall usability.
Original PR description
Updated the Input type for better clarity and easier understanding for users: - '**Other Input Types**' : 'Salary Input Types' - '**Payslip Other Input Types**' : 'Salary Input Types' **task-5474028** Forward-Port-Of: odoo/enterprise#103632