Daily updates from Odoo
Monday, March 9, 2026
34 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where demo livechat sessions incorrectly displayed as active in the info panel, even after receiving feedback. By adding a marker for the end of the conversation, the panel now accurately reflects the session's outcome, ensuring consistent and reliable demo data. This improves the clarity and accuracy of demo information.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations…
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations in the info side panel. This created inconsistent demo data where closed conversations appeared with options meant for ongoing chats (e.g., status shown instead of outcome). **Current behavior before PR:** ---------------------------------------------- - Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set. - As a result, the info side panel treated them as ongoing conversations. - This caused mismatched UI information for demo data. **Desired behavior after PR is merged:** ---------------------------------------------- - Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt. - The info side panel correctly reflects closed conversations with coherent outcome information. Task-5412081 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250001
This update resolves a JavaScript error that occurred when reloading the shopfloor app, specifically during MO process runs. The fix disables the automatic focus of the search bar, preventing a 'null' element error and ensuring consistent functionality. This improves the user experience and stability of the shopfloor application.
Original PR description
Steps to reproduce:
- Open the shopfloor app
- Reload or duplicate the page where the MO process is running
Issue:
A JavaScript error occur during reload:
UncaughtClientError > TypeError
Uncaught Javascript Error > Cannot read properties of null (reading 'blur')
Occured on 101125414-19-0-all.runbot180.odoo.com on 2026-02-16 04:59:28 GMT
TypeError: Cannot read properties of null (reading 'blur')
at https://101125414-19-0-all.runbot180.odoo.com/web/assets
/9d8abcf/web.assets_web.min.js:36280:459
Cause:
This happens when the search bar component attempts to call `blur()` on `inputRef.el` while the element is not yet available or has already been destroyed during the component lifecycle.
Fix:
Disable the search bar autofocus in the shopfloor
`env.config.disableSearchBarAutofocus = true`.
opw-5902675
upg-3894728
Forward-Port-Of: odoo/enterprise#109803
Forward-Port-Of: odoo/enterprise#107491This update removes a temporary workaround in the API documentation that was created when some fields in Odoo were renamed. This change ensures the API documentation accurately reflects the current field names, providing developers with the correct information. It's a minor fix to maintain the consistency and reliability of our API.
Original PR description
Reference-to: ec2b2edda9d4a2e4fb45d0 ([FIX] base: rename inherited custom field) 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 Forward-Port-Of: odoo/odoo#249161 Forward-Port-Of: odoo/odoo#249072
This update resolves a bug that caused the Odoo Enterprise application to crash when users switched between the text and HTML composer in AI chat. The fix ensures focus handling correctly works for both composer types, preventing errors and improving stability.
Original PR description
*=ai_app In AI chat, focusing the composer used to call ev.target.select(). That works for the text composer (textarea), but not for the HTML composer (contenteditable), where select() doesn’t exist and causes a TypeError. This update makes focus handling respect the active composer mode: - text mode keeps the existing select behavior - html mode uses the editor focus path instead task-5981018 Forward-Port-Of: odoo/enterprise#109634 Forward-Port-Of: odoo/enterprise#109163
This update resolves an unexpected behavior in the HTML editor within Safari, where pressing the spacebar would incorrectly move the text selection. The fix addresses a discrepancy in how Safari handles text node normalization, ensuring consistent and accurate selection behavior across browsers.
Original PR description
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a…
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a text node adjacent to another and we normalize, the two text nodes will be merged but the selection will move to the parent element instead of the correct position inside the new merged text node. Example: before normalize: `<span>"ab""c[]d"</span>` after normalize: `<span>"ab[]cd"</span>` (expected) vs `<span[]>"abcd"</span>` (Safari) Solution: Instead of using `normalize`, we manually merge adjacent text nodes and properly restore the selection by computing the absolute offset before the merge and restoring it to the correct position in the merged text node. Steps to reproduce: - Have two adjacent text nodes inside a `span`. - Put the selection on the second text node in the middle. - Press space. - The selection will move to the end of the text. opw-5956709 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252485 Forward-Port-Of: odoo/odoo#251918
This update resolves an issue where AVCO valuations were incorrectly defaulting to a product's initial price when stock move dates were earlier than the product's creation date. The fix ensures that actual stock movements always take precedence in AVCO valuation calculations, providing more accurate inventory reporting.
Original PR description
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps…
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps to reproduce**: - Create a new product with a standard price of 0 and AVCO cost method - Create a PO for that product with a unit cost of 1,000,000, confirm it and validate the receipt - Go to Accounting > Review > Inventory > Inventory Valuation -> Observe that the valuation correctly takes the purchase into account - Go back to the receipt, unlock it and change the effective date to one week in the past - Go back to Inventory Valuation -> Observe that the valuation no longer takes the purchase into account - Change the valuation date to yesterday -> Observe that the valuation takes it into account again **Cause**: When a product is created, a `product.value` record is instantiated with today’s date: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L174 https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L202 In the AVCO computation, a manually set product value (`product.value`) takes precedence over move values when it is anterior, either here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L309-L312 or here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L334-L338 Since the stock move date is set one week in the past, the initial product value (0.0) takes precedence over the move valuation. When the valuation date is moved forward to yesterday, this initial product value is ignored and the move value is correctly applied again. **Solution**: Setting the initial `product.value` date to the product creation date is arbitrary, as it makes inventory valuation depend on when the product was encoded rather than on real stock history. Instead, set the date of the first `product.value` to the earliest possible epoch, ensuring that any real stock move always takes precedence in AVCO valuation. opw-5882080 Forward-Port-Of: odoo/odoo#247407
This update fixes a problem where self-order prices weren't accurately calculated when taxes and fiscal position mappings were involved. The change ensures prices are correctly recomputed using accounting methods, leading to more accurate order totals and financial reporting. This improves the reliability of self-order transactions.
Original PR description
Before this commit, the price of order lines from self was recomputed in the backend but for orders with price included taxes and a fiscal position mapping, the recomputation was not correct. This commit fixes the issue by recomputing the prices using compute_all method from accounting on taxes after fiscal position. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252487 Forward-Port-Of: odoo/odoo#251945
This update fixes an issue where miscellaneous entries within overdue reports weren't being included in the printed reports sent to partners. Now, when users mark a miscellaneous entry for inclusion in the follow-up report, the full entry details (including amount and description) will appear in the printed report. This ensures partners receive complete information about overdue items.
Original PR description
…port Currently, even if users mark a miscellaneous entry to be included in the follow-up report, only its amount is counted in the total overdue; the entry itself is excluded from the printed report sent to the partner. Steps to reproduce: - Have a journal item with partner, receivable account and due date in the past - Open followup report for the partner, uncheck 'No followup' for the aml - Go back to the partner, in the followup section, hit 'Send' and send the manual followup (or wait/trigger the scheduled action) Issue: Printed followup report is missing any info on the misc entry opw-5405657 Forward-Port-Of: odoo/enterprise#109581 Forward-Port-Of: odoo/enterprise#106725
This update fixes an issue where employee status information wasn't being retrieved correctly, leading to potential maintenance challenges. By reading `im_status` directly, the system now accurately captures necessary data for out-of-office calculations and internal user access, ensuring consistent employee status representation.
Original PR description
Just reading `im_status` instead of the dedicated method makes the maintenance harder and it is potentially problematic as it doesn't return the `im_status_access_token` nor the necessary extra information from employee records to compute out of office. In the 2 flows that are fixed here, the token is not mandatory as employee data is typically returned to internal users which have the right to read partners regardless. Leave status is also sent as part of `_store_avatar_card_fields` so that is also fine, but homeworking status appears to not be sent. `_store_avatar_card_fields` does return `work_location_id` and its type but `_store_im_status_fields` returns `work_location_type` and that is what is used in `hr-homeworking-office` of `imStatusDataRegistry`.
This update adjusts the spacing in the live chat sidebar to create a cleaner and more visually appealing design. Specifically, the spacing between the language code and the conversation badge counter has been reduced, and the language code is now displayed with a muted style for better readability. This improves the overall user experience.
Original PR description
Before this commit, discuss app sidebar items that had both the language and the important badge counter had too much spacing. This commit adapts spacing to preserve visually the same except reducing the language and counter spacing. The language code was also too visible compared to conversation name, so this PR improves by putting a `.text-muted` on it. Before / After <img width="297" height="945" alt="Screenshot 2026-03-06 at 14 44 59" src="https://github.com/user-attachments/assets/b75fc8ae-7c56-4918-8adb-5a347b740d7e" /> <img width="298" height="949" alt="Screenshot 2026-03-06 at 14 44 45" src="https://github.com/user-attachments/assets/6f3b98ec-4f54-438c-8e8b-bdac9a842a5d" />
This update improves the Knowledge app by automatically moving related articles to the trash when an audit report is deleted. Previously, linked articles remained visible, leading to cluttered workspaces and confusion. This change ensures a cleaner and more organized Knowledge experience for users.
Original PR description
When a user deletes an audit report, the articles linked to that report currently remain visible in the Knowledge app. This can lead to cluttered workspaces and confusion about which articles are still relevant. To keep workspaces clean, these linked articles will now be automatically moved to the trash when the audit report is deleted. Task-5902448 Forward-Port-Of: odoo/enterprise#101234
This update fixes an issue where sick leave days weren't accurately counted across months and the basic salary was incorrectly calculated when there were no work entries on payslips. The changes ensure accurate tracking of sick leave and prevent incorrect salary calculations, improving payroll accuracy.
Original PR description
### Issue: - Sick leaves were calculated using the leave record dates, so leaves that started in one month and continued into another month were not counted correctly. - The Basic salary rule was applied even when there were no `WORK100` work entries on the payslip. ### Fix: - Updated the leave filtering logic to consider leaves whose `request_date_from` or `request_date_to` overlaps with the payslip period year, instead of relying solely on the leave start date. - Adjusted the Basic salary computation to execute only when `WORK100` exists in `worked_days_line_ids`, preventing calculation when no effective worked entries are present. ### Impact: - Ensures sick leave days are correctly accounted for in the relevant payslip period, even when the leave spans across months. - Prevents incorrect Basic salary computation on payslips with no `WORK100` work entries, resulting in accurate payroll calculations. --- task-5462380 Forward-Port-Of: odoo/enterprise#104401
This update resolves an issue where multi-page invoices generated as PDFs would display an empty first page. The fix adjusts how the PDF rendering engine handles table formatting, ensuring all invoice lines are correctly placed across multiple pages. This improves the user experience when printing invoices.
Original PR description
Steps to reproduce: 1. Create an invoice with enough lines to span at least two pages. 2. Print the Invoice PDF. Observation: The first page appears empty (except for the header), and the entire invoice lines table is pushed to the second page. Cause: The introduction of the 'table-responsive-sm' wrapper in saas-19.1 includes 'overflow-x: auto'. The wkhtmltopdf rendering engine treats elements with overflow properties as unbreakable atomic blocks. If the block's height exceeds the remaining space on the current page, the engine moves the entire container to the next page rather than splitting it. Solution: Apply 'overflow: visible !important' to the 'table-responsive-sm' div. This overrides the Bootstrap default for the reporting engine, allowing the internal table rows to break naturally across pages while retaining the responsive wrapper for web/portal views." opw-5937043 Forward-Port-Of: odoo/odoo#251221
This update ensures that the 'Outstanding Account' field is automatically populated when a new 'Card' payment method is created in Point of Sale. Previously, the system lacked this configuration, causing inconsistencies between automated setup and manual setup, which has now been resolved to improve data accuracy and streamline the POS configuration process.
Original PR description
Steps to reproduce: 1. Initialize a new database with 'point_of_sale' and 'accountant' modules. 2. Go to Configuration > Payment Methods and open the 'Card' payment method. 3. Observe that the 'Outstanding Account' field is empty, despite being required in the view for bank journals. The issue occurred because the '_create_journal_and_payment_methods' method created the default 'Card' payment method without specifying an 'outstanding_account_id'. While the ORM allows this (as the field is only required in the view), it creates an inconsistency between automated setup and manual configuration. Solution: Modify '_create_journal_and_payment_methods' to automatically assign the 'outstanding_account_id' during creation. It follows the pattern used in the payment method's onchange logic by fetching the default debit account from the chart template or falling back to the company's transfer account. opw-5914536 Forward-Port-Of: odoo/odoo#249439
This update resolves a warning message users encountered when adding Google Shared Drive links to course content. The fix allows the system to properly access files within Shared Drives by explicitly requesting broader access through the Google Drive API. This ensures a smoother experience for users adding content from Shared Drives.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413 Forward-Port-Of: odoo/odoo#241037
This update resolves an issue where the Documents app would crash after deleting a payslip run. The fix ensures that related documents are also removed when a payslip run is deleted, preventing data inconsistencies and improving application stability. This improves the user experience and avoids potential errors.
Original PR description
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a…
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a payslip run with payslips - Go to a payslip, validate and generate the document - Then cancel and reset to draft - Reset the Payslip Run to draft - Delete it - Open the Documents app ### Cause: The payslips are linked to the run with a `ondelete='cascade'` relation. https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113 This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB. ### Solution: Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there. opw-5501061 Forward-Port-Of: odoo/enterprise#109510 Forward-Port-Of: odoo/enterprise#105969
This update resolves an issue causing the floor screen to repeatedly re-render, impacting performance. The problem stemmed from a bug where the system was incorrectly updating appointment start times, triggering an infinite loop of re-renders. This fix ensures the floor screen displays appointments accurately and efficiently.
Original PR description
Infinite re-rendering in floor_screen.
Root cause: `getFirstAppointment` mutates reactive model state
(appointment.start) during rendering:
```
appointments.map((appointment) => {
if (appointment.start < startOfToday) {
appointment.start = startOfToday; // <= mutates reactive state!
}
});
```
And `startOfToday` is set by
`DateTime.now().set({ hours: 0, minutes: 0, seconds: 0 })`
Which doesn't zero milliseconds, so each render creates a new
`startOfToday` with a later millisecond value.
The comparison `appointment.start < startOfToday` keeps being true
triggers another write => another re-render => infinite loop.
Forward-Port-Of: odoo/enterprise#109915This update resolves an issue where the Timesheet Assistant form wasn't clearing after deselecting multiple suggestions. Now, when you remove all suggestions, the form automatically resets and disappears, preventing confusion and ensuring accurate timesheet data. This improves the user experience and data integrity.
Original PR description
# Steps to reproduce - Open Timesheet Assistant - Select multiple suggestions - Click on the cross to deselect all suggestions # Current behaviour The created timesheet from is not cleared and remains opened. # Expected behaviour Instead, the form should be cleared and disappear. task-6003551 Forward-Port-Of: odoo/enterprise#109819
This update fixes an issue where confirming multiple quotes could result in a negative loyalty point balance. The system now checks for sufficient points before calculating changes, preventing this error and ensuring accurate loyalty point tracking. This improves data integrity and user confidence in the loyalty program.
Original PR description
### Steps to reproduce: - Download Sales app - Then, tick Configuration -> Settings -> Promotions, Loyalty & Gift Card - From the sales app top bar, Products -> Discount and Loyalty -> New - Rule =…
### Steps to reproduce: - Download Sales app - Then, tick Configuration -> Settings -> Promotions, Loyalty & Gift Card - From the sales app top bar, Products -> Discount and Loyalty -> New - Rule = Default & Reward = any discount for 100 points - From the 'Loyalty Cards' smart button, create a new loyalty card for a test customer and set its balance to 100 points - Create 2 "Quotations" with product below 50$ and claim reward. Don't confirm the quotes - Select the previous quotes and click "Confirm Orders" smart button - Verify that the created loyalty card has a balance of -100 ### Cause of Issue: When multiple quotations are confirmed in bulk, the system processes their eligibility for rewards one by one. https://github.com/odoo/odoo/blob/3656171994450d11151565efdb4b9dd0468cefa8/addons/sale_loyalty/models/sale_order.py#L150-L153 Hence, each quote will pass the check because the check since they individually require a number of points less than or equal the current loyalty card balance. Then https://github.com/odoo/odoo/blob/3656171994450d11151565efdb4b9dd0468cefa8/addons/sale_loyalty/models/sale_order.py#L166-L167 The change is caluclated collectively, which lowers the balance to a negative amount. ### Fix: Since the `change` is calculated before any change is done in the database, it is suitable to raise an error to the user at this point if the change is going to turn the balance negative. opw-5929187
This update ensures that all float time fields, including those in list views, are formatted consistently using the same options. Previously, the list view footer wasn't correctly applying the formatting rules, leading to discrepancies. This change guarantees a uniform and accurate display of float time values across all views.
Original PR description
Before this commit, the float_time formatter didn't extract the options "unit" and the field widget was. So, the list view footer, that was using the formatter and not the field widget, wasn't formatted in the same way that the column. Now, the formatter and the field widget float_time time behaviour with the options are the same. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where setting the inventory quantity to zero on a product without a defined location would cause an error. The fix ensures that the system handles this scenario gracefully, preventing disruptions to inventory management. This improves data accuracy and reliability.
Original PR description
When a user sets the inventory quantity to 0 on a quant while the product’s Inventory Location is unset, a traceback is raised. Steps to reproduce the error: - Install ``stock`` module with demo data…
When a user sets the inventory quantity to 0 on a quant while
the product’s Inventory Location is unset, a traceback is raised.
Steps to reproduce the error:
- Install ``stock`` module with demo data
- Open ``Cabinet with Doors`` product
- In Inventory tab, unset Inventory Location > Open forecast report > click the On Hand quantity
- Select the quant > Actions > Set to 0
Traceback:
```py
ValueError: NotNullViolation('null value in column "location_dest_id"
of relation "stock_move" violates not-null constraint
```
https://github.com/odoo/odoo/blob/bc790e13ddf3ceacead40cc6ff8d27f1a5f5364d/addons/stock/models/stock_quant.py#L1005-L1016
When property_stock_inventory is unset,
the ``_get_inventory_move_values`` method assigns a NULL value to ``location_dest_id`` in ``move_vals``.
As a result, creating the stock move with a NULL ``location_dest_id`` leads to the above traceback.
sentry-7117991902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245245This update resolves an issue where the 'stats' button on a Purchase Order (PO) would disappear after the PO was canceled when it was originally created from a Stock Movement (MO). The fix ensures the PO remains linked to the MO, maintaining accurate tracking and reporting. This prevents confusion and ensures data integrity.
Original PR description
* Currently when a PO generated from MO, after that we cancel that PO, the MO statsbutton disappear, * Reason: because we remove move_dest_ids out of po line so the link is missing 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 Forward-Port-Of: odoo/odoo#250042
This update resolves an issue where users without project access rights would encounter errors when modifying work orders linked to private projects. The fix ensures that workers can successfully update these work orders, improving workflow efficiency and preventing disruptions.
Original PR description
When working on a MO that is linked to a project in private, it will trigger a access error if the worker is does not have project access right Steps to reproduce: ------------------- * Install Project, MRP, Accouting * Create a private project * Create a MO and link it to this project * confirm this MO with a user that has no project access right Observation: ------------- When modifying the MO, we will pass through the write that has been overwritten: https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/project_mrp_workorder_account/models/mrp_production.py#L6-L10 we will call _get_analytic_distribution on project.project and since _get_analytic_distribution will [read fields from self](https://github.com/odoo/odoo/blob/436921c24a531eba6bf57ffe3f7c3b4978139d83/addons/analytic/models/analytic_line.py#L59-L64) we need project.project read rights. opw-4919576 Forward-Port-Of: odoo/enterprise#108148
This update fixes an issue where the system incorrectly treated re-deliveries as returns, resulting in a single shipping label being generated. Now, when returning multiple packages, the system accurately identifies and processes each package as a separate return, ensuring proper delivery label creation and improving the efficiency of the return process.
Original PR description
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery -…
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery - Multiple packages - Validate transfer - Return - Validate IN - Return again - Add the UPS under the "additional info" tab - Ensure still multiple packages - Validate OUT Cause ----- When preparing the shipping data, we go through https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121 which leads us to do https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155 so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`. https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58 From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns. ----- Ticket: opw-5866100 Forward-Port-Of: odoo/odoo#251789 Forward-Port-Of: odoo/odoo#246946
This update fixes a display issue in the payroll module where 'Confirm' buttons were incorrectly visible when payslips existed. The system now correctly hides these buttons when payslips are present, streamlining the user experience. This ensures users only see confirmation options when appropriate.
Original PR description
The 'empty_payslips' field is an Integer, but the view was treating it as a pure Boolean. This commit: - Updates 'Confirm' buttons to be invisible when payslips exist (> 0). Task: 5916154 Forward-Port-Of: odoo/enterprise#106957
This update removes unnecessary overrides related to Swiss payroll calculations within the payrun process. The core logic has been corrected, making these overrides no longer required. This streamlines the payroll process and ensures accurate calculations.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves a bug where hidden popups were causing extra dropzones during website editing. The fix ensures popup visibility is consistently tracked, preventing these unexpected dropzones and improving the overall drag-and-drop experience. This improves usability for users adding content to the website.
Original PR description
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost…
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost `d-none` class after dropping unrelated snippets ## How to reproduce ### Bug 1: extra dropzones from hidden popup desync 1. Enter website edit mode. 2. Drop popup in the page 3. Drag another snippet as you were adding it to the page 4. An additional dropzone appears below the invisible popup snippet ### Bug 2: hidden popup loses `d-none` class 1. Enter edit mode. 2. Drop a popup. 3. Close it so `.s_popup` gets `d-none`. 4. Drop any other snippet on the page arbitrarily. 5. Popup loses `d-none` class. ## Expected behavior after fix - Popup hidden/shown state remains stable across editor refreshes and snippet drops. - Drag-and-drop no longer creates extra dropzones from hidden popups. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251517 Forward-Port-Of: odoo/odoo#250625
This update fixes errors preventing users from searching for job titles within the employee module. Previously, access restrictions on a related database table caused issues for certain user groups. The changes remove these restrictions, allowing all users to perform job title searches and address a separate issue related to resume searches.
Original PR description
[FIX] hr: fix job title search access error Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones Bug cause: Only…
[FIX] hr: fix job title search access error Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones Bug cause: Only users/managers can access to hr_version model and since marc demo has not, it receives this error. Bug solution: I put store=True and compute_sudo for job_title and by that way everyone can search for job_title without access. In the task [MOHF] showed another traceback about job title search. I fixed that in this commit as well. Bug 2 reproduction: employee app -> try to search something for resume -> it will give error (there is no version_ids) Bug 2 cause: There is no version_ids in the employee.public model, in the search version_ids.job_title is used but job_title can be used directly. Bug 2 solution: I used job_title in the search instead of using version_ids.job_title. task - 6000488 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 Forward-Port-Of: odoo/odoo#251949
This update ensures that One Stop Shop (OSS) invoices for intra-EU B2C sales in Italy are correctly formatted for the Italian Revenue Agency (Agenzia delle Entrate). Previously, the system rejected these invoices due to a specific formatting requirement. This change adds the necessary lines and summaries to ensure compliance with FatturaPA standards.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 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 Forward-Port-Of: odoo/odoo#252368 Forward-Port-Of: odoo/odoo#243740
This update fixes an issue where error messages from the IAP (Internet Access Point) were not being displayed correctly when the French reports module was adapted for the new ASPone API. The fix ensures that errors are now properly presented, improving the user experience and troubleshooting capabilities for French-language reporting.
Original PR description
When adapting the code to ASPone new rest api, errors were no more well handled, this fix aims to correctly display the errors we get from IAP task-5955980
This update fixes an issue where long preset names in Point of Sale (PoS) were causing the preset button to take up too much space and obscure other buttons on the screen. The change ensures the PoS interface remains usable, even with lengthy preset names, improving the overall user experience. This was a minor visual adjustment.
Original PR description
# How to reproduce - Enable Take out / Delivery / Members in PoS Configuration - Create a preset with a very long name and set it as default - Open the register # The problem The preset button takes too much space and hide the other buttons opw-5938578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250671
This update fixes an issue where formatting was lost when restoring content from the full composer to the basic composer. Now, users are prompted to choose between restoring formatting in the full composer or using the simpler composer without formatting, providing a more flexible and user-friendly experience.
Original PR description
Before this commit, when using the full composer and accidentally closing it with some content, the composer content was recovered on the basic composer and formatting was lost. This happens because…
Before this commit, when using the full composer and accidentally closing it with some content, the composer content was recovered on the basic composer and formatting was lost. This happens because restore of content only works in the basic composer, and basic composer does not support rich HTML like the full composer. This commit adds a new UX/UI to restore formatting when accidentally leaving the full composer: When some content has been restored from full composer, opening the chatter composer momentarily disables everything but the full composer button, in addition to show a popover suggesting the user to decide to either continue with Full Composer and restore formatting, or restore content in the small composer without the formatting. Most of the time people want to restore formatting from the full composer, but at the same time the full composer can be a frustrating experience that may incite to just continue with the more reliable small composer. This new popover support both use-cases. Task-5910961 <img width="1219" height="175" alt="Screenshot 2026-02-26 at 17 28 06" src="https://github.com/user-attachments/assets/13d8e1ca-4186-445e-8422-a14c31f8570f" /> Forward-Port-Of: odoo/odoo#252318 Forward-Port-Of: odoo/odoo#247245
This update ensures that employees only receive timesheets for public holidays that are relevant to their company. Previously, timesheets were incorrectly generated for employees in companies without the holiday, leading to inaccurate time tracking. This change improves data accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
This update resolves an issue where the delivery partner wasn't correctly set on sales orders when using MTSO pull rules for stock movements. The fix ensures that the correct contact information is passed through the delivery process, particularly in multi-step routes and subcontractor scenarios, improving order fulfillment accuracy.
Original PR description
*:{sale_,}stock, mrp_subcontracting ### Sate of the art: Since the refactoring of 19.0 removing the procurement groups and introducing stock references 2713876dbc70d3984e584a9037a2206dcda4e84a, the…
*:{sale_,}stock, mrp_subcontracting
### Sate of the art:
Since the refactoring of 19.0 removing the procurement groups and introducing stock references 2713876dbc70d3984e584a9037a2206dcda4e84a, the `partner_id` is not propagated in pull flows. While the following fix 3bd213c24536fa6d40a7d7a44d4c553947f82c84 addresses some of these propagation issues, it only propagates the partner in case of a move chain for mto moves generated by mto rule. The current PR addresses some of the mtso use cases such as the mtso multi-step pull delivery and the mtso resupply subcontractor on order.
## 1. mtso multi-step pull delivery
### Steps to reproduce:
- In the settings enable: Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in deliveries in 3 steps
- Inventory > Configuration > Warehouse Management > Routes
- Modify you 3 steps Delivery (pick, pack, ship) route:
- Change the rules to be in pull Stock -> Pack -> Out -> Cust
- Change the rules: Pack -> Out -> Cust to be in mtso and not mto
- Create and confirm a sale order for a partner A
- The pick, pack and ship should be created
#### > The delivery partner (contact) is only set on the ship
### Cause of the issue:
As the route has been modified to be handled by pull rules, it is generated from end to start by subsequent move confirmations. However, as, the pull rules Pack -> Out -> Cust are in mtso, the associated moves will be created with a `make_to_stock` `procure_method`.
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_rule.py#L304-L305
Hence, when a procurement is created because of the `mts_else_mto` rule in the `_action_confirm`, the procurement will not set any `move_dest_ids` nor `partner_id`:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1549-L1552
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1688-L1690
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699
In other words, the pick and pack moves will not be part of a move chain (with `move_dest_ids`), and the `partner_id` is not propagated.
While the move chain `move_dest_ids` propagation is indeed only intended for mto moves (created by mto rules) since the mtso refactoring: a72382063ee662010729d983fbf6fb6305b8adf2 the `partner_id` should be propagated for pull rule in `mts_else_mto` to avoid losing the delivery partner that used to be propagated by procurement groups which were removed in 19.0 by 2713876dbc70d3984e584a9037a2206dcda4e84a Since the associated fix: 3bd213c24536fa6d40a7d7a44d4c553947f82c84 the `partner_id` can now be propagated via the `procurement_values` but is currently only propagated in case of mto moves:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699
## 2. Resupply subcontractor on order
### Steps to reproduce:
- In the settings enable: Multi-Step Routes, Subcontracting
- Inventory > Configuration > Warehouse Management > Routes
- Set the rule of the "Resupply Subcontractor on order" route to mtso
- Create a subcontracting bom for a finished product (FP) with a storable
component (comp) for subcontractor: Bob
- Create and confirm a PO for 1 unit of FP with Bob as vendor
#### > Bob is not set as delivery contact on the resupply delivery for comp
### Cause of the issue:
When the rule is in MTO, so is procure method of the move raw for comp in the subcontracted MO. As such, the procurement generated at its confirmation will provide a `move_dest_ids`:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_move.py#L1688-L1698
which allows to propagate the subcontractor once the procurement is run because of these lines:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_rule.py#L307
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
In the present case, since the rule is in mtso, the `procure_method` of the raw move will be mts and the `move_dest_ids` will not be propagated. So that `partner_id` is never set as the subcontractor.
### Note about the fix:
When the rule `procure_method` is `mts_else_mto`, at the time we enter override of the `_get_stock_move_values` of `mrp_subcontracting`:
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
the only reference to the subcontractor is the one contained in the `production_ids` of the `reference_ids` of the procurement values which does not look like a reliable link as:
- Multiple `reference_ids` could be set in the values of the procurement
- Multiple `productions_ids` could be linked to the `reference_ids`
- Without the link to the subcontracted move raw nothing indicates that we trigger the creation of a move destined for a subcontractor
By contrast, the current proposition rely on the move that should have been set as `move_dest_ids`in the mto flow and mitigate these uncertainties.
opw-5402407
opw-5883477
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251564
Forward-Port-Of: odoo/odoo#250307