Daily updates from Odoo
Wednesday, July 1, 2026
28 changes · master
Enhancements to existing features
The shipping setting formerly called "Batch Shipping" has been renamed to "Multicollo". This makes the wording match Sendcloud’s own terminology and helps avoid confusion for users configuring delivery options.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477
Users can now see product availability and expected arrival information directly in the stock move list view for planned field service sales orders. This removes the need to open each record just to check replenishment timing, making it faster to review pending deliveries.
Original PR description
Previously, when a sales order for a field service product was planned, adding supplementary products only displayed the basic delivery status in the stock moves list view. To view the replenishment forecast or expected arrival date, users had to navigate into the form view. - This commit exposes the `forecast_widget` in the list view. Users can now check product availability and arrival timelines at a glance without opening individual records. task-5929015
Belgian payroll now better handles extra hours worked by part-time employees, while keeping track of the usual full-time limits in the company. It also adds clearer payroll warnings so unusual cases can be caught earlier, helping avoid validation issues and payroll mistakes.
Original PR description
Introduce support for part-time additional hours in Belgian payroll (hours worked beyond the contractual part-time schedule, without exceeding the normal full-time working limits in the company)
- Add 3 dedicated work entry types (0%, +50%, +100%)
- Add payslip warnings for:
- monthly limit (>12h)
- daily limit (>9h)
- weekly limit (reference schedule)
- invalid type on Sundays/public holidays
- overlap with working time
Related PRs:
odoo: https://github.com/odoo/odoo/pull/269726
upgrade: https://github.com/odoo/upgrade/pull/10581
task-5484105The Belgian payroll configuration now groups certain time-based benefits, such as private car, meal vouchers, and representation fees, into categories instead of simple yes/no flags. This makes the setup more consistent and easier to manage in payroll rules and payslip calculations.
Original PR description
In this commit, we converted time type benefits (private_car, meal_voucher, representation_fees) from boolean fields into categories. task-6193618
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. This commit changes the `shopee_buyer_identifier` field type to be `Char` and cleans the stable workar
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. This commit changes the `shopee_buyer_identifier` field type to be `Char` and cleans the stable workaround. opw-6325948 See also: - stable: https://github.com/odoo/enterprise/pull/121498 - upgrade: https://github.com/odoo/upgrade/pull/10578
For an accountant, the dmfa report is too detailed, he needs a grouped summary. task: 6307733
Original PR description
For an accountant, the dmfa report is too detailed, he needs a grouped summary. task: 6307733
Enable testing of DIMONA declarations without making actual API calls to ONSS by using the sandbox environment in the settings. Go to Payroll → Reporting → Create Declarations From JSON. Here you can create a declaration in the same format received from the government. You can also go to Payroll → Reporting → DIMONA and create any DIMONA declaration without sending real API calls. Create an employee and click the Check DIMONA button. A wizard will appear, allowing you to enter the fake respon
Original PR description
Enable testing of DIMONA declarations without making actual API calls to ONSS by using the sandbox environment in the settings. Go to Payroll → Reporting → Create Declarations From JSON. Here you can create a declaration in the same format received from the government. You can also go to Payroll → Reporting → DIMONA and create any DIMONA declaration without sending real API calls. Create an employee and click the Check DIMONA button. A wizard will appear, allowing you to enter the fake response you need. Task Id: 6069261
Payroll calculations now ignore worked day lines for company executives, so their payslips are handled more appropriately. This reduces unnecessary payroll data on executive slips and helps keep calculations and reports clearer.
Original PR description
task-6332908
This update aligns the data cleaning and data merge records with the same way Odoo Community stores references to related records. It improves consistency between editions and helps these tools work more reliably with linked data.
Original PR description
Adapt to Odoo community, by applying the same res_id reference change to data_cleaning.record and data_merge.record. Community: https://github.com/odoo/odoo/pull/268906.
The payslip calendar button now includes a Gantt-style timeline view, giving managers a clearer way to see payroll-related dates and scheduling at a glance. This makes it easier to review and plan payroll work without changing the underlying payroll process.
Original PR description
task-6348465
Belgian working schedules now only allow time types that count as working time or support reorganization measures. This helps keep schedule settings aligned with local payroll rules and reduces the risk of choosing an invalid time type.
Original PR description
In this commit, we introduce an extr domain/restraint on the time types that can be selected for belgian working schedules. Now, atop the existing domain, in belgium localization you can only select time types that count as working time, or that contribute to a reorganization measure. task-6333928
The Point of Sale barcode lookup test flow was updated to match the new quick-create product buttons, "Add & New" and "Add & Close." This keeps the automated tour working correctly after the interface change and helps prevent false test failures.
Original PR description
In this commit: =============== new buttons `Add & New` and `Add & Close` are added in quick create product view so adapt changes in tour Task-6260673 Related Comm. PR:https://github.com/odoo/odoo/pull/267661
This update hides the employee record column from standard payslip views to reduce confusion for most users, while still keeping it available in debug mode. It also increases the number of salary computation lines shown by default, which helps users in cases where payslips contain many entries.
Original PR description
Problem: - The column "employee record" on payslips worked day lines is confusing for most users and unnecessary. - The salary computation tab only shows 40 lines by default but in belgium it's always more Solution: - Show the employee record in debug mode only, by setting the `groups` field attribute to `base.group_no_one` on the view. - Increase the number of payslips lines to 200, by using the `limit` list attribute on the view. Task-6348587
Resolved issues and error corrections
Printing the Planning report now works reliably even when the report is grouped by fields such as Role or Project instead of Employee. This prevents crashes during PDF generation and ensures multi-day shifts are split correctly in all grouping modes.
Original PR description
### Issue: When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or…
### Issue: When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or `AttributeError`. ### Cause: The `action_print_plannings` method hardcoded the assumption that the `group_by` key would always be a `resource.resource` recordset. 1. When the user grouped by other fields, it returned strings, booleans, or empty recordsets, causing crashes when the code blindly called `.id` and `.display_name`. 2. During the sorting phase, mixing `False` (for unassigned empty recordsets) with strings caused a `TypeError`. 3. For multi-day shifts, the method failed to extract the actual resource to calculate the shift splits if the grouping was not explicitly set to `resource_ids`. ### Fix: - Implement safe attribute checks (`hasattr`) when extracting group IDs and display names. - Ensure unassigned empty recordsets properly fall back to the "Undefined" string and empty strings during sorting to prevent TypeErrors. - Universally fallback to extracting the resource directly from the slot (`slot.resource_ids[:1]`) for multi-day time splitting when grouped by non-resource fields. - Add a unit test to ensure stability when grouping by `role_id` with multi-day shifts. Task: 6244057 Forward-Port-Of: odoo/enterprise#118530
This update corrects the Peru Kardex PLE stock report so it produces more accurate inventory and cost figures. It also ensures landed costs appear properly in the report without adding an unnecessary hard dependency, which improves reliability and compatibility in daily reporting.
Original PR description
*Continuing on the work from https://github.com/odoo/enterprise/pull/111526, new PR because we cannot push to it.* Adapt the Kardex PLE 12.1/13.1 reports from the SVL-based approach in 18.0 to the stock.move-based approach required in 19.0. Key changes: - Use traceable IDs (account_move_id/stock_move_id) for CUO field - Back-calculate opening balance cost at report date instead of using current standard_price, which is wrong when post-period purchases have changed the average cost - Filter storable products only (is_storable) matching v17/v18 behavior - Handle negative opening balance quantities correctly - Add bridge module l10n_pe_reports_stock_landed_costs to show landed costs as separate Kardex lines (operation_type=26) without forcing stock_landed_costs as a hard dependency Forward-Port-Of: odoo/enterprise#121855
This update prevents an error that could occur when the system fetched an IoT device record and found more than one match. It makes the lookup return just one device, improving reliability and avoiding interruptions in IoT-related workflows.
Original PR description
Currently, a singleton error occurs while accessing the `type` field on `iot_device`, as the search assigned to `iot_device` returns multiple `iot.device` records. Error: `ValueError: Expected singleton: iot.device(5, 10)` This commit fixes the above issue by adding `limit=1` to the search, ensuring that `iot_device` always contains a single record and preventing the singleton error. Sentry-7579060623 Forward-Port-Of: odoo/enterprise#122219
Users can now select accounts with the Other Expenses type when creating financial budget lines. This aligns budget setup with all profit and loss accounts, making budgeting more complete and avoiding a selection blocker.
Original PR description
Currently, accounts with the `Other Expenses` account type cannot be selected in financial budget lines. **Steps to reproduce:** - Install the `accountant` module. - Go to `Chart of Accounts` and…
Currently, accounts with the `Other Expenses` account type cannot be selected in financial budget lines. **Steps to reproduce:** - Install the `accountant` module. - Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`. - Go to Accounting > Configuration > Financial Budgets. - Create a new budget and add a budget line. - Try to select the newly created account. **Observation:** Accounts with the `Other Expenses` type are not available for selection in budget lines. **Root Cause:** At [1], the `expense_other` account type is missing from the `account_id` domain. **Expected Behavior:** Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting. **Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709 **Fix:** This commit ensures that users can add `Other Expenses` accounts to budget lines. [1]: https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120 opw-6313835 Forward-Port-Of: odoo/enterprise#121735
This update corrects button and keypad visibility issues in the Point of Sale ticket screen for certain local setups. It ensures the right controls appear only when they should, and also improves the appearance of a prep-order input field in dark mode.
Original PR description
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install…
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install `l10n_in_pos_urban_piper`. - Open a draft Urban Piper order and notice that the numpad is visible. Cause: ====== - The numpad visibility depends on a `t-if` condition in XML. - Due to the asset loading order, this condition gets overridden by another module. Fix: ==== - Move the visibility logic to a getter method. - Override the getter in other modules instead of using XML to control the visibility. - Also fixed the css issue for prep order time input when using it in dark mode --- Issue 2: ====== Invoice button visible on Chile Company's TicketScreen Steps to reproduce: =============== - Ensure `pos_urban_piper` is installed, open the Chile company's PoS Config - In the ticket screen, we have an invoice button on paid orders. Cause: ===== - Button visibility handled through XML conditions; this condition gets overridden by another module. Fix: === - Move the visibility logic to the getter method and override it in submodules to control visibility. Task-6299415 Related Community PR: https://github.com/odoo/odoo/pull/270088 Forward-Port-Of: odoo/enterprise#120571
Quality emails sent to an alias are now correctly turned into quality alerts even when the team’s company was not set. This prevents incoming messages from being lost and helps ensure issues are captured and followed up as expected.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#121778 Forward-Port-Of: odoo/enterprise#109947
This change keeps POS order totals and line quantities in sync when a table order is split and paid more than once. It prevents already-paid items from still appearing on the parent order, so cashiers cannot accidentally charge the same items again from the Orders tab.
Original PR description
In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid…
In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path. Steps to reproduce: ------------------- * Enable POS Restaurant with l10n_de Fiskaly * Create a table order (e.g. 3 meals + 3 drinks) * Open Split Bill, move 1 meal + 1 drink, and pay * From Orders tab, open the remaining parent order and repeat split + pay * Reopen the parent order from Orders tab > Observation: The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab. Why the fix: ------------ The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order. The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility. opw-6175880 Forward-Port-Of: odoo/enterprise#117206
This update corrects a test in the Mexican electronic invoicing module so it works whether the accounting app is installed or not. It prevents false test failures caused by a payment changing from “paid” to “in payment” in certain setups.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
This fix prevents the AI assistant from asking the user twice when creating project tasks. It now checks that all required fields are available before confirming the action, which avoids repeated previews and accidental duplicate-looking behavior.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596 X-original-commit: c21dcfe8e4a2c399ee25ebeadd408ce303ce2ff9 Forward-Port-Of: odoo/enterprise#122032
Issue: The `test_overtime_ruleset_flow` tour test was failing because the `amount_rate` field could not be found. Reason: - Couldn't find the amount_rate field as it was located in the Payroll tab and the tour did not navigate to that tab before interacting with the field. - The tour also used some selectors and values that were no longer valid, causing some steps to fail. Fix: - Open the Payroll tab before interacting with the `amount_rate` field. - Set the overtime leave request dur
Original PR description
Issue: The `test_overtime_ruleset_flow` tour test was failing because the `amount_rate` field could not be found. Reason: - Couldn't find the amount_rate field as it was located in the Payroll tab and the tour did not navigate to that tab before interacting with the field. - The tour also used some selectors and values that were no longer valid, causing some steps to fail. Fix: - Open the Payroll tab before interacting with the `amount_rate` field. - Set the overtime leave request duration type to "Custom Hours". - Replace the unavailable "Salary-exempt" employee type with "Employee". - Use the checkbox input selector to interact with the attendance_based field. - Explicitly open the dropdown before clicking on `action_continue` button. - Remove the unnecessary final `action_continue` step.
The Knowledge setup tour has been updated to use the Add button when confirming property changes. This avoids losing recent edits by accidentally clicking outside the popover, making the guided setup more reliable.
Original PR description
Previously, the knowledge_properties_tour used to click outside the property definition popover to save changes. This now discards recent changes, so the tour explicitly clicks the add button instead.
The Belgian payroll process now delays Dimona OUT notifications for employees with code 495 until a departure reason has been entered. This avoids sending an end-of-employment notice too early and reduces manual corrections in the Dimona portal.
Original PR description
This commit will prevent the automatic sending of Dimona OUT notifications upon contract end date changes unless a departure reason is specified for employees with code 495. Why: Currently, the system triggers a Dimona OUT transmission immediately when a contract end date is modified. Now employees with the code 495 and requiring the 'Departure Reason' to be set ensures that the legal notification is only sent when a factual termination of employment has been confirmed, reducing the need for manual corrections in the Dimona portal. What: - Modified the trigger logic for Dimona OUT generation in the Belgian payroll module. - Added a conditional check for the employee code (495). task-6127189
Code cleanup and technical improvements
The way conversation threads are calculated in the chatter has been refactored. This helps keep message history organized more reliably and prepares the feature for smoother future improvements.
This change updates how certain background services are started so they begin automatically when the app is created. It simplifies startup and reduces the risk of services being initialized too late, improving reliability for affected areas.
Original PR description
This commit introduces a new plugin which starts the legacy services. Before this plugin, we needed to start the services after the app creation but now, this is done during the creation.
This change updates a small set of interface templates to use the newer Owl data-binding syntax. It helps keep the product compatible with the latest framework version and reduces maintenance risk, without changing business behavior.
Original PR description
* = ['event_iot'] As part of the migration from `owl 2` to `owl 3`, this commit replaces uses of `t-custom-model` with `t-model` or `t-model.proxy`.