Daily updates from Odoo
Friday, February 21, 2025
74 changes · 18.0
Enhancements to existing features
Invoice lists can now be searched using the total invoice amount. This makes it easier for users to quickly find specific invoices when they know the amount but not other details.
Original PR description
It would help people to be able to search on the Total amount for invoices task-4575021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale order amounts now use the currency linked to each session, so values display and behave according to the right monetary precision. This improves consistency for businesses using different currencies and simplifies related quality checks.
Original PR description
check commit message for description
The Indian e-invoicing module now rejects pincodes outside the valid government-defined range, such as 000000. This helps prevent invalid partner address data from causing issues during e-invoice submission.
Original PR description
As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character Before this commit- if a partner with pincode `000000` then no validation error After this commit- if a partner with pincode `000000` invalid pincode validation raises 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
Automated guided tour tests now better detect unstable page behavior by waiting briefly after finding a target and confirming it remains visible and unchanged. This helps reduce unreliable test results and improves confidence in product quality checks.
Original PR description
in this commit, we improve the method to look for indeterminisms in the tours. The method waits a certain amount of time once the trigger has been found and then checks if the element is still visible, if it has changed or if it has undergone mutations. We take advantage of this commit to also improve the method to find the trigger in the DOM (we check that body does not have the class o_is_blocked and that the frame is is-ready=true if the element is in an iframe)
This update prevents errors caused by company-specific fields pointing to records that no longer exist. It improves reliability when loading or comparing these values, reducing unexpected disruptions for users working across companies.
Original PR description
When using JSONB for company-dependent many2one fields, references to non-existing records in the comodel can lead to MissingError. This commit introduces validation during fetch and comparison by taking advantage of index-only scan to ensure that referenced records exist. 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
The point of sale system now includes a dedicated way to apply discounts during sales flows. This helps make discount-related actions more consistent and easier to reuse in the checkout experience.
Original PR description
add a function to add discount
The Knowledge app now relies on the shared HTML editor for content migration instead of maintaining its own migration logic. This reduces duplication and helps keep Knowledge, Website Knowledge, and related features aligned with the standard editor behavior.
Original PR description
This commit moves the html_field migration system to the standard. See implementation in 0df669159aaa1a9631ab12a68758bf78954071f7. Removing the Excalidraw command means that the html migration system must be moved to `html_editor`. This commit thus removes the sytem from Knowledge and adapts the manifests to take into account the move done, and updates a test to account for the new html editor version (1.1). task-4489076
Customer follow-up reports now use a dedicated statement format that focuses on the current year and only includes customer invoices. The report separates invoices that are due from those that are overdue, making payment follow-up clearer and less confusing for customers.
Original PR description
Instead of sending a confusing customer statement that includes invoices from the last period regardless of their status. Adding a new Partner ledger variant that will be sent as a follow-up report that provides the current year's customer statement including only customer invoices with separating Due and OverDue invoices. task-4454196
After pairing an IoT Box, users can now configure eligible devices for a selected Point of Sale directly from a popup. This reduces manual setup work for barcode scanners, customer displays, and receipt printers, making store onboarding quicker and easier.
Original PR description
To configure IoT Devices in a PoS we needed to pair the IoT Box, then go to PoS configuration and select devices (barcode scanner, customer display, receipt printer) one by one. We now display a popup right after IoT Box pairing, allowing autoconfiguration of eligible devices in the wanted PoS. Task: 4585446
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
Features or functions removed from Odoo
The HTML editor now includes a system to update older embedded content automatically when pages or fields are opened. Existing Excalidraw drawings are converted into standard links because the embedded drawing service had restrictive usage requirements that limited normal users.
Original PR description
This PR adds the migration system previously implemented in Knowledge to update embedded components inside the html field/viewer, see odoo/enterprise@0df669159aaa1a9631ab12a68758bf78954071f7. It also makes use of it to replace excalidraw embedded components by normal links. task-4489076
Miscellaneous changes
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, lead
Original PR description
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the…
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, leading to inconsistent URLs. Steps to reproduce: 1. Context: The database has two companies, Company A and Company B, each with their own custom domains, Domain A and Domain B. 2. Log in to the database using Domain A. - Post a link via social marketing for Company A. The short URL will use Domain A. 3. Switch to the Company B. - Post the same link via social marketing for Company B. The short URL will now incorrectly use Domain A instead of B. While the short URL still redirects to the correct content, the domain in the short URL is inconsistent and depends on the last logged-in domain. OPW-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194331
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state t
Original PR description
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state to saas18.1, where each unit points to its reference as a parent. Having multiple references in the same category caused a having a cycle in this link. See: https://github.com/odoo/upgrade/blob/master/migrations/uom/saas~18.1.1.0/pre-migrate.py#L16-L25 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197634
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
Original PR description
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
Original PR description
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Pr
Original PR description
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Project Stage feature 4. Go to Project > Configuration > Projects 5. Click on new button to create a new project 6. Set the project name and click on the second project stage Current Behavior: ---------------- The project goes back to the default stage instead of staying in the stage selected by the user. Expected Behavior: ----------------- The project should be in the stage selected. Forward-Port-Of: odoo/odoo#198452
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close t
Original PR description
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing…
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close the session and check the cost of the products in the order > Observation: The cost for P3 is incorrect, it should be 100 but it is 200. Why the fix: ------------ When selecting the stock moves line to consider for the cost of the PoS order, we need to select the stock moves that are related to the BoM lines of the original product. In the previous code we were only relying on the product id, and this was causing the issue because some products can have the same product id but used in different BoM lines. opw-4201935 Forward-Port-Of: odoo/odoo#198036 Forward-Port-Of: odoo/odoo#193717
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an e
Original PR description
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198492 Forward-Port-Of: odoo/odoo#196106
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
Original PR description
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: - P1 -> 2 units - P2 -> 2 units - Validate the receipt and create a backorder. Problem: A picking is validated with only 2 units of P2, and a backorder is created with 5 units of P1 and 3 units of P2, instead of correctly validating the picking with: - P1 -> 2 units -
Original PR description
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: -…
Steps to reproduce the issue:
- Create a storable product P1.
- Create a subcontracted product P2.
- Create a receipt with 5 units of P1 and P2.
- Mark it as To Do.
- Set the quantities as follows:
- P1 -> 2 units
- P2 -> 2 units
- Validate the receipt and create a backorder.
Problem:
A picking is validated with only 2 units of P2, and a backorder is
created with 5 units of P1 and 3 units of P2, instead of correctly
validating the picking with:
- P1 -> 2 units
- P2 -> 2 units
And creating a backorder with:
- 3 units of P1
- 3 units of P2
This occurs because, when updating the move for P2 from 5 to 2, a move
line is created and marked as picked. As a result, when computing the
picked value for the move, it is also marked as picked:
https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock/models/stock_move.py#L206-L207
Thus, when validating the picking, since only the move for P2 is marked
as picked, it is the only one that gets validated.
opw-4357997
Forward-Port-Of: odoo/odoo#189481Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Original PR description
Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197589 Forward-Port-Of: odoo/odoo#197502
Original PR description
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197589 Forward-Port-Of: odoo/odoo#197502
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. I
Original PR description
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. Instead, while the MO isn't started yet, we can simply compare to the demand to see if there's enough reservation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198593
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it
Original PR description
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking. OPW-3919976 Forward-Port-Of: odoo/odoo#198601 Forward-Port-Of: odoo/odoo#196161
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.
Original PR description
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages. * `python3-cryptography` is installed by `python3-openssl` * `python3-idna` and `python3-urllib3` are installed by `python3-requests` * `python3-markupsafe` is installed by `python3-jinja2` Forward-Port-Of: odoo/odoo#198102 Forward-Port-Of: odoo/odoo#197302
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
Original PR description
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish s
Original PR description
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish status, which was previously missing in [1](https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e). This update guarantees that the notification appears only when necessary. task- 4046471 Forward-Port-Of: odoo/odoo#173793
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attach
Original PR description
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attachments/assets/df32dbc8-d042-4802-a9b4-2f3d93e97963" /> Forward-Port-Of: odoo/odoo#198320
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross com
Original PR description
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross compare opw-4481596 Forward-Port-Of: odoo/odoo#198480
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79515 Forward-Port-Of: odoo/enterprise#76341
Original PR description
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79515 Forward-Port-Of: odoo/enterprise#76341
The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 Forward-Port-Of: odoo/enterprise#79111
Original PR description
The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 Forward-Port-Of: odoo/enterprise#79111
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
Original PR description
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invo
Original PR description
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invoice and payment amounts (`invoice_amount / payment_amount`). This approach removes rounding discrepancies and ensures consistent values in the XML, preventing these rejections. Forward-Port-Of: odoo/enterprise#79038
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will
Original PR description
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection. Forward-Port-Of: odoo/enterprise#79797
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Original PR description
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
Original PR description
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
Original PR description
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Original PR description
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Forward-Port-Of: odoo/enterprise#79660
Original PR description
Forward-Port-Of: odoo/enterprise#79660
See commits :-) Forward-Port-Of: odoo/enterprise#79621 Forward-Port-Of: odoo/enterprise#79264
Original PR description
See commits :-) Forward-Port-Of: odoo/enterprise#79621 Forward-Port-Of: odoo/enterprise#79264
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Original PR description
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create arti
Original PR description
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create article without any errors. Also prevent unnecessary write on empty recordset. Task-4414401 Forward-Port-Of: odoo/enterprise#76349
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will
Original PR description
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags. After this commit: the line break is there and the words are not join together anymore. OPW-4079729 Forward-Port-Of: odoo/enterprise#78307 Forward-Port-Of: odoo/enterprise#73727
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efa
Original PR description
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called,…
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efabfed5c1 Before: 3.51s (`_create_checks`) - 17493 queries (total queries of the script, not for the single operation)  After: 2.08s (`_create_checks`) - 16103 queries (total queries of the script, not for the single operation)  Comparison of the time taken by Confirming the MRP Order (using `time.process_time()`) | n_components | before (s) | after (s) | ratio | | --- | --- | --- | --- | | 1 | 0.074 | 0.073 | 0.988 | | 5 | 0.134 | 0.140 | 1.042 | | 10 | 0.216 | 0.187 | 0.862 | | 20 | 0.334 | 0.304 | 0.908 | | 50 | 0.736 | 0.600 | 0.816 | | 100 | 1.378 | 1.172 | 0.851 | | 200 | 2.739 | 2.374 | 0.867 | Forward-Port-Of: odoo/enterprise#66224 Forward-Port-Of: odoo/enterprise#65725