Friday, February 21, 2025
52 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)
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
Resolved issues and error corrections
The 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
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
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 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 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-4492298This 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 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
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
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
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