Daily updates from Odoo
Monday, January 27, 2025
22 changes · 18.0
Resolved issues and error corrections
This fix prevents the website editor from crashing for customers whose custom setup loads only the base jQuery file. Odoo now detects the missing legacy jQuery support and loads it automatically, keeping the editor usable without requiring customer-side asset changes.
Original PR description
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put…
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put `web/static/lib/jquery/jquery.js` in `web.assets_backend` (using custom modules) but not `web/static/src/legacy/js/libs/jquery.js`. Therefore `ensureJQuery` doesn't fetch `web._assets_jquery` and therefore `web/static/src/legacy/js/libs/jquery.js` is never included. __Description of the fix:__ If jQuery is present, check if the method `getScrollingElement` is defined in jQuery.fn. If not load `/web/static/src/legacy/js/libs/jquery.js`. __Steps to reproduce the issue in local:__ 1. Add back "web/static/lib/jquery/jquery.js" in the `web.assets_backend` entry of `addons/web/\_\_manifest\_\_.py` to simulate that a customer added it in a custom module. 2. Open the database and Refresh Assets in the debug menu 3. Try to open the editor Crash: "TypeError: $(...).getScrollingElement is not a function" opw-4499576 [1]: https://github.com/odoo/odoo/commit/b8fc93ea97b8
This fix stops an extra dialog from appearing in Point of Sale when the same register session is already being closed. It helps cashiers avoid confusion during the closing process and keeps the workflow smoother.
Original PR description
check commit message for description.
This fixes the status display for draft accounting entries so they once again appear with the expected blue badge. The change helps users quickly distinguish draft moves in accounting lists after a recent view update accidentally removed that visual cue.
Original PR description
In the account move view, since this commit: https://github.com/odoo/odoo/commit/9b47dd1158b2819c74431f30ff137cbb13ce0d4f We made a new column that is status_in_payment but with that we removed the decoration for draft moves task-4497735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where tables added to chatter messages could lose visible cell borders after being logged or sent. This helps users share formatted information more clearly and reliably in discussions.
Original PR description
**Problem**: When adding a table in the chatter and logging/sending, the table is not displayed properly. This issue is same as: https://github.com/odoo/odoo/commit/99c5a73b2ffc9bef6128059c51574c70cdfc6767. Grouped styles like `border`, `padding`, and `border-radius` do not propagate their values to substyles when variables are used in the value. **Solution**: Apply same fix in `convert_inline` of `mail` **Steps to Reproduce**: 1. Open the full composer. 2. Add a table. 3. Log a note. 4. Observe that `td` borders are not visible. opw-4483477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users are now shown a clear warning when they try to use Print & Send on an invoice that has not yet been confirmed. This prevents a confusing system error caused by draft invoices not having a final invoice number for the PDF filename.
Original PR description
Currently, an error occurs when attempting to print and send an invoice that is in a draft state. Step to produce: - Install the `account` module. - Go to Invoicing / Customers / Invoices, Create one invoice without a customer and invoice line, and come to the list view of Invoices. - Select this invoice and click on 'Print & Send'. `AttributeError: 'bool' object has no attribute 'replace'` The issue occurs because the system attempts to replace the name at [1] to generate a PDF file name. But the invoice's name is not available. Link [1]: https://github.com/odoo/odoo/blob/41de88b930e569daea7624ee3655cef218f9136f/addons/account/models/account_move.py#L5739 To resolve this issue, Raise a user error if the user attempts to select the 'Print & Send' action on an invoice that is not in the confirmed state. Sentry-6185757435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Odoo's spreadsheet engine with several fixes that make formulas, selections, popovers, icons, and grid rendering behave more reliably. It also improves Excel compatibility by preserving data validation rules when importing and exporting spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8c6bd14c [REL] 18.0.11 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1ae4dd4d6 [FIX] TextValueProvider: Avoid…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8c6bd14c [REL] 18.0.11 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1ae4dd4d6 [FIX] TextValueProvider: Avoid duplicate key in template Task: 4483494 https://github.com/odoo/o-spreadsheet/commit/b7a2d6f33 [FIX] formulas: binary search returning incorrect index for multiple exact matches Task: 4328300 https://github.com/odoo/o-spreadsheet/commit/a23b0534c [FIX] selection: drag and drop resized cols and rows Task: 4454025 https://github.com/odoo/o-spreadsheet/commit/6dae73692 [FIX] popover: wrong position on updated popover Task: 3814260 https://github.com/odoo/o-spreadsheet/commit/96928270e [FIX] Selection: selection follows the moved header Task: 4461901 https://github.com/odoo/o-spreadsheet/commit/6405df3ce [FIX] icons: Missing dimension on icon Task: 4461359 https://github.com/odoo/o-spreadsheet/commit/a0401a35f [IMP] xlsx: support import/export of data validation rules Task: 4505529 https://github.com/odoo/o-spreadsheet/commit/f0537e96b [FIX] GridComposer: Fix CellReference pill display Task: 4501136 https://github.com/odoo/o-spreadsheet/commit/eccd9fa51 [FIX] renderer: Fix grid rendering Task: 4448426 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes an issue where users could not edit the description of a newly added service line on a confirmed sales order. The change keeps order line descriptions editable when appropriate, reducing friction when updating confirmed orders.
Original PR description
Steps: - Install sale_project - Create a service type product - Create a SO and confirm it - In the confirmed order add a SOL with the new product Issue: - cannot edit the description of the new SOL Cause: - readonly for the SOL is set based on product_updatable and product_updatable is set false when product type service even for new order line Fix - Updated the readonly condition to account for new lines opw - 4473488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a timing issue that could crash the app if a user opened a related record and navigated away before the view finished loading. The change makes the interface safely ignore late-loading results for screens that are no longer active, improving reliability during normal navigation.
Original PR description
Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`. This could be reproduced in a form view with an x2many field, whose form view isn't inline (i.e. needs to be fetched when a record is clicked). In such a form view, click on a record in the x2many, then, during the call to `get_views`, toggle the home menu (for instance). 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
Sales order combo items now allow users to update the delivered quantity, not just the description and taxes. This fixes an editing limitation so delivered amounts can be corrected directly when needed.
Original PR description
Previously, only the description and taxes could be edited on combo item SOLs. However, the delivered quantity should also be editable. opw-4454205
This fixes an issue where employees on flexible working schedules could see a one-day leave request counted as two days. Time off calculations now update once the schedule's daily hours are available, helping keep leave balances accurate.
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Since 'calendar_id.hours_per_day' will be equal zero at first we should re-compute the duration of periods when this field gets a value. opw-4309551
Manufacturing orders created or partially produced in the Barcode app no longer crash when Lots & Serial Numbers is disabled. This prevents an interruption for warehouse users working without lot tracking enabled.
Original PR description
Before this commit, creating or partially producing an MO within the Barcode app gives a traceback if the "Lots & Serial Numbers" option is not set.
Steps to reproduce
-----
1. Inventory > Configuration > Settings > uncheck Lots & Serial Numbers
2. Barcode > Operations > Manufacturing > New > Add any product and Confirm
3. Traceback occurs
```
TypeError: Cannot read properties of undefined (reading '0')
at MainComponent.saveFormView
```
Cause
-----
Normally if `lot_producing_id` on the MO is False, then `lineRecord.data.lot_producing_id` is also false. But with the Lots & Serial Numbers option unset, `lineRecord.data.lot_producing_id` becomes undefined instead.
Solution
-----
Add an optional chain to handle the possible nullish value.
opw-4460956The Sign app now sends users back to the project they came from after completing a signature request. This avoids opening an unnecessary new wizard and makes the workflow smoother for project users.
Original PR description
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button redirects correctly to the project view. task:4431882
Users could hit an access error when sending a document for signature if another user had already uploaded the same file in Documents with view-only access. The fix links sign requests to the exact uploaded attachment instead of another document with the same file content, so signing works reliably for internal users.
Original PR description
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document…
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another internal user (ie. Mark Demo) and upload the same document as a sign template in the Sign app. 4. set the template's `signed document folder` to the same folder as the document uploaded by Mitchell Admin. 5. attempt to send the document for signing. 6. an access error is raised. ### Solution: - Prior to the fix, the `create` method, relied solely on matching the `checksum` of the `sign_requets` attachment with existing documents which resulted in documents not related to the sign request being set as the `reference document`. - The fix now gets the correct document by searching for documents with the same `attachment_id` as the sign request's template attachment. OPW-4421368
The US payroll payslip report now handles hourly payslip lines with zero worked hours without causing an error. This prevents a server crash when printing affected payslips and keeps payroll reporting available for edge cases or corrections.
Original PR description
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500…
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 for any worked line. - Click on 'Print' button. - 500 Internal Server Error. ### Solution: - Issue introduced here https://github.com/odoo/enterprise/commit/935b23cfe74741d1168d93add8c7a221b5168021#diff-6133beb42a4aef7b7c8e1a19738d1fd2689e40e98a2e4e34c0ad4bf12eb2e1b3R52 `worked_days.amount/worked_days.number_of_hours` cause a division by zero if `worked_days.number_of_hours` is 0. - I've updated the template to handle the case. so now If the value is 0 or less, it simply returns 0 instead of dividing. opw-4478495
Changing the date in the duplicate transaction finder no longer causes an error when results appear after an empty state. This makes the bank synchronization workflow more reliable for users reviewing potential duplicate transactions.
Original PR description
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by removing the obsolete `firstIdsInGroup` field and adding a condition to ensure that the value being checked is an array, preventing any traceback. no task id
Fixed an issue where large PDFs could appear as a blank white viewer when preparing or signing documents. This improves reliability for users working with longer agreements or multi-page documents in Odoo Sign.
Original PR description
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and the PDF appears correctly. The exact problematic value depends on browser and environment, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size Solution ----- Use a maximum canvas size but keep the styling of the canvas element to cover all the PDF viewer. This means a scaling factor needs to be applied to the position of the sign items between which the lines are drawn. opw-4407698
Financial report rows and columns will now keep the intended order automatically during database upgrades. This prevents reports from appearing in an unexpected sequence if the underlying report definitions change, reducing manual maintenance and upgrade risk.
Original PR description
Having no manual sequence on report lines/columns might be problematic in case of DB upgrade, if the line order changed in the xml files, as the report won't adapt and update the sequence field. Setting auto_sequence will ensure that this won't ever be a problem anymore (and avoid the tedious task of manually setting the sequence on each line/column)
This fix ensures subscription invoice lines use the correct quantity when billing products based on ordered quantity, especially around future or deferred billing periods. It prevents incorrect invoiced quantities from being calculated from future subscription periods, improving billing accuracy for subscription customers.
Original PR description
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past.
Tax closing messages now show a clickable link to the related main closing entry instead of displaying raw HTML text. This makes it easier for accounting users to navigate between dependent tax closing entries and their parent entry.
Original PR description
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged message. [this commit]: https://github.com/odoo/enterprise/commit/09f5b35493bee7b63e96e8b28ad741aeb5ee80e5
Reconciled batch payments no longer appear as available options during bank reconciliation. This prevents users from accidentally seeing or selecting payments that have already been matched, keeping the reconciliation workflow clearer and more accurate.
Original PR description
### Steps to reproduce: - In Accounting, create a new Customer invoice - Create a payment for this invoice - In Customer > Batch Payments create a new batch payment - Select the payment you created - In the Dashboard click on the three dots of the "Bank" block and click on transactions - Create a new transaction with the same amount as the invoice - Click "Match" on the right - In the "Batch Payments" tab select the Batch payment previously created - Validate - Back in the Dashboard, click on the reconcile button of the Bank block - In the "Batch Payments" tab the batch payment is still here even if it is reconciled ### Cause: There are no domain to filter the batch payments. ### Solution: Add a domain to check the state of the batch payments, do not display if it is "reconciled". opw-4461341
Opening the Documents app after switching to mobile view no longer triggers an error. This improves reliability for users who access documents from phones or resized browser windows without needing to refresh the page.
Original PR description
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view. Task-4437768
Fixes subscription invoices so their start and end dates reflect the actual billing period, especially when invoicing after delivery. This helps prevent incorrect deferred revenue periods and gives customers and finance teams more accurate invoice information.
Original PR description
The deferred start date (start date) relied on either the `last_invoice_date` or the `order_id.last_invoice_date`. If both were unset, the start date of the invoice was not defined, leading to…
The deferred start date (start date) relied on either the `last_invoice_date` or the `order_id.last_invoice_date`. If both were unset, the start date of the invoice was not defined, leading to incorrect calculations. The deferred end date (end date) was always set to "today" because the calculation used the earliest date among "today," the theoretical stop, or the subscription end date. As "today" is always the earliest, the end date incorrectly marked the current date as the last day of the billing period. The deferred start date should be based on the last invoiced date or the subscription start date as a fallback. The deferred end date marks the last day of the billing period it should be the earliest between: - The end date of the current invoicing period (theoretical stop) - The subscription's end date (if set) Steps to Reproduce: Setup Product with Subscription and Inventory Tracking: Go to Sales > Products and create a new product. Enable Subscription for the product. Enable Track Inventory for the product. Set Invoicing Policy to either "Ordered Quantity" or "Delivered Quantity" based on the scenarios below. Scenario 1: Invoicing Policy - "Ordered Quantity" (No bug here) Create a Sales Order with the product and confirm it. Generate the invoice. Expected and actual Behavior: The Start Date and End Date on the invoice should be correctly populated and correspond to the subscription period. Scenario 2: Invoicing Policy - "Delivered Quantity" Create a Sales Order with the product and confirm it. Deliver the product. Generate the invoice. Actual Behavior:The Start Date and End Date on the invoice are both incorrect. OPW-4458048