Daily updates from Odoo
Thursday, April 30, 2026
265 changes
30 changes
Enhancements to existing features
This update strengthens the security of the AI website editor by rigorously sanitizing HTML and CSS generated by the AI. It validates actions, removes potentially harmful code, and ensures consistent styling, preventing unexpected website behavior and improving overall stability. This protects the Odoo Enterprise platform from potential vulnerabilities.
Original PR description
Following [commit] introducing the AI website editor tool, we would like to sanitize the output AI provides. We first check that the actions we received are valid, and then we sanitize the html content, before it's sent to the frontend, where it will be sanitized as well. We also validate css and check for potentially malicious patterns, and then compile it to see if there aren't any errors, so it doesn't break our styles. [commit]: https://github.com/odoo/enterprise/commit/2f69f868e22173b12d51067f0bf3b5d4dc27228f task-6143725
Resolved issues and error corrections
This update reduces excessive spacing within the Odoo dashboard side panel, making it easier for users to navigate and view information. The changes refine the layout by adjusting spacing and padding, improving the overall visual clarity and user experience. This is a minor fix to enhance usability.
Original PR description
## Description: The dashboard side panel had too much vertical spacing between the fold button, dashboard sections, and dashboard entries. Reduce the top and section spacing by one Bootstrap step, and use smaller vertical padding on dashboard entries while keeping their vertical margin for readability. Task: [6138870](https://www.odoo.com/odoo/project/2328/tasks/6138870) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a calculation error in the 2033D-2 report for French tax filings. Specifically, it ensures that the total amounts are accurately aggregated, including those generated by dynamic line items. This resolves a discrepancy that could have impacted reported tax figures.
Original PR description
Fixed an issue where the total aggregation for line I-C in the 2033D-2 report didn't add the amount of dynamic lines. no task id
This update enhances the visual clarity of form fields by ensuring consistent styling for required, readonly, invalid, and focused states. The changes prioritize clear indication of the active field and improve overall usability. This ensures users can easily identify and interact with the correct fields within the application.
Original PR description
Before this commit, the focus style wasn't applied on a required field. We now have improved consistency across field states and their visual design. Here’s how to visually distinguish each field state: **Required**: the border is more prominent **Readonly**: the label is greyed out (as well as the background color) **Invalid**: the background color is red **Focused**: the border color is green We no longer want to change the label color for simplicity. For example, if you see a thicker green border with a greyed-out background, it means the field is **focused**, **readonly**, and **required**. Note: the "invalid" style is removed when the field receives focus. We chose not to support this combination. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a formatting issue in the e-waybill document date field. Previously, the date displayed included the time, which is not the required format. This change ensures consistent and accurate date representation for e-waybill documents.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update resolves an issue where pressing 'Enter' within the emoji suggestion list in the discuss HTML composer would unexpectedly send a message. The fix prevents this behavior, ensuring users can now properly manage their messages without unintended submissions when the emoji picker is open.
Original PR description
In discuss html composer, when emoji suggestion list is open, pressing enter sends the message. This commit fixes this issue by preventing the default action of the enter key when the emoji suggestion list is open. task-6173045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261965
This update resolves an issue where generating timesheets would produce errors when a previously employed employee was archived and a related holiday was still active. The fix prevents timesheet generation from considering time off requests for archived employees, ensuring accurate timesheet calculations. This improves data integrity and prevents potential reporting discrepancies.
Original PR description
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should…
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should affect the timesheets). 2. Create a new public holiday (global time off) that overlaps with Employee A’s time off. 3. Archive Employee A. 4. Delete the public holiday created in step 2. 5. An error related to timesheet generation appears. ## Expected Behavior: - The public holiday / global time off should be deleted without any error. # Desired behavior after PR is merged: ## Fix (Implemented): When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees. ## Alternative Fix (Not Implemented): Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved. ## Version: This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0 but didn't directly test ## Task: [5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261909 Forward-Port-Of: odoo/odoo#244203
This update resolves a technical issue where an incorrect import statement was present in the core driver for our Point of Sale IoT integration. This fix ensures the driver functions correctly, preventing potential disruptions to the system's ability to process data from IoT devices. The change is a routine bug fix.
Original PR description
This PR fixes the wrong import in adam_scale_driver.py opw-6173563 Forward-Port-Of: odoo/enterprise#115625
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, ensuring a more precise representation of sales transactions, especially when cash payments are involved. This improves reporting accuracy and provides a clearer picture of financial data.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261884 Forward-Port-Of: odoo/odoo#254401
This update fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to the stock moves, preventing accurate tracking of origin. The change ensures byproducts added through the MO are properly associated with stock movements, resolving a discrepancy in location data. This improves the reliability of production tracking.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582 Forward-Port-Of: odoo/enterprise#110122
This update ensures that survey invitations are sent in the recipient's preferred language, regardless of whether they are part of a mixed-language group. Previously, invitations were consistently sent in English, even when recipients had set their language preference to Dutch or other languages. This change improves the user experience and avoids confusion.
Original PR description
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install…
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install the "Surveys" module and activate a second language (e.g., Dutch). 2. Create a survey and ensure its invitation template has translations for both languages. 3. Create two contacts: one with English as their language and another with Dutch. 4. On the survey, click "Share" and add both contacts as recipients. 5. Send the invitations. 6. The contact with Dutch preferred language receives the email in English. ### Cause By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one. opw-5868581 Forward-Port-Of: odoo/odoo#260028 Forward-Port-Of: odoo/odoo#246778
This update ensures that missing payslip alerts are triggered only when the payroll closing date has passed. This prevents unnecessary notifications for payslips that are already outdated, streamlining payroll reporting and reducing potential user confusion. This change improves the accuracy and efficiency of our payroll processing system.
Original PR description
In this commit, missing payslip in a payrun issue will be raised only if the payroll closing date is due (old conditions remains). task-6008297 Forward-Port-Of: odoo/enterprise#112182
This update resolves a technical issue that prevented demo flows from running correctly when new Peppol and Nemhandel response data was added. The fix ensures demo mode functions smoothly by updating the mock data, preventing errors and improving the demo experience.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
This update fixes an issue where the ewallet discount was incorrectly included in delivery calculations. The change adjusts the pricing logic to accurately exclude ewallet amounts from delivery costs, ensuring consistent and accurate shipping charges for customers. This improves the overall customer experience and billing accuracy.
Original PR description
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99…
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99 => delivery price = 50 3- Create a eWallet with balance = 200. 4- Create a SO add a line with product. Set the SOL unit amount to 100. 5- Click on `add a shipping`. Add the created delivery method. 6- As you see, the delivery amount is correctly calculated. 7- Now apply the eWallet using `reward` button. 8. Update the shipping cost. The shipping cost is 30, which is not expected. Cause: --- In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount. However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`. Fix: --- We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards. opw-6124209 Forward-Port-Of: odoo/odoo#260134
This update corrects a minor issue where the 'delete' option was missing from the user interface for certain returns and checks reports. This was caused by lingering references to the previous default 'new' state value. Removing this value improved database efficiency.
Original PR description
In odoo/enterprise#103149, the default value for the state of the returns and checks were removed to use False by default to reduce space in the database. However, a few reference were left using the default value which was 'new'. To reproduce (using working files): - Create a working files - Open the menu of the working file in the working files kanban view - The option delete isn't present
This update resolves an issue where toggling attendees in the calendar filter section was not working correctly. The fix corrects a technical error related to how the calendar filter ID was being accessed, ensuring that attendees are toggled as intended. This improves the user experience when managing calendar events.
Original PR description
Steps to reproduce ==================== - Open the calendar. - Try to toggle any attendees through the label. - By default, it will toggle the first attendee. Technical =========== Recently, here https://github.com/odoo/odoo/pull/253294, we started using `this` when accessing a component properties, but here in our case, `filterId` is not a component property; it is declared using `t-set` in the parent template, and using it like `this.filterId` leads to undefined, which leads to the same ID for all the inputs, which was causing the issue. Task-6124794
This update resolves an issue where certain expense accounts were incorrectly included in default reporting filters. Specifically, accounts related to exchange differences and early payment discounts were added. This ensures that financial reports accurately reflect all expense transactions, improving data accuracy and reporting reliability.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375 Forward-Port-Of: odoo/odoo#259583
This update fixes an error in the Datev general ledger export that resulted in incorrect tax rates. The issue stemmed from how multiple tax repartition lines were handled, leading to amounts being replaced instead of added. This ensures accurate tax reporting for Datev customers.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue that prevented users from switching between company types (Companies vs. Associations & Foundations) for their Belgian accounting setup. The fix clears references to old accounts within cash rounding configurations, allowing the localization switch to complete without errors. This ensures seamless switching between fiscal localization types.
Original PR description
### Issue before this commit: Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The…
### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.
### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?
### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67
### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.
opw-6050537
Forward-Port-Of: odoo/odoo#260145This update fixes a previous removal of a payslip line edition wizard, now replaced with an inline computation method. This change streamlines the payroll calculation process, ensuring more accurate and immediate pay results for employees. It addresses a previous issue related to the wizard's functionality.
Original PR description
We replace the previously removed payslip line edition wizard with inline payslip computation Forward-Port-Of: odoo/enterprise#112972
This update corrects a display issue on rental product pages when 'continue selling' is enabled. Previously, the available quantity was incorrectly shown as 2 regardless of the rental period. The fix ensures the quantity accurately reflects the remaining availability based on the selected rental timeframe, improving the customer experience.
Original PR description
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product…
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product tracked in stock with a quantity of 5 - Enable "continue selling" and "show available quantity below 10" - Go to the ecommerce page of this product - Rent 3 units for a given period, confirm and pay - Return to the ecommerce product page -> Whatever the selected renting period, the displayed quantity is always 2 **Cause**: The website displays `free_qty`: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15 `free_qty` is computed in: https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36 which leads to: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10 and ultimately relies on: https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213 This computation does not take the selected renting period into account. There is a period-aware computation here: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1 but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled). opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#108493 Forward-Port-Of: odoo/enterprise#103333
This update resolves an issue where a website tour wasn't functioning correctly due to an outdated assumption about the search bar size. A new fix ensures the tour accurately detects scrolling behavior, preventing interruptions and improving the overall user experience. This addresses a technical detail related to website performance.
Original PR description
__Problem__ odoo/odoo@9394e17a added a step to this tour that assumes the website search bar is small. However, this search bar was smaller than it should have been because of an issue fixed by the enterprise PR (odoo/enterprise#115694). __Fix__ Remove the step added in odoo/odoo@9394e17a runbot-242449
This update resolves a problem where the size of the product search bar was incorrectly set, causing a tour to fail in the SaaS version of Odoo. The fix ensures the size attribute is only applied to the product search bar, preventing issues with other website search elements.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449 Forward-Port-Of: odoo/enterprise#115433
This update resolves an issue impacting the accuracy of real margin reports within the Odoo system. The changes adjust the report's structure to ensure correct aggregation of data, leading to more reliable margin calculations. This improves the financial reporting capabilities for sales teams.
Original PR description
Adjust the real margins pivot report structure --- task-6168613
This update fixes an issue preventing users from inserting snippets within the Odoo Forum's help pages. The system was incorrectly filtering dropzones, blocking snippet group clicks. The fix allows snippet group clicks, ensuring users can easily add snippets to the forum, improving usability.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#260400 Forward-Port-Of: odoo/odoo#256078
This update fixes an issue where the system incorrectly generated purchase orders when stock was sufficient to fulfill manufacturing orders. The change ensures that purchase orders are only created when there's a genuine stock shortage, streamlining the procurement process and reducing unnecessary costs. This improvement focuses on the 'mts_else_mto' move type.
Original PR description
Steps to reproduce: - Create a product P1 with a BoM containing component C1 - Set C1 route to MTO + Buy: - add any vendor - Have 10 units of C1 in stock - Confirm a Manufacturing Order for 2 units…
Steps to reproduce:
- Create a product P1 with a BoM containing component C1
- Set C1 route to MTO + Buy:
- add any vendor
- Have 10 units of C1 in stock
- Confirm a Manufacturing Order for 2 units of P1
- The MO confirmation triggers the move for C1, which gets assigned from stock
- Increase the quantity_producing on the MO
- This updates product_uom_qty on the move and calls _run_procurement
Expected behavior:
- No Purchase Order should be created since stock covers the demand
Current behavior:
- A Purchase Order is created even though stock is sufficient
- In case of partial stock, the full procurement_qty is used instead of the uncovered delta
Fix:
- Track mts_else_mto moves separately before calling _action_assign()
- After _action_assign(), subtract the newly covered quantity (move.quantity - old_qty)
from the procurement_qty before running the stock rule
- Skip the procurement entirely if the adjusted qty <= 0
opw-6042283
Forward-Port-Of: odoo/odoo#261538
Forward-Port-Of: odoo/odoo#258871This update corrects a bug where timesheets were incorrectly assigned to the wrong employee when created through the timesheet systray. The issue stemmed from a formatting error in how user IDs were passed, now ensuring timesheets are accurately linked to the correct user. This prevents data discrepancies and ensures accurate time tracking.
Original PR description
# Steps to reproduce: - Open a billable project and a task - Open the timesheet systray - Create timesheet # Current behaviour The timesheet is recorded for another employee. # Root cause This happens because the `user_id` passed to the record update was lacking the right `[id, name]` format. As a consequence, the timesheet was created without a user (`False`), thereby linking it to another employee than the current user. task-6169253 Forward-Port-Of: odoo/enterprise#115420
This update resolves a bug that prevented users without project access from correctly linking project values to sales quotations or rental orders. The change uses a temporary access method to ensure project information is included, allowing for accurate order creation even without direct project permissions. This improves the functionality of the sales and rental processes.
Original PR description
Before this commit if a lead is converted into either of sales quotation or rental quotation, if the user doesnt have access to project but has access to sales and CRM, it throws a error to read the project. Rationale: - Even when there is no access to project, it is neccesary for the project value to be linked in the suqsequent quotation or rental order. So using a sudo to to read the value and assigning it as a default value is neccessary.
This update fixes a potential timeout issue in the website builder when users upload multiple images simultaneously. Previously, a 10-second timeout would trigger errors, but this change allows builder actions to remain active until image uploads are complete, improving the user experience and preventing frustrating errors.
Original PR description
Steps to reproduce: 1.Drop a gallery slider 2.Add multiple images at the same time 3.Wait more than 10 seconds before finalizing uploads 4.A toaster error is displayed Before this change: Builder actions relying `this.dependencies.media.openMediaDialog` inside their `apply` method could time out while the media dialog was still open. This was due to OperationPlugin enforcing a default 10s timeout, even when the user was still interacting with the dialog (e.g., selecting or uploading images).(see PR[1]) After this change: The timeout is disabled by using `this.canTimeout = false` for actions that open the media dialog using apply method, ensuring they remain active until the media dialog completes and preventing false timeout errors. [1]:https://github.com/odoo/odoo/pull/233079 task-6131455
This update fixes an issue impacting how sales advantages are calculated. Specifically, discounts are now excluded from these calculations, ensuring more accurate and reliable advantage reporting. This change improves the accuracy of sales performance analysis.
Original PR description
for the computation of advantages. Only exclude rewards of type discount for the advantage calculation. opw-6159239
18 changes
Resolved issues and error corrections
This update resolves an issue where users without HR access rights couldn't apply filters in the Time Off search functionality. The fix prevents a technical error related to a specific field not present in the public employee model, ensuring all users can effectively filter their time off data. This improves usability for a wider range of users.
Original PR description
More general fix for https://github.com/odoo/enterprise/pull/113973 or https://github.com/odoo/enterprise/pull/115478 Steps to reproduce: - Log using a user with no HR access rights (e.g. Marc Demo) - Go to Time Off > Overview - Remove all filters - Add a new custom filter on "Department is equal to ..." or "Job is equal to ..." Instead of the filter being applied, a traceback occurs. This originates from the fact that in _get_gantt_data_groupby_employee, the employee domain is mapped to address the field current_version_id. However, if a user has no HR rights, the search will be redirected to the employee public model, on which that field isn't defined. This commit adapts the domain in search_fetch to avoid current_version_id being present in it. No related task Co-authored by @BeBel42
This update adds a new test case to the HR holiday Gantt chart functionality. It addresses a previous issue related to public employee access, ensuring that authorized users can correctly view and manage holiday schedules. This enhancement improves the reliability and security of the HR module.
Original PR description
Add a test for the issue resolved in https://github.com/odoo/odoo/pull/261937 No related task
A bug was causing timesheets to be incorrectly linked to another employee when created through the timesheet systray. This issue stemmed from a formatting error in how user IDs were passed during the timesheet creation process. This fix ensures timesheets are accurately recorded for the correct employee.
Original PR description
# Steps to reproduce: - Open a billable project and a task - Open the timesheet systray - Create timesheet # Current behaviour The timesheet is recorded for another employee. # Root cause This happens because the `user_id` passed to the record update was lacking the right `[id, name]` format. As a consequence, the timesheet was created without a user (`False`), thereby linking it to another employee than the current user. task-6169253
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, aligning the displayed total with actual payment amounts. This ensures greater accuracy and transparency in sales reporting.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261884 Forward-Port-Of: odoo/odoo#254401
This update resolves an issue where 'Other Expense' accounts were incorrectly included in default reporting filters. By adding specific account types (exchange differences, discounts) to the filter, the system now accurately categorizes expenses, leading to more precise financial reporting. This improves the reliability of financial data.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375 Forward-Port-Of: odoo/odoo#259583
This update resolves a problem where the size of the product search bar was incorrectly set, causing issues with a website tour. The fix ensures the search bar's size is only adjusted when the ‘website_sale_renting’ module is installed, preventing disruptions to other website features.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449 Forward-Port-Of: odoo/enterprise#115433
This update fixes a bug where the Odoo app could become unresponsive if a feature was repeatedly accessed. The change prevents the creation of duplicate promises, ensuring that the app remains responsive even with frequent interactions. This improves overall app stability and user experience.
Original PR description
Whenever `isOnMainTab` is called, it creates and returns a new promise that will be resolved once the shared worker sends its response. However, if `isOnMainTab` is called twice in quick succession, before the shared worker answers, only the last promise is resolved, leaving the first one hanging forever. This commit fixes the issue by not recreating a promise if there is already one pending. Forward-Port-Of: odoo/odoo#262021
This update fixes an issue where the Datev export CSV incorrectly reported tax rates when a vendor bill used multiple tax repartition lines. The fix ensures that all tax amounts are accurately included in the CSV, improving the reliability of financial data exports to Datev.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue preventing users from switching between company localization types (Companies vs. Associations & Foundations) for Belgian businesses. The fix clears references to old accounts within cash rounding settings, allowing the localization switch to complete without errors. This ensures accurate reporting and functionality for Belgian clients.
Original PR description
### Issue before this commit: Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The…
### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.
### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?
### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67
### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.
opw-6050537
Forward-Port-Of: odoo/odoo#260145This update fixes an issue preventing users from deleting time off allocations that were created after a payslip had been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off allocations can be deleted regardless of when they were created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#115545
Forward-Port-Of: odoo/enterprise#114895This update corrects a formatting issue that prevented receipts printed on specific 180dpi receipt printers (like the TM-T88V) from displaying correctly. The previous setting caused a gap in the printed output, now fixed to align with standard printer specifications. This ensures accurate receipt printing for our retail partners.
Original PR description
Printers with a 180dpi (so 180 dot per 25.4mm) (like the TM-T88V) have a standard print width of 72mm on an 80mm roll. Which gives 72/25.4*180 = 510.23 dots / pixels So, the manufactures usually defines it as 512 dot grid. Right now, the width is set to 576px, causing the last 65 pixels to not be printed. opw-6087544 opw-6125418
This update ensures the session cookie is consistently set when using Odoo.sh, preventing frequent disconnections and improving the reliability of WebSocket connections. This change enhances the overall user experience by maintaining a stable connection, regardless of the database configuration.
Original PR description
Before this commit, the session cookie was only being set when the `db_name` is defined in `odoo.conf`. This was because it was used to identify the correct DB in a multi-DB setup. However, having the session cookie set also prevents frequent disconnects on every message when connected to an odoo.sh DB. After this commit, the session cookie is always set even when no `db_name` is defined. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing some tests from running. The changes ensure that nested brackets and escaped characters are handled properly, improving the reliability of test execution. This resolves a technical detail that ensures consistent test results.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#262101 Forward-Port-Of: odoo/odoo#261516
This update prevents the 'Start a Poll' action from appearing in the composer when users are editing an existing message. Previously, this action was misleading and unnecessary, as polls are intended for new message creation. This change improves the user experience by aligning the action's availability with its intended use.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the composer, the 'Start a poll' action is displayed among the available options. Starting a poll while editing an existing message makes no sense, as polling is only meaningful when composing a new message. **Current behavior before PR:** ---------------------------------------------- - 'Start a poll' action appears in the composer 'More Actions' menu even when the user is editing an existing message - Clicking it while in edit mode opens the poll creation dialog, which is misleading and unintended behavior **Desired behavior after PR is merged:** ---------------------------------------------- - 'Start a poll' action is hidden from the 'More Actions' menu when the composer is in edit mode - The action continues to appear as expected when composing a new message in a channel or group conversation Task-6171541 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261961
This update resolves a bug where editing previously edited messages caused unexpected behavior like selecting the "(edited)" label and losing content after saving. The fix removes the "(edited)" span from the editor's content, ensuring correct editing functionality and a smoother user experience.
Original PR description
When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body…
When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer. This caused two issues: - CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted. - CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children. Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct. Also align the mock server with the real server behavior: - Place the span *inside* the last `div`/`p` element instead of after it. Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label. task-6172161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where combo products weren't consistently ordered according to their choices, leading to incorrect item sequences in sales orders. The fix ensures combo items are always displayed in the intended order defined by the combo selection, improving the accuracy and reliability of the point-of-sale system.
Original PR description
When creating a combo product, its items were not ordered according to the combo choice sequence, and extra items were always appended at the end. As a result, combo items could appear in the wrong order. This fix ensures that, when computing combo prices and merging combo items with extra items before creating the order lines, the correct sequence is derived from the parent product. All items are then sorted based on this sequence so that they consistently follow the order defined by the combo choices. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6064642 Forward-Port-Of: odoo/odoo#261633 Forward-Port-Of: odoo/odoo#255596
This update resolves a performance issue where changing a product's lot/serial in a stock picking could trigger slow requests due to Odoo fetching all stock quantities without respecting a defined limit. The fix ensures that the system respects the limit during these onchange calls, resulting in significantly faster response times.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In…
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#261904 Forward-Port-Of: odoo/odoo#259983
This update addresses a technical detail by removing the Tailscale IP address from the IoT box status screen. This change improves the clarity and accuracy of the information displayed to users, streamlining the status reporting process. It ensures that only relevant network interfaces are shown.
Original PR description
This PR removes tailscale ip address from iot box status screen. ``` >>> netifaces.interfaces() ['lo', 'eth0', 'wlan0', 'tailscale0'] ``` The 'tailscale0' interface will now be ignored Forward-Port-Of: odoo/odoo#242796
12 changes
New functionality added to Odoo
This update introduces a new 'tare' mode specifically for Toledo scales within the Odoo system. This allows users to accurately measure items by resetting the scale to zero before each measurement, improving data precision for inventory tracking. This enhancement supports a key feature for businesses utilizing Toledo scales.
Original PR description
This PR adds the tare mode for Toledo scales. Related PR: https://github.com/odoo/odoo/pull/253328
Resolved issues and error corrections
This update resolves a visual bug where the "Add to Cart" button appeared squeezed on product pages in edit mode. Specifically, when the Image Area is set to 33 and the purchase style is Large, the button's size was incorrect. The fix ensures the button displays its intended size across all product page layouts.
Original PR description
This code fixes a bug related to the size of the “Add to Cart” button. To reproduce the bug, you need to be on a product page in edit mode. In this mode, you must set the Image Area to 33 and the purchase style to Large. You will see that the “Add to Cart” button is squeezed. The bug occurs because, in edit mode, a new span container is added around the button to indicate that it can be edited. The fix simply adds CSS on top of this container. find-when-working-on-task-6147939 **Before** <img width="1918" height="552" alt="before" src="https://github.com/user-attachments/assets/f46c78ff-b095-4738-821b-ff52272f160d" /> **After** <img width="1913" height="1054" alt="after" src="https://github.com/user-attachments/assets/ef38a68f-acbb-439b-883d-8e3ee45c5d4a" />
This update corrects a layout problem in the Odoo spreadsheet component. After a recent code change, the spreadsheet was displaying with text flowing from right to left. This fix ensures the spreadsheet displays correctly for users in both left-to-right and right-to-left language environments.
Original PR description
When we switched from scss to a css file in the o_spreadsheet library, we exposed the library style to the automatic convertion of `rtlcss`. This process replaces the explicit `tlr`rules to `rtl`. rtlcss can ignore files/rules with inline instructions but since the library is external to Odoo and is not explicitely aware of `rtlcss`' existence, we add an explicit rule inside Odoo which will not be exposed to `rtlcss` conversion. Task-6170966 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a minor visual issue where icons within thumbnails in the email attachment list were not positioned correctly. The change adjusts the base layout to allow for overrides, ensuring a consistent and professional appearance for users. This improves the overall user experience when viewing attachments.
Original PR description
We modify the base layout to allow a fix of the icon position in an override. Task-5152517 Forward-Port-Of: odoo/odoo#249055
This pull request addresses several minor bugs in the Documents module, primarily related to file uploads and display. Specifically, it fixes issues with scrolling to uploaded files, incorrect icon positioning, and display problems with the 'You' badge under certain conditions. These changes improve the overall usability and reliability of the Documents application.
Original PR description
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file…
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file in that folder The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel. We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel. [FIX] documents: fix icon position in thumbnail How to reproduce: - install documents - open the chatter of a document - click on log a note, and upload a file The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border). We fix here the position the icon/button. [FIX] documents: fix "you" badge layout How to reproduce: - install documents - change the name of Mitchell Admin to a very long name - open the share panel owned by Mitchell Admin The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct). We fix here the layout of the badge in such configuration. Task-5152517 Forward-Port-Of: odoo/enterprise#107686
This update fixes a technical issue where a promise created by the Odoo application could hang indefinitely if called multiple times quickly. The fix prevents the creation of new promises, ensuring that all requests are handled correctly and preventing performance problems. This improves overall application stability.
Original PR description
Whenever `isOnMainTab` is called, it creates and returns a new promise that will be resolved once the shared worker sends its response. However, if `isOnMainTab` is called twice in quick succession, before the shared worker answers, only the last promise is resolved, leaving the first one hanging forever. This commit fixes the issue by not recreating a promise if there is already one pending. Forward-Port-Of: odoo/odoo#262021
This update adjusts the checksum calculation for the IoT scale certification module within Odoo Enterprise. This change aligns with recent updates to the underlying IoT drivers, ensuring data integrity and accuracy for certified IoT devices. It’s a routine maintenance update to maintain the module’s functionality.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This change ensures all printers, including those connected via IoT, are properly loaded and functional within the PoS environment.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable.
This update resolves an issue causing FEC imports to crash for French association companies in Guadeloupe and Martinique. The fix prevents the import process from incorrectly attempting to link asset models, which were unexpectedly included in the account templates. This ensures smoother and more reliable FEC imports for our French users.
Original PR description
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account…
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account templates. Since 19.1, those templates may include asset_model_ids, which makes the import try to resolve asset XML IDs that do not exist for that company setup. Steps to reproduce: 1. Create a new company with Guadeloupe or Martinique for country. 2. Set the French associations chart of accounts on it. 3. Go to Accounting -> Configuration -> Chart of Accounts. 4. Import the FEC file linked on the ticket. 5. Import fails with traceback. Desired behavior after fix: FEC import should keep the existing template completion behavior, but it should not copy asset_model_ids onto imported accounts. Importing an FEC for French association companies in Guadeloupe or Martinique should therefore no longer crash because of unrelated asset model references. Ticket [link](https://www.odoo.com/odoo/project.task/6053048) opw-6053048
This update fixes a critical issue where refunds for gift cards and e-wallets could allow their reuse, leading to incorrect accounting and potential fraud. It now prevents refunds, and also ensures that products associated with multiple loyalty programs are correctly separated into distinct order lines. This improves data accuracy and prevents misconfigurations.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#261647 Forward-Port-Of: odoo/odoo#256896
This update corrects a problem that occurred when switching accounting chart templates, specifically when changing from a company to an association localization. The change ensures that old accounting records are properly removed during template updates, preventing errors related to foreign key constraints. This improves stability and prevents disruptions during localization adjustments.
Original PR description
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account"…
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding" DETAIL: Key (id)=(1919) is referenced from table "account_cash_rounding" ``` **Steps to reproduce:** 1) install l10n_be module 2) make a new belgium company 3) go to accounting > configurations 4) change the fiscal localization package to "Belgium- Associations and Foundations" **Cause:** `account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'` **Solution:** Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch. opw-6165374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows support teams to log data from Point of Sale orders processed through the `sync_from_ui` system. A new configuration setting enables this logging, preventing unnecessary data collection and ensuring only relevant information is recorded. The addition of the `pos_reference` field in logs further aids in identifying specific orders during investigations.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261792
4 changes
Resolved issues and error corrections
This update resolves a technical issue that could cause instability in voice message testing. By ensuring asynchronous code waits for the voice player to load, we've eliminated potential race conditions and improved the reliability of our testing process. This contributes to a more stable and dependable Odoo Enterprise experience.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/242411 Community: https://github.com/odoo/odoo/pull/261910 Forward-Port-Of: odoo/enterprise#115587
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it in the main accounting view. Now, users can directly create and edit certificates within the digipoort certificate setting, improving usability.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115628 Forward-Port-Of: odoo/enterprise#114307
This update fixes an issue where the valid date range for ESG emission factors was incorrectly shown. The missing 'always_range' option has been added, ensuring that users now see the accurate and complete date range for these important sustainability metrics. This improves data accuracy and reporting.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#114784
This update resolves an issue where the industry FSM report worksheet wasn't saving correctly in the Enterprise portal, leading to tour failures. The fix ensures the worksheet functions properly, preventing disruptions to users accessing this report.
Original PR description
The worksheet is not auto saving and the worksheet is not rendering properly in portal, which caused the tour to fail. runbot error-242479
7 changes
Resolved issues and error corrections
This update fixes an issue where quantities were incorrectly doubled when settling POS sales orders using the 'Pick then Deliver' warehouse method. The fix ensures accurate lot quantity tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order fulfillment.
Original PR description
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading…
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots. Steps to reproduce: ------------------- * Create a product with Tracking by lots * In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)" * Create a quotation with the product and confirm it * Validate the delivery * In POS, settle the sale order from Quotation/Order * When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes > Observation: Quantity doubled. Why the fix: ------------ read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice. We now use move lines from exactly one picking and filter by sale_line_id. opw-6001585 Forward-Port-Of: odoo/odoo#261729 Forward-Port-Of: odoo/odoo#253539
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it in the main accounting view. Now, users can directly create and edit digipoort certificates within the accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115628 Forward-Port-Of: odoo/enterprise#114307
This update fixes a critical issue where gift cards and e-wallets could be reused after refunds, leading to potential misuse. Now, refunds completely disable the associated card or wallet, preventing fraud and ensuring accurate accounting. Additionally, the system now correctly handles products linked to multiple loyalty programs, allowing for distinct order lines.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#261647 Forward-Port-Of: odoo/odoo#256896
A technical error prevented importing emissions data through the ESG reporting tool. This update restricts imports to manual emissions, resolving the database conflict and ensuring accurate reporting. This change improves the reliability of our ESG data collection process.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587
This update corrects a technical issue preventing accurate stock availability calculations, specifically when using the MRP module. The change removes unnecessary restrictions on user permissions, ensuring the system correctly reflects stock levels across different user sessions (like POS).
Original PR description
Computing qty_available with sudo(False) drops superuser privileges, causing an AccessError on mrp.bom when the mrp module is installed. This happens because _compute_quantities_dict calls _bom_find, which performs an access check on mrp.bom that the current user (e.g. a POS session during online payment processing) may not pass. Removing sudo(False) preserves the calling environment's access rights, which is sufficient and avoids the permission error. opw-5975248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260755 Forward-Port-Of: odoo/odoo#252827
This update optimizes the process of preparing data for workcenter visualizations, resulting in significantly faster performance. By streamlining the check for workorders and pre-calculating resource calendar durations, the system now responds much quicker, especially with large datasets. This improves overall system responsiveness.
Original PR description
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching…
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching the field `order_ids` for all the workcenters. This can be too slow in cases where the workcenters have a lot of workorders and in addition to that there is no need to do this repeatedly for every workcenter. In this commit, I have modified the check by invoking a `search_count` on the workorders before iterating over the recordset and in addition to that I have pre-computed the sum of the duration hours of the attendances related to a `resource_calendar` as multiple workcenters might have the same `resource_calendar` The benchmark done below, was on a database that contained 78 workcenters. | Workorders | Before | After | | :--- | :--- | :--- | | 1380828 | 12s | 0.16s | | 138082 | 1.21s | 0.14s | | 13808 | 0.21s | 0.09s | opw-6040077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256812
This update fixes a problem where users without sufficient accounting permissions would encounter errors when retrieving information about components within purchase orders created by others. The change ensures that users with appropriate timesheet access can correctly access and analyze component data, improving data accuracy and workflow efficiency. This resolves a previous access restriction.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- *…
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989 Forward-Port-Of: odoo/odoo#261588 Forward-Port-Of: odoo/odoo#255824
13 changes
New functionality added to Odoo
This update allows users to send purchase documents in bulk, streamlining the process for self-billing transactions. Previously, this functionality was unavailable. Now, the bulk sending button is enabled only when the purchase journal is configured for self-billing, ensuring accurate record-keeping.
Original PR description
Before this commit, the button to send in bulk from the purchase list view was disabled. With this commit, we add the possibility to send them in bulk, but only when the journal has been set as self-billing. Task-6075282
This update adds support for a key Belgian tax exemption for Small and Medium Enterprises (SMEs) related to withholding tax on payroll. It introduces a new company field to determine eligibility and adjusts calculations on the 274.XX tax sheets. This ensures compliance with Belgian regulations and improves reporting accuracy for SME clients.
Original PR description
Add support for the Belgian Small/Medium Enterprise withholding tax exemption (dispense de précompte professionnel PME) on the 274.XX sheets. - Add 'Small/Middle Sized' boolean field on company for eligibility - Add SME exemption rate rule parameter (0.12% for 2026) - Compute SME taxable amount and exempted amount on 274.XX sheets - Display SME exemption tab in form view when applicable - Include SME exemption page in PDF report - Add SME exemption worksheet in XLS export task-5428830
Enhancements to existing features
This update enhances the 'Sign' module's ability to display non-Latin fonts like Arabic and Bengali within PDF documents. Previously, font customization was limited; now, users can define multiple fonts within a system parameter, offering greater flexibility for diverse document layouts and languages without requiring manual parameter changes.
Original PR description
Up until now, by specifying a ttf font file in the use_custom_font system parameter, one could allow the display of different fonts or alphabets in the pdf generation in sign. With this PR we want to…
Up until now, by specifying a ttf font file in the use_custom_font system parameter, one could allow the display of different fonts or alphabets in the pdf generation in sign. With this PR we want to explore the possibility of defining multiple fonts, which would allow both for the use of different alphabets in different documents (without always having to go modify the system parameters) and multiple alphabets in the same document, in different text boxes/selection menus. The way it works is that a variable called sign.use_custom_font needs to be created in the system parameters and populated with a list of ttf files, separated by a ; For example, if one wants to add the fonts for Arabic and Bengali which are in files named NotoSansArabic-Regular.ttf and NotoSansBengali-Regular.ttf, the value of the newly created system variable should be: NotoSansArabic-Regular;NotoSansBengali-Regular The code should check all the usual folders for fonts. If a file is not found it is ignored and a warning is logged. At document rendering time, if an appropriate font is not found for a text to be displayed in a Text, TextArea or Selection field then the system defaults to Helvetica (latin alphabet) and most different-alphabet symbols are rendered as black boxes. This is intended. Task: 4731754
This update adjusts the popover that appears when setting time off requests in Payroll > Time Offs. Previously, the popover had a fixed width, causing issues with button placement. This change creates a dynamic popover that adapts to its content, ensuring a cleaner and more user-friendly experience.
Original PR description
When going into Payroll > Time Offs > Clicking on a cell > Clicking Set, the popover that appears is just the default MultiCreatePopover, which has a maximum width of 276px. In some cases, many buttons appear besides duration or in the footer, so we want the popover width to be dinamical instead. To do this, we create a new Popover that extends the original. The object is the same, but this way we can override the template and add mw-100 to the class of the body, so that the popover will adjust to its contents. Task: 5990385
This update simplifies the names of payroll structures used in the Belgian localization for Odoo Enterprise. The change reduces the length of these names, improving readability and maintainability within the system. This is an internal improvement that doesn't impact users directly.
Original PR description
Change the payroll structure names for the Belgian locatization to be shorter. task-6159009
This update replaces an outdated technology (Deferred) with a modern, more efficient approach (Promise.withResolvers) within the Odoo Live Chat module. This change enhances the overall performance and stability of the live chat feature, ensuring a smoother user experience.
Original PR description
Deferred is deprecated, Promise.withResolvers is now the preferred API. Part of [task-5262203](https://www.odoo.com/odoo/1519/tasks/5262203) Community: https://github.com/odoo/odoo/pull/262207
Resolved issues and error corrections
This update fixes an issue where outstanding amounts weren't accurately calculated after a refund was processed within a point-of-sale transaction. Previously, only the original order total was considered. Now, refund orders are included, ensuring the correct net due amount is displayed and settled, improving financial accuracy.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#114143 Forward-Port-Of: odoo/enterprise#107883
This update enhances the Odoo Enterprise sign process to be more user-friendly on touch screen devices. The changes address usability issues and optimize the interface for touch interactions, making it easier for users to complete sign requests. Unrelated changes from another branch have been removed.
Original PR description
Sign is not well optimized for touch screen users, fields can't be placed and other operations are also hard. This PR is made to fix that. Task: 5001223
This update streamlines the calculation of payslips by restoring a previously removed wizard and implementing inline computation. This change enhances the accuracy and efficiency of payroll processing, ensuring employees receive correct payments. It addresses a previous removal that impacted the functionality of the payroll system.
Original PR description
We replace the previously removed payslip line edition wizard with inline payslip computation Forward-Port-Of: odoo/enterprise#112972
This update corrects a technical issue that prevented payruns from being created correctly in the Hong Kong localization. The fix involved renaming a missing function within the HR payroll module, restoring normal payrun functionality. This ensures accurate payroll processing for Hong Kong users.
Original PR description
In the big commit adding eMPF to the hk localization, a function was miss named and was causing an error when trying to create a payrun. In this commit we fix the naming of the function and everything goes back to working. Task: 5960503
This update fixes an issue where payrun creation incorrectly displayed the current month, including today's date. The change adds a necessary keyword to ensure the payrun period accurately reflects the intended timeframe, improving the accuracy of payroll reporting.
Original PR description
During the step that shows leaves in payrun creation, the period including today's date was always shown (i.e. if month, the current month). This was because of a missing keyword in the context which was making the logic fallback on the default. We add the keyword and everything goes back to working. Task: 5961725
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts when a vendor bill had multiple tax repartition lines. The fix ensures that all tax amounts are accurately included in the export, improving the reliability of financial reporting for Datev.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update ensures that the expiration date from a GS1 barcode on a packaging is correctly applied when creating a new lot in Odoo. Previously, the system didn't recognize the due date on the packaging, leading to incorrect lot expiration settings. This fix improves inventory accuracy and reduces the risk of expired stock.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#1124903 changes
New functionality added to Odoo
This update makes the Preparation Display app readily available on the Odoo dashboard for Point of Sale (PoS) users. This enhancement simplifies access to key preparation information, streamlining the PoS workflow and improving operational efficiency. It addresses a previous request to improve user access to this important functionality.
Original PR description
This commit makes the Preparation Display app accessible from the Odoo dashboard for PoS users. Task-[5980289](https://www.odoo.com/odoo/project/1737/tasks/5980289) Related PRs: - https://github.com/odoo/odoo/pull/251391
Enhancements to existing features
This update expands the 'Reload AI Data' button on invoices to support importing bills from Peppol and other e-invoicing formats. This allows users to easily correct mistakes or re-import invoices after deleting lines, improving data accuracy and streamlining the billing process.
Original PR description
When a bill is imported from OCR there is a button called Reload AI Data appears that the user can use to reload the bill, it is useful if the user deleted a line by mistake or for whatever reason wanted to reload the bill, but this button is only supporting OCR at the moment. This commit extends its functionality to support also peppol and other einvoicing formats as well. task-6159853
Resolved issues and error corrections
A recent update to the sign tour caused it to fail. This fix corrects a minor naming inconsistency in the user selection process, ensuring the tour runs smoothly for all users. The change updates a simple text string to resolve the issue.
Original PR description
When running the sign_tour from 19.0 forward, the tour fails because during the selection of the signer we select the child that contains Administrator while the name of the user is Mitchell Admin. Therefore the fix is as easy as modifying Administrator to Admin. Runbot Error: 238784
7 changes
Resolved issues and error corrections
This update ensures correct handling of vendor identification when importing KSeF bills. It now requires the Polish NIP number (without the 'PL' prefix) to be used, aligning with Polish tax regulations for foreign companies operating in Poland. This is crucial for proper KSeF compliance and accurate invoice processing.
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039
This update resolves a technical issue where long descriptions in related image fields caused website errors (502 errors). The fix truncates filenames to prevent exceeding server buffer limits, ensuring images load correctly for users. This improves the overall user experience and prevents potential website downtime.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952
This update resolves an issue where the Swedish EC Sales Report exported to KVR (a key accounting format) displayed decimal values instead of the required integer format. This fix ensures accurate reporting for Swedish businesses, aligning with local tax regulations and improving data integrity.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#114292
This update corrects an issue where barcode-created internal transfers incorrectly displayed zero demand and used the wrong warehouse locations in inventory reports. The fix ensures that scanned quantities accurately reflect demand and that moves are linked to the correct sub-locations, improving inventory accuracy and reporting.
Original PR description
When creating an internal transfer from the Barcode app, stock moves auto-created from scanned lines showed incorrect data in the Moves Analysis list view: - Demand (product_uom_qty) was always 0. -…
When creating an internal transfer from the Barcode app, stock moves auto-created from scanned lines showed incorrect data in the Moves Analysis list view: - Demand (product_uom_qty) was always 0. - Source and destination locations showed the picking's generic header location (e.g. WH/Stock → WH/Stock) instead of the actual sub-locations scanned by the operator. Steps to reproduce: ------------------- * Open the Barcode app and start a new internal transfer. * Add a product from WH/Stock/Shelf to WH/Stock/Shelf2 with qty 8. * Validate the transfer. * Open Inventory > Reporting > Moves Analysis > List View. > Observation: the move shows Demand = 0, From = WH/Stock, To = WH/Stock. Why the fix: ------------ When barcode saves a transfer it writes move_line_ids directly on the picking without pre-existing moves. stock.move.line.create() calls _prepare_stock_move_vals() to auto-create the backing move. Core stock intentionally sets product_uom_qty = 0 for open pickings (so that backorder/procurement logic is not affected), and reads source/dest locations from the picking header rather than from the individual line. For the barcode "scan-first" flow these two defaults are wrong: - The scanned quantity IS the demand; there is no separate planning step. - Sub-location scanning stores the real locations on the line, not on the picking header. _prepare_stock_move_vals is overridden in stock_barcode to set product_uom_qty = self.quantity and propagate the line's locations to the move. For kit (phantom BOM) products, action_explode() deliberately relies on product_uom_qty == 0 as a signal to derive the BOM factor from the actual total scanned quantity (move.quantity) rather than from the first-scan demand, which would be captured too early. A second override in stock_barcode_mrp reverts product_uom_qty back to 0 for kit products only, while keeping the location fix. opw-6150750
This update fixes an issue where the Point of Sale dashboard incorrectly displayed all POS locations under the default warehouse, even when a specific POS was configured with a different warehouse and operation type. The change ensures that the POS dashboard accurately reflects the warehouse associated with each POS based on its setup, improving inventory management and reporting.
Original PR description
When filtering pos by warehouse_id, all pos are under the same warehouse even if we had configure an Operation Type from a different warehouse for a specific pos. Steps to reproduce: ------------------- * Setup a second warehouse in the company * Add the new POS operation type picking for the second warehouse on the POS settings * Group by warehouse in the POS dashboard > Observation: It always shows the first warehouse Why the fix: ------------ The warehouse_id field on pos.config was a plain Many2one with a static default that always set it to the first warehouse of the company. Convert warehouse_id into a computed stored editable field that derives from picking_type_id.warehouse_id. This ensures the warehouse stays in sync when the operation type changes, while still allowing manual override for the Ship Later feature. opw-6104652
This update resolves a minor issue in the invoice grouping test, ensuring that users can correctly ungroup lines even after an invoice has been imported, grouped, and posted. This enhancement improves the reliability of the testing process and ensures proper invoice handling within the system. This change is relevant for users managing invoices and tax calculations.
Original PR description
[FIX] account_edi_ubl_cii: fix group lines test Fix the test `test_import_invoice_group_lines_by_tax` to cover the case where an invoice was imported, grouped and posted, the next one will be grouped but the user still can ungroup lines up to 18.3, an other PR will be opened for 18.4+ no-task
This update resolves an issue where a delay in website menu transitions could cause navigation elements to behave unexpectedly. Specifically, a dropdown menu might close prematurely when combined with other actions. This ensures a smoother and more reliable user experience for website visitors.
Original PR description
[FIX] website: wait for extra menu to fully render before continuing When clicking on the extra menu item, a Bootstrap dropdown is displayed with a transition. Because this transition takes time, it can lead to undeterministic behavior especially in tests. For example, if a tour clicks on the extra menu item and then clicks on the "Site" button in the navbar, the dropdown transition may still be in progress. This can cause the "Site" dropdown to close prematurely. runbot-240955 Forward-Port-Of: odoo/odoo#261179
6 changes
Enhancements to existing features
This update ensures the ‘pos_blackbox_be’ module works seamlessly with the latest Odoo images used for IoT Boxes. It backports a previous fix to maintain compatibility and improve the functionality of these devices within the Odoo Enterprise system.
Original PR description
Backport of #100440 opw-6172860
Resolved issues and error corrections
This update fixes a bug preventing changes to Sales Orders (customer, state) in draft mode from being logged in the chatter. The previous system suppressed all tracking data, but this change ensures that user-initiated modifications are accurately recorded for better auditability and communication. This improves transparency and collaboration around sales order updates.
Original PR description
**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a…
**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a Sales Order, do not confirm 2. Change the customer → no log in chatter 3. Confirm the SO, then cancel it 4. Set it back to Quotation → no log in chatter **Current behavior:** No chatter entry is created for either change. **Expected behavior:** Both changes should appear in the chatter since `partner_id` (tracking=1) and `state` (tracking=3) have tracking enabled. **Cause of the issue:** `_track_finalize` discards ALL tracking data whenever the SO is in `draft` state. This was originally intended to avoid noise from catalog product additions, but it also suppresses legitimate field changes like customer updates and state transitions back to draft. **Fix:** Instead of blanket-suppressing all tracking on draft SOs, only discard tracking when the change originates from the product catalog (`_update_order_line_info`), which sets a `catalog_skip_tracking` context flag. This preserves the original noise-reduction intent while allowing real user-initiated field changes to be tracked. Backport of: 311bf3426fb241cd5036db58c6c317fe0e81ab87 opw-6106537
This update fixes a potential error in the Danish tax reporting module that could cause unexpected application crashes. The issue stemmed from a mismatch between how error messages were handled and the expected data type, specifically related to string formatting. The fix includes added tests and resolves the problem, ensuring more stable reporting.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466
This update resolves an issue where discounts weren't being imported accurately due to rounding discrepancies. The fix ensures that discount amounts are imported exactly as they appear on the original invoice, preventing subtotal mismatches. This improves data integrity during invoice processing, particularly for Italian VAT imports.
Original PR description
**PROBLEM** When importing an invoice, we don't want to round the discounts, to avoid discrepancy between the subtotal computed by Odoo, and the subtotal of the file we import. To do this, we change the decimal precision of discount to 100 digits when importing files. However, float_round wasn't built with this in mind, in float round, we add a small epsilon to fix some rounding issue. This small epsilon changes the amount of the discount (50.0 -> 0.5000000000004) and this changes the subtotal. **STEP TO REPRODUCE** 1. Install l10n_edi_it. 2. Change the VAT number of IT Company to 05098540288 (to match the one on the file to import). 3. Import the file present in the bug ticket. 4. Notice the subtotal of the line doesn't match what's in the invoice. **FIX** We skip rounding of the discount on import. Ticket [link](https://www.odoo.com/odoo/project.task/6046324) opw-6046324
A bug preventing list view editing within Studio mode has been resolved. The issue stemmed from an incorrect domain check related to company IDs, which wasn't properly handled due to the view's structure. Adding hidden fields to the XML view resolved the conflict and restored the ability to edit list views.
Original PR description
Steps to reproduce:
1. Install Invoicing and Studio
2. Go the Journal Entries list view
3. Enter Studio mode
4. Go to View, and Enable Mass Editing
The following traceback is raised:
```py
Field 'company_id' used in domain of python field 'journal_id' (
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|', ('company_id', '=', False), ('company_id', 'parent_of', [''])]) + ([('id', 'in', suitable_journal_ids)])) is restricted to the group(s) base.group_multi_company.
```
Now that the list view is editable, there is a check being performed on the `journal_id`'s company and domain. However, those fields aren't present in the view, thus OWL is unaware of their values and cannot properly apply the `journal_id`'s check_company, nor domain. By adding those two fields as `column_invisible`, the error is fixed.
Ticket [link](https://www.odoo.com/odoo/project.task/6119955)
opw-6119955This update addresses a limitation in how Odoo updates its product UNSPSC codes. Previously, new codes could only be added during initial module installation. Now, a new upgrade script automatically adds updated codes to the database, ensuring our product data remains current with industry standards. Existing product codes are not modified.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366