Daily updates from Odoo
Friday, February 21, 2025
31 changes · 18.0
Resolved issues and error corrections
Employees with flexible working hours can now see weekend shifts when opening the planning link from their email. This prevents published weekend assignments from being hidden and helps employees reliably review their full schedule.
Original PR description
### Issue: - When assigning weekend shifts to an employee with flexible hours, the weekend shifts don't appear when clicking on `View Your Planning` of the planning email. ### Steps to reproduce: -…
### Issue:
- When assigning weekend shifts to an employee with flexible hours, the weekend shifts don't appear when clicking on
`View Your Planning` of the planning email.
### Steps to reproduce:
- Create a new employee with flexible hours.
- In the Planning app, create a new shift for the employee on a weekend.-Publish and send the shifts.
- In emails, click on the email sent to the employee, then click `View Your Planning`.
- The weekend shifts don't appear.
### Solutions:
- When clicking on the `View Your Planning` link, the request is processed by the controller at:
`@http.route(['/planning/<string:planning_token>/<string:employee_token>'], type='http', auth="public", website=True)`
- This controller invokes the `_planning_get` method, which in turn calls the `_get_valid_work_intervals` method.
- In the `_get_valid_work_intervals` method, I check if the calendar has flexible hours to return the whole interval.
opw-4378797
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Accounting dashboard now keeps journal card graphs aligned with the bottom of each card, even when cards have different numbers of action links. This fixes a visual inconsistency introduced during a previous redesign and makes the dashboard cleaner and easier to scan.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard - Make sure that one journal has more action links than the other ones of the same row **Issue:** There is an offset between the bottom border of the kanban card and the graph that depends on the difference between the number of action links in the current card and the higher number of action links in a card on the same row.  **Cause:** The view has been refactored in version 18.0 and some css has been lost in the process. opw-4473451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where tax subtotals could be calculated incorrectly when certain taxes were included in the base amount. It helps ensure sales and accounting documents show accurate tax totals for affected scenarios.
Original PR description
… taxes Bug introduced by https://github.com/odoo/odoo/commit/90949cd56da77da3645922f670f86483d7859c2f See tests in this commit for a concrete use case. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now safely handles cases where no text or content is selected in Firefox. This prevents an unexpected browser-specific error, improving editing reliability for users.
Original PR description
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a mobile issue where website visitors lost access to an ongoing live chat after refreshing the page. The chat now remains available as a bubble on mobile, so customers can continue conversations without switching device mode or finding a workaround.
Original PR description
Before this commit, when using livechat by visitor in mobile, any page reload would remove access to the livechat. Steps to reproduce: - access to website with livechat installed on mobile - click on…
Before this commit, when using livechat by visitor in mobile, any page reload would remove access to the livechat. Steps to reproduce: - access to website with livechat installed on mobile - click on livechat button (bubble icon in bottom right) - send a message - reload the page => the livechat is not open, not even as a chat bubble. This prevents visitor from access the livechat again, except if user finds a workaround to open the same page in non-mobile mode (e.g. landscape mode or disabling high-dpi). This happens because livechat relies on discuss chat hub, and there's some code to prevent server-side synchronisation of chat windows and bubbles in mobile. As a reminder, conversation in mobile are shown as fullscreen chat windows. This code was preventing the opening of chat window on livechat for visitor, leading to prevention of continuing to live chat on the device. This commit fixes by adding fold action to chat windows in mobile specifically for livechat visitors, thus allowing to have chat bubbles in mobile. This fixes allow to show chat windows as bubbles to livechat visitors, which is the primary fix of these changes. Due to chat windows being server-synced, we made sure to not sync chat windows in the backend. To do so, we rely on presence of livechat service to determine when the chat bubble feature should work in mobile. opw-4423556 opw-4488830
Users who manage stock can now validate deliveries linked to field service or sales projects even if they do not have Sales app access. This prevents an access-rights error and keeps delivery validation working for operational users without needing extra sales permissions.
Original PR description
Before this commit, when the user validates a stock picking and that user does not have access to sales app, he will get a traceback if `sale_project_stock` module is installed because the `reinvoiced_sale_order_id` field of the project linked to the picking and that field required the user to have sale access to access to it. This commit adds a sudo to generate eventual SOLs to reinvoice the stock move when the user without any access to Sales validates the stock picking. Steps to reproduce the issue: ---------------------------- 1. Create a sales order with a storable product 2. and Service product that creates a task in the Field service project 3. After confirming this SO, a task is created => assign Demo to this task and demo doesn't have Sales access right 4. Login as demo, trying to validate the delivery from this task opw-4590044
This change reverts a previous adjustment to invoice report headers and footers for Latin American invoice documents and Hungarian EDI reports. It helps restore the expected document layout and avoid formatting issues in printed or PDF invoices.
Original PR description
…oter issues" This reverts commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the online checkout from crashing when customers switch between addresses that have different delivery availability. It helps Click & Collect shoppers continue checkout smoothly even when a delivery option is not available for one address.
Original PR description
Steps to reproduce: 1) Install Click & Collect 2) Configure a standard delivery to deliver only to Belgium and publish 3) Unpublish the others 4) Go to /shop page add a storable product 5) Proceed to /checkout add two addresses one with US country, the other with Belgium 6) Try to click on US partner then on Belgium then again on US 7) Observe traceback After this commit we skip the check in _canEnableMainButton if a radio element is not found.
This fixes a problem on Android Chrome where pressing backspace in the HTML editor could remove unintended text or place the cursor in the wrong position. The editor now restores unexpected browser changes so deleting content behaves consistently, helping users edit pages and rich text without losing content.
Original PR description
On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content,…
On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content, considering the editor handles the delete operation and assumes the default behavior is prevented.
The steps below illustrate one of the possible issues.
Steps 1:
a. Have the following html:
```
<h1><span style="font-size: 36px;">Welcome to the To-do app! </span></h1>
<p>
<span style="font-size: 14px;">
Use it to manage your work</span>
</p>
```
b. On Android Chrome, place the cursor at the beginning of the paragraph and press backspace on the device's virtual keyboard.
As a result, the paragraph is merged with the heading, but the characters "Use it to" disappear:
```
<h1>
<span style="font-size: 36px;">Welcome to the To-do app!</span>
<span style="font-size: 14px;"> manage your work</span>
</h1>
```
This example was taken from the "Welcome Mitchell Admin" task in the To-do app, so it's easily testable.
Steps 2:
a. On Android Chrome, have two paragraphs with some text, and place the cursor at the beginning of the second paragraph. E.g.:
```
<p>abc</p>
<p>[]def</p>
```
b. Press backspace on the device's virtual keyboard.
As a result, the paragraphs are merged (as expected), but the cursor is placed in the wrong position, e.g.: `<p>abcd[]ef</p>`, whilst `<p>abc[]def</p>` was expected.
Since the default behavior cannot be prevented, this commit makes sure that eventual DOM mutations and selection changes occurred after the beforeinput event are reverted, aiming to achieve the same effect as preventing default.
task-4243933This fix restores missing header information in certain invoice report layouts for Latin American invoice documents and Hungarian EDI reports. It prevents invoices from being printed or shared with incomplete branding or layout details after a previous change affected the templates.
Original PR description
Commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d introduced a regression that caused `l10n_latam_invoice_document` to lose its header for the striped layout. In addition due to different position of the header img tag in the standard layout template HTML tree, `l10n_hu_edi` also required explicit base standard layout header classes in its attributes. This was caused by the xpath `//img/../..` introduced in f86238d7c872b3f025085831d50f1896168b6274 which thus unintentionally removed these classes opw-4593505
This fix prevents an error that could occur when customers reach the receipt screen after paying online in Point of Sale with discounts, promotions, or loyalty enabled. It updates the payment flow to use the current order identifier, helping checkout complete reliably.
Original PR description
Description of the issue/feature this PR addresses: Steps to reproduce: - Setup a POS - Enable online payment (e.g Demo) - Activate discount, promotion & loyalty in configuration - Place an order in the POS until receipt screen Alternatively, take look at the recording: https://github.com/user-attachments/assets/471e06ae-45d6-4440-a287-7c2433845c26 Current behavior before PR: Odoo will throw an error because the existing field of server_id is not exists anymore, error occurs when post processing loyalty.  Desired behavior after PR is merged: This PR is expected to solve the issue by changing the old server_id with the current id field opw-4584152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where invoice numbers and customer references could appear twice when viewing journal entry lines from aged receivable reports. The change makes report line descriptions cleaner and easier for accounting users to read.
Original PR description
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases. ### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the…
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases.
### Steps to reproduce:
- Go to Accounting > Reports > Aged Receivable
- Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry"
- On the Journal Entry, add the something to Customer Reference
- Go back to the report, you should see the invoice name and Customer reference are shown twice
### Cause:
The bug appeared in this commit (https://github.com/odoo/odoo/commit/eb872c09897eb9edd5b6e5b9e8171fa6764be3dc) when computing the line display_name, if there is a move name, a reference and `line_name`.
The variable `line_name` already include the reference: `name = f'{line.move_id.ref} - {line.move_id.payment_reference}'` (https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7)
So `line_name` is different from `move_name` and the result is: `line.move_id.name (line.move_id.ref) line.move_id.ref - line.move_id.payment_reference`
### Solution:
The previous fix prevents `line_name` from having the same string twice. But it does not fix the issue when the invoice name and Customer reference are different.
This commit checks if `move_name` and `move_ref` are included in `line_name` before adding it to the display name.
This is not optimal as it makes this code dependent on the format of `line_name`.
opw-4492298Odoo now recognizes Worldline's payment rejection response as an expected payment outcome instead of treating it as a connection problem. This makes failed subscription payments, such as those caused by expired cards, clearer and more accurate for users and support teams.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: >…
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: > Automatic payment failed. No email sent this time. > Error: Worldline: The communication with the API failed. > Details: Cause ----- When a payment gets rejected for any reason like card expiration, Worldline returns the 402 HTTP response code[^2]. This is a nonstandard response indicating "Payment Required"[^3]. Because the 4xx HTTP status code range is reserved for client errors, we currently interpret the 402 response as a communication failure with the API instead of a rejected payment. Solution -------- Don't `raise_for_status` if the response belongs to one of the "expected" responses according to their API: - 200: Successful - 201: Created - 402: Payment rejected opw-4481602 [^1]: Wordline doesn't provide a way to easily test rejected payments. [^2]: https://apireference.connect.worldline-solutions.com/s2sapi/v1/en_US/json/response-codes.html [^3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402
Accounting warning messages can now correctly open review links that include multiple view options. This prevents users from hitting an error when following a warning link from the Secure Entries wizard, helping them complete accounting checks without interruption.
Original PR description
When we show a wizard to the user it is possible to add some warnings and redirects to views. However currently an error message will raise when accessing a view with more than 1 view mode Steps to reproduce: - Have entries already secured with hash - Create unreconciled bank statement - Open Secure Entries wizard (Accounting / Accounting / Secure Entries) - Enter a future date - Warning will raise "There are still unreconciled bank statement lines before the selected date. The entries from journal prefixes containing them will not be secured: BNK1/2025 Review" - Click on the Review Link Traceback ``` Uncaught Promise > View types not defined kanban,list found in act_window action 855 ``` This occurs because multiple view_mode are not correctly handled opw-4571921
Uninstalling an industry module now removes all related records, including those that were previously kept because they had duplicate exclusion references. This helps keep databases clean and prevents leftover demo or industry-specific content from remaining after a module is removed.
Original PR description
Steps to reproduce: - Install any industry module; - Uninstall the module; Current behaviour: Some records from the industry module (like a knowledge article) which have a second xmlid from `__cloc_exclude__` remain in the database after the uninstallation. Expected behaviour: After this commit, all records from the industry and their related `__cloc_exclude__` ir_model_data entries are removed. task-4501067
This pull request fixes website translation handling so customized translated text stored in attributes is preserved correctly. It also includes several business-impacting fixes across imports, login caching, inventory reports, accounting, sales expenses, manufacturing dates, hardware naming, and Belgian tax configuration.
Original PR description
Description of the issue/feature this PR addresses: Personalizaciones en las traducciones del sitio web. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where landed costs could be counted twice on product lots when multiple lot-valued products were received together. Lot costs now match the product valuation, helping inventory and cost reports show accurate figures.
Original PR description
Steps to reproduce the bug:
- Create two storable products, P1 and P2:
- tracked by: lot
- Valuated by: lot
- Create a service product, S1:
- is landed cost: True
- value: $100
- Create a receipt:
- unit of P1, unit price: $1
- unit of P2, unit price: $1
- Add the landed cost S1, split by quantity.
Problem:
The cost valuation of the products is then $51 each. The product form
and valuation are displayed correctly. However, if we check the lot,
the cost appears as $101.
This issue occurs because, when validating the landed cost, we have a
dictionary mapping lots to values. Then, we iterate over each product,
but we do not filter the lot dictionary for the current product.
Instead, we traverse the entire dictionary, leading to the lot values
being processed twice.
opw-[4509006](https://www.odoo.com/web#id=4509006&view_type=form&model=project.task)This change adds safeguards to ensure company-specific linked records still exist before they are used. It helps prevent errors when records are removed at the same time another process is trying to reference them, improving reliability for users.
Original PR description
Added existence checks for company-dependent many2one fields to ensure assigned ids are valid and to handle cases where records are deleted concurrently. This prevents potential MissingError issues in the future. 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
Visitors who are not logged in are now politely asked to sign in when they try to react to comments, instead of seeing an access error. This improves the experience on public pages such as course reviews while keeping comment reactions limited to authenticated users.
Original PR description
Public users should not be able to react to comments. This commit politely ask them to log in. Reproduce --- - website_slides - as public - open course review - attempt to react - access error opw-4545596
The guided tour pointer now correctly detects whether a target is off-screen horizontally or vertically. This prevents misleading pointer placement during product walkthroughs, making tours clearer for users.
Original PR description
Before this commit, if an element was out of the screen on the X axis, the pointer was showing as if it was out of the screen in top. Now, it makes the difference between X and Y axis. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores company-based filtering when users choose accounts on invoices, vendor bills, journal entries, and related expense views. It helps prevent users from accidentally selecting accounts that belong to another company, improving data accuracy in multi-company setups.
Original PR description
In `account.move.line` views, the `account_id` fields that have a `domain` attribute need to filter for `company_ids` in the domain, since the check_company domain is overriden by the domain in the field. We removed these domains in odoo#171079 thinking that check_company=True would automatically add them. But it doesn't, so we must revert that change. Otherwise, the user can select accounts that don't belong to the current invoice / vendor bill / journal entry's company. task-none
Swiss payroll payment reports now offer the correct Swiss ISO 20022 format instead of forcing the standard SEPA format. This ensures generated bank payment files match Swiss banking requirements and reduces payment processing issues for Swiss companies.
Original PR description
### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to choose SEPA and by doing this it uses the 'sepa_ct' payment method: https://github.com/odoo/enterprise/blob/033b3f7773e0dd41cb1dfcc5542d19b22f5fe609/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L26 ### Solution: Add a new value to choose from other than SEPA for the Report Format and make this format use the payment method iso20022_ch. opw-4437968
This fix avoids upgrade failures when a related tax report component is not available yet during module loading. It helps ensure smoother upgrades for customers using the Spanish Modelo 130 reporting modules.
Original PR description
During module load, a custom handler coming from a dependant module could be unavailable. Skip the check in such cases. Steps to reproduce: 1. In 17.4 install `l10n_es_reports_modelo130` 2. Upgrade to 18.0 There is an error because the model `l10n_es_modelo130.mod130.tax.report.handler` is not loaded yet. The same error is also observed if we try to upgrade `l10n_es_modelo130` in 18 after installing `l10n_es_reports_modelo130`.
Spreadsheet chart settings now show a loading spinner while chart data is still being prepared. This prevents users from seeing an incorrect error message and makes chart editing feel clearer and more reliable.
Original PR description
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Brazilian fiscal product fields now appear in a dedicated section on the Accounting tab instead of being shown under Ecommerce Shop. This makes product setup clearer for Brazilian companies and avoids confusion when both eCommerce and Brazilian tax localization are installed.
Original PR description
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting,…
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific section inside the accounting group. Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group. **Root Cause** The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly. **Fix** To avoid modifying a module unrelated to Brazilian taxes, which might have a broader impact, the existing behaviour is left unchanged. Instead, a new section has been added within the accounting tab to display the necessary information. This ensures that only the l10n_br_avatax module is modified. Opw-4533760
After splitting a PDF in Documents, the newly created documents are now automatically selected as expected. This makes the workflow smoother and helps users continue working with the new files without manually finding and selecting them.
Original PR description
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273
This fix restores the ability for users to include payments from branch companies in a batch created by the main company. It removes an unexpected company mismatch error, allowing multi-branch payment collection workflows to work as they did before.
Original PR description
Users managing several branch companies may collect in a batch several payments from the branches. However this currently does not work as expected. Steps to reproduce: - Have a [main] company and a [branch] company - Create a payment in [branch] - Create a batch in [main] - Add the payment to the batch Issue: Error will raise ``` Incompatible companies on records: - “PAY00001” belongs to company “Your branch” and “Batch Payment” (batch_payment_id: 'BATCH/IN/2025/0001 (New)') belongs to another company ``` This occurs because now we check that batch and payment belong to the same company It is a change of behavior as in older versions this flows was permitted opw-4574188
A disabled Knowledge app test was updated to match recent changes in the article editor. This helps improve future automated test reliability without changing the user experience.
Original PR description
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158
This update fixes two issues in the Italian point of sale flow: discounted order lines now show the correct reduced price, and fiscal printer receipt formatting is converted more reliably. This helps prevent incorrect customer-facing totals and improves consistency for Italian POS receipts.
Original PR description
- Fix the tags and attributes html to xml replacement to use longest matching - Fix the price calculations when a discount is added to an order line
Odoo no longer blocks SEPA direct debit batches solely because a first collection date is within the usual 5-day notice period. Users now receive a warning in that case, while payments are only blocked when the date is less than 2 days away, helping companies using imported mandates process payments more smoothly.
Original PR description
By default, SEPA requires a 5 day notification period prior to collecting a payment, if no payment has ever been collected using the related mandate. However, it could be that the company used another software before and imported their existing mandates (that have no payments yet in Odoo). In this case, the 5 day period does not apply and can be relaxes to the default 2 day period for running mandates. Instead of blocking the user when their required payment date is not at least 5 days from today (on first-time mandates), we now only show a warning at the top of the form, with links to the related payments. Blocking the user will only happen if the required payment date is not at least 2 days from today. [task-4472278](https://www.odoo.com/odoo/project.task/4472278)
The HTML editor now automatically scrolls to the cursor when typing moves it outside the visible area. This prevents users from losing sight of new content while adding multiple paragraphs, making editing smoother and less confusing.
Original PR description
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr