Daily updates from Odoo
Monday, February 9, 2026
10 changes · saas-18.4
Resolved issues and error corrections
This update fixes an inconsistent visual issue in the Field Service Report generated from the Bubble document layout. The report's tables had conflicting border styles, resulting in a jarring appearance. By adding a specific CSS class, the report now consistently uses rounded borders, improving its overall professionalism and readability.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any…
Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any Field Service task 5. Use the Products smart button to add one or more products 6. Click the Settings icon > Print > Field Service Report Observation: -------------------------------- In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals Issue: -------------------------------- The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders Solution: -------------------------------- Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout Before: <img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" /> After: <img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" /> opw-5401612 Forward-Port-Of: odoo/enterprise#105616
This update ensures that a failure message is now correctly displayed when a quality check is marked as failed. Previously, the system didn't show the intended failure notification. The fix corrects a technical issue related to how the system handles quality check states, ensuring users receive the expected feedback.
Original PR description
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t…
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown. **Steps to produce:** * Install `Quality` and `Manufacturing` with demo data * Go to MRP > Configuration > Operations > Manual Assembly * Create a pass/fail quality point with a failure message * Create and confirm an MO for `Table Top` * Go to Shop Floor > Activate work centers if inactive > Manual Assembly * Fail the assembly using the quick-action button Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing) **Observed Behavior:** * No failure message is displayed when the quality check is failed. **Root cause:** * This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears. **Solution:** * Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions. **Before:** <img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" /> **After:** <img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" /> [1]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 [2]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 [3]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 [4]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 [5]: https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161 opw-5403465 Forward-Port-Of: odoo/enterprise#102095
This update resolves an issue where journal items displayed in general ledger reports were incorrectly linked to account groups. The problem stemmed from a change in Odoo 18.0 that prevented a previous fix from working. The update now uses a more robust SQL query to accurately retrieve the correct account IDs, ensuring correct reporting.
Original PR description
Currently journal items shown don't belong to the account group that they should belong to, and from saas-18.3 an error will be generated after following the below steps or step mentioned in ref PR…
Currently journal items shown don't belong to the account group that they should belong to, and from saas-18.3 an error will be generated after following the below steps or step mentioned in ref PR [1]. - Install `Accounting (accountant)` with demo data - Create account groups e.g., name as `Test 1` and code prefix `1 to 1` - Go to the general ledger report - Click on `Journal Items` of the account group line `1 Test 1` Error from saas-18.3: `ValueError: Cannot convert account.account.group_id to SQL because it is ...` This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the `account.account` model to the search domain. However, in 18.0, commit [2] modified this field so that it is no longer stored. As a result, when a search domain includes this `non-stored` field, Odoo skips the domain evaluation and logs a error at code line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0. Also, starting from saas-18.3, passing such a non-stored field in a domain raises an explicit error at code line [4], instead of being silently ignored. This commit resolves the issue by introducing an SQL query that returns the account ids related to `record_id(account group id)` include `record_id` as `None`. [1]: https://github.com/odoo/enterprise/pull/100191 [2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767 [3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174 [4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201 sentry-7100657414 Forward-Port-Of: odoo/enterprise#103137
This update resolves an error that prevented non-employee users from creating expenses linked to uploaded documents. The issue stemmed from a required field ('employee_id') not being populated correctly. The fix now displays a user-friendly error message instead of crashing, ensuring a smoother experience for all users.
Original PR description
Currently an exception is generated when the non-employee user tries
to generate expenses from the documents.
Steps to produce an error:
- Install the `documents_hr_expense` module without demo data
- Delete employee `Administrator`
- Upload any PDF/image file inside the company's `Internal` folder
- Click on the uploaded document and click on the `Create an Expense` button
Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...`
This error occurs because `employee_id` is required when creating an
expense. Since the current user is not linked to an employee record,
`employee_id is` set to false, which causes the issue.
This commit resolves the issue by raising a `UserError` when the current
user is not linked to an employee.
sentry-7192984733
Forward-Port-Of: odoo/enterprise#104966
Forward-Port-Of: odoo/enterprise#104762This update fixes an issue where Modelo 390 reports for past years were generating empty BOE files. The fix ensures the report correctly uses the specified year's data, resolving a discrepancy between the report and the actual tax information. This improves the accuracy of tax reporting for Spanish companies.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374 Forward-Port-Of: odoo/enterprise#106676 Forward-Port-Of: odoo/enterprise#104928
This update simplifies the sales order reporting for subscription customers. The 'remaining hours' field, which could be misleading due to the recurring nature of subscriptions, has been hidden. This ensures a clearer and more intuitive experience for our customers and reduces potential confusion.
Original PR description
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic. In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle. To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription. opw-5246238 Forward-Port-Of: odoo/enterprise#99813
A recent page refresh issue was preventing the restaurant appointment tour from working correctly. This update refactors the tour to maintain a consistent simulated time, ensuring appointments remain visible and the tour functions as expected after a reload. This improves the user experience for restaurant bookings.
Original PR description
The `RestaurantAppointmentTour` fails when page refreshes reset the mock clock to system time, causing the frontend to filter out mock appointments and the tour to timeout. Refactor the tour to use the new `withTimeFreeze` helper, ensuring the simulated date persists across reloads so appointments remain visible. runbot-232601 Related Community PR: odoo/odoo#247596
This update automatically generates unique employee IDs and sets the initial marital status to a person's birthday if they are single. This simplifies the onboarding process for new employees in the Swiss payroll system, reducing manual data entry and improving data accuracy.
Original PR description
For quality of life improvement, the unique employee identification is now automatically generated and initial marital status date is set to the birthday by default if the person is single Forward-Port-Of: odoo/enterprise#106752
This update clarifies the type of data stored in a key vector field within the AI module. Adding a 'ttype' field provides better organization and control over vector data, ensuring data consistency and improving the overall reliability of AI-powered features. This change is a technical refinement to enhance the AI module's functionality.
Original PR description
Add field ttype for vector field. community: https://github.com/odoo/odoo/pull/247542 For problem https://github.com/odoo/odoo/pull/247323#discussion_r2767940038
This update standardizes the way time off and absences are managed within the Odoo Enterprise system. It backports a fix that ensures consistent reporting and processing of these employee-related data points, improving accuracy and streamlining HR workflows. This change primarily affects the CH (Switzerland) payroll module.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/f238e04f3f6c39b61d0449a0766809df06eb6980 task-5384297 Forward-Port-Of: odoo/enterprise#101449