Daily updates from Odoo
Navigate
Branch
Monday, March 9, 2026
120 changes
32 changes
Enhancements to existing features
This update restricts the ‘Working Schedule Change’ wizard to only Belgian companies, improving the accuracy of payroll calculations. It also removes a redundant field and enhances the user interface with improved spacing, resulting in a cleaner and more intuitive experience for users managing Belgian employee schedules.
Original PR description
- Show the “Working Schedule Change” wizard only for employees belonging to Belgian companies. - Remove the “Post Change Contract Creation” field from the working schedule change wizard. - Add extra right padding to the warning alert in the time-off section for improved UI spacing. task-5367812 Forward-Port-Of: odoo/enterprise#109378 Forward-Port-Of: odoo/enterprise#101013
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
9 changes
Resolved issues and error corrections
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees linked to non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888
This update resolves an issue where the Timesheet Assistant form wouldn't clear after deselecting suggestions, leaving a partially filled timesheet open. The fix ensures that the form is completely cleared and disappears, providing a cleaner user experience and preventing confusion. This improves data accuracy and usability.
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
This update resolves an issue where sending digest emails failed when a company didn't have a website configured. The fix prevents a technical error (KeyError) by ensuring the system handles cases where website information is missing. This ensures all users can receive their email digests, regardless of whether a website is set up.
Original PR description
When a company has no website configured, sending a digest email raises a traceback. Steps to reproduce the error: - Install ``website`` module - Create a new company and switch to it - Create a new digest email > In KPIs, Enable Visitors > Add recipient > Save - Click on Send Now button Traceback: ```py KeyError: res.company(1,) ``` https://github.com/odoo/odoo/blob/dee3fdee0326db032d95639eb8ee9386bb1762d4/addons/website/models/digest.py#L49-L59 If no website exists for the company, ``websites_per_company`` becomes an empty dictionary. Therefore, accessing ``websites_per_company[company]`` raises the above traceback. sentry-7239108433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Spreadsheet app would crash when using the 'Date' global filter. The fix ensures the system correctly handles scenarios where the 'spreadsheet_account' module isn't installed, preventing the error and improving filter stability.
Original PR description
Steps to reproduce: - Install Spreadsheet and Accounting - If `spreadsheet_edition_account` is installed, uninstall it - Go to Spreadsheets, create a new one and add a "Date" global filter => Traceback This commit fixes the issue by handling the case where no fiscal year is not installed. Task: 6002612
This update resolves an unexpected behavior in the HTML editor within Safari, where pressing the spacebar would shift the selection incorrectly. The fix involves a manual merging of adjacent text nodes to ensure accurate selection handling, improving the editor's usability across different 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 fixes an issue 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 'Confirm' buttons were incorrectly displayed when payslips existed. The system now correctly hides these buttons when there are outstanding payslips, providing a cleaner user experience. This ensures users only see the 'Confirm' button when it's 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 fixes an issue where credential errors were displayed in a confusing format. It also ensures correct XML generation for partners without OIB information, enhancing data accuracy. New tests have been added to validate these improvements.
Original PR description
- Credentials errors have a separate format in MER, they should now be displayed in a more user-fiendly manner - Correcting XML generation for partners with no explicit OIB provided - Adding tests for both changes task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252083 Forward-Port-Of: odoo/odoo#249448
This update resolves a problem where invoice PDFs generated with multiple line items displayed incorrectly, often pushing content to subsequent pages or mixing header elements. The fix ensures the PDF engine handles the table as a standard block, preserving the mobile-friendly web view while improving PDF output. This improves the professionalism of invoices generated for printing.
Original PR description
The invoice report table uses 'table-responsive-sm' to improve mobile readability. However, this class causes rendering artifacts in PDF generation via wkhtmltopdf. Steps to reproduce: - Have an invoice with multiple lines - Print Issue: Depending on the number of lines involved the printed pdf may exhibit graphical issues: - The first page may not contain invoice lines at all, with all lines pushed to the second page - The second page may have the header mixed up with the first line Analysis: It occurs after refactoring the invoice report for mobile view https://github.com/odoo-dev/odoo/commit/ad6351c44b7419f2a1c13731e33b111e0b25e633 However, when printing the report we don't actually need the responsible table. This commit preserve the mobile-friendly web view while ensuring the PDF engine handles the table as a standard static block. opw-5909071
3 changes
Resolved issues and error corrections
This update fixes an error in how project budgets are calculated, ensuring accurate spending and remaining amounts. Previously, the system incorrectly displayed negative percentages and inflated remaining balances. Now, the budget summary shows the correct spent and remaining amounts for expense budgets.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings…
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings page 3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates. 4. Click Add Budget button and open the budget wizard. 5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000). 6. Create a Vendor Bill using the same analytic account with an amount of 1000. 5. Confirm the bill. 6. Go back to Project's Updates and click New button to view the budget summary. Observation: --------------------------- The budget summary displays incorrect signs and percentages in Activities summary, for example: ``` -10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining. ``` This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000). Issue: --------------------------- The project cost (already negative) was negated again when computing the spent amount in https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs. Solution: --------------------------- For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly. After the fix: ``` 10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining. ``` opw-5357854 Forward-Port-Of: odoo/enterprise#109638 Forward-Port-Of: odoo/enterprise#102126
This update fixes an issue where miscellaneous journal entries weren't appearing in printed follow-up reports, even when marked for inclusion. Now, all relevant information from these entries, including the entry itself, is included in the report sent to partners, ensuring accurate overdue tracking. This improves the visibility of outstanding debts.
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 removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The standard Odoo logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures accurate and compliant payroll processing for Swiss clients.
Original PR description
Not necessary anymore, standard logic has been fixed
14 changes
Resolved issues and error corrections
This update fixes an error in how project budgets are calculated, ensuring accurate spending and remaining amounts. Previously, the system incorrectly displayed negative percentages and inflated remaining balances. The fix ensures that negative budget amounts are handled correctly, providing reliable budget tracking.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings…
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings page 3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates. 4. Click Add Budget button and open the budget wizard. 5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000). 6. Create a Vendor Bill using the same analytic account with an amount of 1000. 5. Confirm the bill. 6. Go back to Project's Updates and click New button to view the budget summary. Observation: --------------------------- The budget summary displays incorrect signs and percentages in Activities summary, for example: ``` -10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining. ``` This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000). Issue: --------------------------- The project cost (already negative) was negated again when computing the spent amount in https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs. Solution: --------------------------- For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly. After the fix: ``` 10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining. ``` opw-5357854 Forward-Port-Of: odoo/enterprise#109638 Forward-Port-Of: odoo/enterprise#102126
This update fixes a bug that prevented users from reconciling batch payments with bank statements when exchange rates changed between the payment creation and reconciliation. The fix ensures accurate currency conversion, resolving the 'unbalanced move' error and allowing for successful reconciliation.
Original PR description
…tion Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move. Steps to reproduce: - Have the main…
…tion Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move. Steps to reproduce: - Have the main company in USD and EUR as foreign currency - Have a bank journal with currency EUR (Bank EUR) - Create an xchange rate for today (1.1) - Make a Payment (EUR), it should not have an associated move - Put the payment in a batch - Update the exchange rate for today (1.2) - Create a Bank transaction in the journal Bank EUR matching the payment amount - Open the bank reconciliation screen and reconcile the transaction with the batch Expected result: Everything is reconciled. Actual result: User gets an error message saying that the account move is not balanced. Analysis: The issue occurs because the reconciled payment amount is converted to the company currency using the date provided in the payment. However the rate was changed in the meanwhile, so it does not match the amount that was used to create the exchange entry values. opw-5164405 Forward-Port-Of: odoo/enterprise#98495
This update resolves an issue where payments with outstanding receipt accounts weren't automatically matched to bank transactions. The fix allows the system to correctly match payments based on amount, ensuring accurate reconciliation and streamlining financial processes. This improves the reliability of our accounting system.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387
This update corrects a display issue in the website editor where the 'Custom URL' field incorrectly appeared on certain pages. Previously, this field was misleadingly presented even when the URL didn't support customization. Now, the field only appears when a page's URL is editable, ensuring a cleaner and more accurate SEO experience.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not…
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394 Forward-Port-Of: odoo/odoo#231609
This update resolves an issue where ZATCA invoicing was incorrectly applied to Settle Due orders in Point of Sale with ZATCA enabled. The change ensures that Settle Due orders are correctly identified and excluded from ZATCA reporting, preventing duplicate invoices and ensuring accurate financial reporting. Mixed settlement and sale orders are now blocked to avoid complex reporting requirements.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244712
This update resolves an issue where the system couldn't access files shared within Google Shared Drives. The fix adds a setting to the API request, allowing the system to properly search across all Google Drive locations. This ensures users can seamlessly embed content from Shared Drives into courses.
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 Dutch tax returns appeared to be submitted in Odoo, but the actual XBRL data wasn't being transmitted to the Dutch tax authorities. The fix ensures that the necessary XBRL export process is triggered when a Dutch tax return is submitted, aligning the UI with the actual submission status.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711
This update fixes a server error that occurred when merging tables in the restaurant POS system. Specifically, the system now waits for order synchronization before merging tables, preventing errors when a table has an empty order. This ensures a smoother and more reliable table management experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577
This update fixes a server error that occurred when merging tables in the Point of Sale (POS) system, specifically when a table had no associated order. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162
This update resolves an issue that prevented users from properly closing the mail composer when sending emails to a large number of leads (over 500). The fix avoids a technical error related to data payload sizes, ensuring the composer functions correctly regardless of the number of records selected.
Original PR description
Steps to reproduce: 1. Install `crm` 2. Create leads more than 500. 3. Select all and try to send email 4. Not close the wizard by "X" Issue: - Traceback occurs: `Uncaught Promise > Unexpected end of JSON input` Cause: - res_ids is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of `active_ids` exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails while dismissing the wizard at `onCloseWizardModal` Solution: - Fallback to context.active_ids when res_ids is not available opw-5891862 Forward-Port-Of: odoo/odoo#248406
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 resolves an issue that prevented basic receipts from printing correctly when the point-of-sale (POS) name exceeded a certain length. The fix limits the maximum POS name length to prevent a technical error that caused the printing process to fail. This ensures all receipts, regardless of POS name length, can be printed successfully.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update ensures that timesheets are only generated for employees associated with the companies that have public holidays defined. Previously, timesheets were incorrectly created for employees in companies without a relevant 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 fixes a minor issue in the Gantt chart where date selections in the scale selector didn't immediately update. The change ensures that date selections in the dropdown update instantly, providing a smoother and more responsive user experience when setting the chart's timeframe.
Original PR description
Steps to reproduce: - Open any Gantt view (e.g., Planning). - Open the scale selector dropdown and select a custom start or end date. Observation: The dates displayed in the dropdown do not update until the 'Apply' button is clicked. Cause: The XML template was referencing dates from the 'scales' prop, which is managed by the parent Gantt controller. This prop only updates after 'selectCustomRange' is called and the entire view reloads. Consequently, local changes in the date picker were not reflected in the UI during the selection phase. Solution: Modify 'web_gantt.GanttScaleSelector' to display dates directly from the local 'pickerValues' state. Since 'pickerValues' is a reactive 'useState' object, the UI now re-renders immediately when a date is picked, providing instant visual feedback before the user commits the change via the 'Apply' button. opw-5911253
1 change
Resolved issues and error corrections
This update resolves issues with the product barcode lookup tooling, specifically preventing errors caused by mixing API requests and image requests. The code has been refactored to ensure consistent return values, enhancing the reliability of this critical feature.
Original PR description
The tooling had several issues like mixing a request to the API server and requesting an image to another server. Also the parameter of barcode_lookup_request was mutable since 444df3e48cb We separate in two method to ensure we never return the request object but only the parts that we expect (a json or the content)
14 changes
New functionality added to Odoo
This update improves the calculation of meal vouchers within the Odoo Enterprise system. Specifically, a new rule has been added to account for worked days, and the existing retention calculation has been adjusted. This ensures more accurate and compliant meal voucher payouts for employees.
Original PR description
In this commit, we added the meal vouchers worked days rule and adjusted the quantity calculation in the retain on meal voucher rule. task-5877401
Enhancements to existing features
This update adjusts the salary scale parameters used in Odoo's Belgian payroll module (l10n_be_hr_payroll) to reflect changes in Belgian labor laws as of January 1, 2026. These updated values ensure accurate payroll calculations for employees in Belgium, maintaining compliance with current regulations.
Original PR description
. Update cp200_salary_scale_first_year values for 01/01/2026 . Update cp200_salary_scale values for 01/01/2026 task-5485636 Forward-Port-Of: odoo/enterprise#107473
This update to the Spanish tax reporting module (l10n_es_reports) addresses changes required by the new 2026 tax format. Specifically, it incorporates a new field for petrol expenses and adjusts the placement of several ‘casillas’ (tax reporting sections) to align with the updated regulations. This ensures continued compliance with Spanish tax reporting standards.
Original PR description
Forward-Port-Of: odoo/enterprise#109600 Forward-Port-Of: odoo/enterprise#109260
Resolved issues and error corrections
This update fixes a potential data error that could occur when moving folders linked to accounting settings to the trash. The automated system cleaning process was incorrectly attempting to delete these folders, leading to database inconsistencies. This change ensures these folders are excluded from the cleanup process, maintaining data integrity.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869 Forward-Port-Of: odoo/enterprise#109776 Forward-Port-Of: odoo/enterprise#104875
This update ensures that the 'Insert in spreadsheet' action is only visible in list view menus for users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for improved security and user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109900 Forward-Port-Of: odoo/enterprise#108099
This update addresses a failing test within the Odoo Enterprise module, ensuring stability. The change refines the logic for determining product pushes based on move lines, resolving a technical issue. This improves the reliability of stock management processes.
Original PR description
This commit is part of the fw port community PR https://github.com/odoo/odoo/pull/252123. This commit fixes afailing test in enterprise. Task-5212472
This update resolves an issue where the internal note from a subscription wasn't correctly displayed in the list view of upsell orders. The fix ensures that notes are accurately reflected in both form and list views, improving data visibility and order management. This was caused by a technical detail related to how Odoo's ORM handles dependencies.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install Subscription and Studio modules 2. Using Studio, add `internal_note_display` field in the Quotation list view 3. Create a…
Steps to reproduce: ---------------------------------------- 1. Install Subscription and Studio modules 2. Using Studio, add `internal_note_display` field in the Quotation list view 3. Create a Subscription with some text in the Notes tab 4. Confirm it and create/confirm an invoice 5. Create an Upsell from this Subscription → Confirm 6. Open the Quotation list view Observation: ---------------------------------------- The internal note is correctly populated in the form view of the upsell order, but remains empty in the list view. Issue: ---------------------------------------- https://github.com/odoo/enterprise/blob/ba950af4ea21624419cf0cb7bbbe92c678ff7325/sale_subscription/models/sale_order.py#L531-L537 `_compute_note_order`accessed `subscription_id.note_order` recursively, Without the recursive dependency in the decorator, the ORM does not properly resolve the `note_order` chain during batch computation (list view), resulting in an empty `internal_note_display` on upsell orders. Form view worked because fields are fetched lazily, ORM tracks full dependency chain. Solution: ---------------------------------------- Add `recursive=True` on the `note_order` field so the ORM correctly tracks the full dependency chain and to allow the ORM to handle the self-referencing compute without warnings. This ensures correct recomputation in batch contexts such as list views. opw-5346451
This update resolves an issue where incorrect logic was used to handle boolean options in date and time fields. The change ensures accurate representation of these options, preventing potential errors in reporting and scheduling. This aligns with best practices for data integrity within Odoo.
Original PR description
*:appointment,esg_hr_fleet This commit is the counterpart of a community commit which removes wrong usages of `exprToBoolean` to evaluate boolean options in date(time) field widgets and formatters. This commit adapts the impacted archs accordingly. Part of task~6012182
This update improves the Knowledge app by automatically moving linked articles to the trash when an audit report is deleted. This prevents workspaces from becoming cluttered and reduces confusion about article relevance. It's a simple change to maintain a cleaner and more organized user experience.
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 a calculation error in the l10n_ch_hr_payroll module that was preventing accurate annual wage figures from being displayed in payroll reports. The change reintroduces the contractual annual wage, ensuring payroll calculations align with Swiss tax regulations and provide correct employee compensation data. This ensures compliance and accurate reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#109264 Forward-Port-Of: odoo/enterprise#109228
This update fixes an issue where miscellaneous entries within overdue reports weren't being included in the printed reports sent to partners. Now, when a user includes a miscellaneous entry in the follow-up report, all details of the entry – including the amount – are accurately reflected in the report sent to the partner. This ensures partners receive complete information about overdue debts.
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 resolves an issue where the Timesheet Assistant form wasn't properly clearing after deselecting multiple suggestions. Previously, the form remained open. Now, the form will automatically clear and disappear when all suggestions are deselected, ensuring a cleaner user experience.
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 allows users to sign multiple documents directly within the Documents App. Previously, this functionality was limited. The change was implemented to address a reporting issue related to code counting within Odoo, ensuring accurate tracking of customizations.
Original PR description
This commit allows to sign multiple documents directly from the Documents App. This was removed by this commit (df271283cb277b69ea16c3adbfe90cc3a6e3d585) by wrapping the "code" server action into a "multi" one. It was done to avoid the cloc tool from counting the line as a customization, but since the server action is included in odoo path it's excluded from the count. Task-5416998
This update fixes an issue where employees could potentially select holidays from different companies within the Odoo Enterprise system. Now, the Gantt chart for holiday scheduling restricts employee selection to only their current company, ensuring accurate and consistent leave management. This improves data integrity and simplifies the scheduling process.
Original PR description
Task: 6012646
9 changes
Resolved issues and error corrections
This update ensures that users only see the option to 'Insert in spreadsheet' within list view menus if they have the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still access the action, which has now been corrected for improved security and user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes an issue where miscellaneous journal entries weren't appearing in printed follow-up reports, even when marked for inclusion. Now, all relevant entries, including their details, are included in the reports sent to partners, ensuring a more complete overview of overdue accounts. This improves reporting accuracy and partner communication.
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 users without proper permissions could access the 'Insert in spreadsheet' action in the Kanban view. Now, the action is only visible to users with the necessary permissions, and the restriction on inserting records based on grouped m2m fields has been removed, streamlining the process.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This fix prevents a data error that occurred when generating work entries after overtime lines were created. The issue stemmed from an incorrect domain used to unlink overtime lines, leading to a 'ValueError'. This ensures work entries are consistently accessible after overtime generation.
Original PR description
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases…
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases where similar overtime lines have already been generated, but the prevention of duplicating overtime lines is implemented in commit 7bc84a920ba39457cb89cf2b93b2e769060c2854 on community. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of the work schedule to Pacific/Fiji (GMT +12). Set his Work Entry Source to Attendances, and in settings, set an overtime ruleset. 2. On this ruleset, select a rule and select 'From a specific duration', and in the field Duration to Exceed, write 8 hours. 3. Go to Attendances. Create an attendance from 3 am to 3 pm, save and close. 4. Click on the Configuration tab > Rulesets, click on the ruleset and click on Regenerate overtimes. 5. Try to open Work Entries. ### Expected behavior The Work Entries show. ### Unexpected behavior An error occurs: `ValueError: Expected singleton: hr.attendance.overtime.line` ## Origin of the issue When regenerating overtimes, we unlink the previously created overtime lines. However, as the domain to retrieve such lines wasn't set correctly, the overtime line of day 2 wasn't included in the lines to unlink. __ opw-5908447
A bug was preventing authorized users from successfully checking out visitors in the Frontdesk module. The issue stemmed from an incorrect filter within the system's access controls, causing a 'Not Found' error. This update corrects the access control filter, allowing users to complete the checkout process as intended.
Original PR description
## Short functional explanation of the error When a user checks in, a mail is sent in the chatter, containing a button 'Check out Visitor'. When a user who should have access to the Check Out feature clicks on the button, we are redirected to a 'Not Found' page. ## Reproduction Steps 1. Go to Frontdesk. Click on Open Desk and check in a visitor. 2. Go back to the Frontdesk app. Click on visitors. 3. Click on the visitor you just checked in. 4. Click on the 'Check Out Visitor' button in the chatter. ### Expected behavior A page should appear with the text: 'The visitor has been successfully checked out'. ### Unexpected behavior A 'Not found' page pops up. ## Origin of the issue We filter users who can benefit from the check-out feature using groups. However, the group used to perform this filter is written incorrectly, leading to a condition that is always True, and always returning a request not found. __ opw-5937326
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 corrects a bug that caused the Owl charting library to crash when users had multiple work entries of the same type. The fix eliminates duplicate work entry type IDs, preventing the error and ensuring the work entry calendar functions correctly. This improves stability and usability for users managing their work schedules.
Original PR description
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on…
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB) - Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated > If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError** ### Cause of issue: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17 ### Fix: Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`. opw-5953671
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The core logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures accurate and compliant payroll processing for Swiss users.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves a technical issue that prevented basic receipts with long POS names from printing correctly. The problem stemmed from a calculation error when padding text, causing a runtime error. This fix ensures all POS names, regardless of length, can be accurately printed on basic receipts.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
11 changes
Enhancements to existing features
This update allows for multiple liquidity lines when generating checks in the Latin American region. Previously, only one liquidity line was supported, which limited reporting accuracy. This change ensures more precise financial reporting for businesses operating in Latin America, aligning with local accounting standards.
Original PR description
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
Resolved issues and error corrections
This update fixes a technical issue where excessive warnings were being generated due to how Odoo handles URLs. The fix ensures warnings are properly deduplicated, preventing unwanted and duplicated notifications. This improvement addresses a potential performance concern and avoids unnecessary alerts.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252193
This update resolves an issue where the website slides feature wouldn't display content from Google Shared Drives. The fix allows the system to correctly access files in Shared Drives by adjusting the Google Drive API request. This ensures users can seamlessly integrate content from Shared Drives into their courses.
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 'User' role in the Sign functionality incorrectly displayed all partner records instead of users. The code has been updated to use the `res.users` relation, ensuring that users are correctly identified when requesting signatures. This improves the user experience and accuracy of the signature process.
Original PR description
## Issue When requesting a signature from the *"User"* role, the relation being used is `res.partner`, instead of `res.users`. ## Steps to reproduce 1. Install *Sign* (`sign`) 2. Upload a PDF 3. Add…
## Issue When requesting a signature from the *"User"* role, the relation being used is `res.partner`, instead of `res.users`. ## Steps to reproduce 1. Install *Sign* (`sign`) 2. Upload a PDF 3. Add a Signature block, set the *Filled by* field to *"User"* and validate 4. Click *Sign Now* 5. **The User field displays all the existing `res.partner`s, instead of the `res.users`.** <img width="558" height="363" alt="5976810" src="https://github.com/user-attachments/assets/3bee36c8-6bdf-4bb1-8adf-7c3fe0092147" /> ## Cause The field appears in `sign_send_request_views.xml`: https://github.com/odoo/enterprise/blob/9d96ecb2a8049e444823128034d0e57acd61d36a/sign/wizard/sign_send_request_views.xml#L11 and the `signer_x2many` widget is defined here: https://github.com/odoo/enterprise/blob/9d96ecb2a8049e444823128034d0e57acd61d36a/sign/static/src/fields/signer_x2many.js#L37-L51 where the `partner_id` relation is set to `res.partner` instead of `res.users` (since https://github.com/odoo/enterprise/commit/34f72ad06d5). opw-5976810
This update fixes a bug in the MRP module that prevented accurate scrap quantity calculations when some items didn't have a 'Bill of Materials' (BOM) associated. The change ensures all scrap quantities are correctly computed for every item in a recordset, improving inventory accuracy.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A technical issue preventing PDF Quote generation through Quote Builder was resolved. This update replaces an outdated PDF library dependency with a compatible version, ensuring Quote Builder functions correctly and avoids errors when creating PDF documents.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464
This update ensures Odoo invoices sent to the AFIP web service (ARCA) comply with their strict requirements for numeric fields like price and quantity. By limiting precision to 3 decimal places, we prevent invoice rejections and maintain accurate accounting data. This change aligns with AFIP's specifications and Odoo's existing rounding practices.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf)
This update resolves an issue where a small floating-point number was incorrectly displayed in sale order down payment percentages. The fix ensures that percentages are rounded correctly, providing accurate financial data for sales calculations. This improves the reliability of the sales order process.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047
This update ensures that the system correctly accesses company-specific data when generating UY CFEs. Previously, users without specific permissions would encounter errors, preventing CFE validation. Adding `sudo()` access resolves this issue, ensuring accurate CFE creation and processing.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" />
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous billing patterns. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and improving data accuracy. It also includes enhancements for sale moves and PDF generation to prevent duplicates.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#251419This update fixes an issue where manually adjusted lot quantities during manufacturing order production weren't always accurately reflected. Previously, the system incorrectly combined available lot quantities with the manually set quantity. Now, the system correctly consumes the specified lot quantities, ensuring accurate stock tracking and production reporting.
Original PR description
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for…
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for product P with 2 units each - Create a MO for a product consuming two units P and confirm it - On the raw move, manually set 1 unit for each lot - Click on "Produce All" - Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each **Cause** While producing: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line: - Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297 - Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity opw-5946439
7 changes
New functionality added to Odoo
This update adds support for the Slovakian PEPPOL code (0245) within the Odoo accounting system. This is necessary to comply with European regulations related to electronic invoicing and data exchange through the PEPPOL network. The change ensures Odoo can correctly process invoices from and to Slovakian businesses participating in the PEPPOL network.
Original PR description
- Added new code Information: https://docs.peppol.eu/poacc/self-billing/3.0/v3.0.1/ https://docs.peppol.eu/edelivery/codelists/v9.5/Peppol%20Code%20Lists%20-%20Participant%20identifier%20schemes%20v9.5.html OPW-6017742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a problem where Razorpay payments failed due to customer names containing commas or exceeding 50 characters. The fix ensures Razorpay receives only clean names (without commas) and limits them to 50 characters, preventing payment errors and improving compatibility with Razorpay.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay.
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a bug where date formats like '2500/1222' were wrongly identified as '%Y.%m.%d'. The change ensures that import files are processed with the correct date formats, preventing import errors and improving data accuracy.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196477
This update ensures that employee skills are correctly copied to newly created appraisals generated by the automated appraisal process. Previously, the system didn't copy skills when appraisals were created directly in the 'pending' state, leading to incomplete appraisal data. This fix addresses a critical issue ensuring accurate appraisal reporting.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433
This update resolves an issue where emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now handles this attachment type by falling back to a standard format, ensuring all incoming emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a technical problem where screenshots of spreadsheets couldn't be saved correctly, leading to errors. The fix ensures that thumbnails are reliably created even when the spreadsheet is temporarily closed, improving spreadsheet functionality and preventing data loss.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Documentation and clarification updates
This pull request formally welcomes Edilianny Sánchez (edy1192) as a contributor to Vauxoo, a key Odoo module. This update ensures compliance with Odoo's contribution guidelines and legal agreements. It's a standard process for onboarding new developers to our open-source project.
Original PR description
Incorporate Edilianny Sánchez (edy1192) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr