Friday, May 30, 2025
49 changes
12 changes
Resolved issues and error corrections
Corrected a display issue where AI-related dropdown items could appear on top of pop-up dialogs, such as custom filter windows. This makes the interface clearer and prevents menus from blocking important dialog content while keeping the AI chat window visible when needed.
Original PR description
Steps to reproduce: - Install any module with exposed views (say sale_management) and the ai module. - Open any list view (say the Quotations) and type something in the search bar. - Dropdown menu…
Steps to reproduce: - Install any module with exposed views (say sale_management) and the ai module. - Open any list view (say the Quotations) and type something in the search bar. - Dropdown menu items will appear and click "Custom Filter" button from the items. - [ISSUE] The items are shown over the custom filter dialog. The issue is caused by the custom rules introduced in the ai module. In this commit, we're removing all the custom rules that overrides the overlay items. We shouldn't be controlling the `z-index` of those items. To ensure that the AI ChatWindow is still above the dialog that opens it, we reduce the `z-index` of the dialog to `$zindex-sticky=1020` (from `zindex-modal=1055`) and change the `z-index` of the ChatWindows to `$zindex-sticky + 1`. This works because the `.o-mail-ChatWindow` elements lives in the same "stacking context" as the `.o-overlay-item` that contains the dialog. In the dom (and in terms of stacking context) it roughly looks like the following: - html (root stacking context) - .o-overlay-item:has(.o_dialog) (z-index=1020) (under .o-overlay-container) - .o-mail-ChatWindow (z-index=1021) (under .o-mail-ChatHub) - .o-mail-ChatHub-bubbles (z-index=1020) With the above `z-index` values, the stacking will be: - .o-overlay-item:has(.o_dialog) - .o-mail-ChatHub-bubbles - .o-mail-ChatWindow (top most) The bubbles are not visible when the chat window is open, and when the chatwindow is minimized, the bubbles is still visible because it's above the dialog.
Closing the AI agent chat window no longer triggers an error. This improves the user experience by preventing a disruptive message when users dismiss the chat.
Original PR description
**Current behavior before PR:** Closing the AI agent chat window would throw an error because the code attempted to access the associated chatwindow after it had been deleted. **After this commit:** The issue is resolved by ensuring the chatwindow is not accessed after deletion, preventing the error.
This update corrects an automated test for UrbanPiper point-of-sale order handling so it selects the intended order during validation. It prevents test confusion caused by similar-looking order and session numbers, helping maintain confidence in the order flow.
Original PR description
In this fix, I updated the parameters passed to the `selectOrder` and `orderHasText` functions. Instead of using 3-digit sequence numbers (e.g., "001", "002"), I switched to 4-digit formatting (e.g., "0001", "0002") to avoid conflicts with the `session_id`, which was causing the wrong `order-row` to be selected. runbot-163111
Web Studio now handles button action setup correctly when users work in non-English languages. This prevents an error that blocked adding a method to a button and keeps the experience consistent with English.
Original PR description
Error occurs when adding method for a button via web studio for non-english translations. **Steps to reproduce:** * Install `web_studio` and change language to any `non-english` language * via Settings>Translations>Languages (we will use french) * Go to Apps>Any App>DropDown>`Info sur le module`>Studio>`Ajouter un bouton` * Select button>`Que doit faire le bouton?`>`Appeler une methode` * Mode> `button_immediate_install` `ValueError: not enough values to unpack (expected 2, got 1)` **Solution:** * This error does not occur in English translation instead it raises a `ValidationError` so we apply its logic to translated version as well. * We do this by removing `_t` from value in JS this would prevent translation of function name as function names are in English. **Sentry-6608410350**
Miscellaneous changes
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86678 Forward-Port-Of: odoo/enterprise#86499
Original PR description
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86678 Forward-Port-Of: odoo/enterprise#86499
13 changes
Enhancements to existing features
Studio exports now exclude inactive records, so exported data better reflects what users actively work with. This reduces clutter and helps teams avoid sharing or importing outdated inactive entries.
Original PR description
**Purpose:** - Exported data from the studio includes inactive records. **Specifications:** - Only active records should be exported. task-4285741
24 changes
Enhancements to existing features
The Knowledge app now hides the expand caret when an article has no child pages. This reduces visual clutter and avoids suggesting there is more content to open when there is not.
Original PR description
Hide the caret icon when the article has no children. task-4830534
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#86426 Forward-Port-Of: odoo/enterprise#73908
Original PR description
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#86426 Forward-Port-Of: odoo/enterprise#73908
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
Original PR description
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212
Forward-Port-Of: odoo/enterprise#86532
Forward-Port-Of: odoo/enterprise#85891*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to
Original PR description
*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86513 Forward-Port-Of: odoo/enterprise#86397
When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data. Steps to reproduce: --- - Install `hr_recruitment_sign` module - Recruitment > Applications > All Applications - Create New and in action button `Request Signature` Traceback: --- ``ValueError: Invalid field 'mobile' on model 'res.partner'`` The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this modul
Original PR description
When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data. Steps to reproduce: --- - Install `hr_recruitment_sign` module - Recruitment > Applications > All Applications - Create New and in action button `Request Signature` Traceback: --- ``ValueError: Invalid field 'mobile' on model 'res.partner'`` The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this module. This commit cleans it up to avoid referencing a non-existent field. commit- https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be sentry-6588612861 Forward-Port-Of: odoo/enterprise#84784
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86624 Forward-Port-Of: odoo/enterprise#86275
Original PR description
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86624 Forward-Port-Of: odoo/enterprise#86275
Miscellaneous changes
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
**Steps to reproduce:** - Install Planning app - Set the type of view to Gantt - (Create a shift if there is none) - Click on `Publish` button - The period end date doesn't take the last day into account (time is 00:00) **Issue:** Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring: Previously used: ``` export function computeRange(scale, date) { let start = date; let end = date; if (scale === "week") {
Original PR description
**Steps to reproduce:** - Install Planning app - Set the type of view to Gantt - (Create a shift if there is none) - Click on `Publish` button - The period end date doesn't take the last day into…
**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)
**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring:
Previously used:
```
export function computeRange(scale, date) {
let start = date;
let end = date;
if (scale === "week") {
// startOf("week") does not depend on locale and will always give the
// "Monday" of the week... (ISO standard)
const { weekStart } = localization;
const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
start = start.set({ weekday }).startOf("day");
end = start.plus({ weeks: 1, days: -1 }).endOf("day");
} else {
start = start.startOf(scale);
end = end.endOf(scale);
}
return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
const startDate = localStartOf(date, rangeId);
const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
return { focusDate: date, startDate, stopDate, rangeId };
}
```
**Fix:**
Added `localStartOf` function in the context setup of PlanningGanttModel.
To avoid overwriting current changes for other modules (which could be intended), this was done instead of :
```
export function getRangeFromDate(rangeId, date) {
const startDate = localStartOf(date, rangeId);
const stopDate = localEndOf(startDate, rangeId);
return { focusDate: date, startDate, stopDate, rangeId };
}
```
related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c
opw-4580458
Forward-Port-Of: odoo/enterprise#86437
Forward-Port-Of: odoo/enterprise#85608pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to
Original PR description
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to the preparation display opw-4754522 Forward-Port-Of: odoo/enterprise#84943 Forward-Port-Of: odoo/enterprise#84870
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest.
Original PR description
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86609 Forward-Port-Of: odoo/enterprise#86397
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
Original PR description
After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212
Forward-Port-Of: odoo/enterprise#86532
Forward-Port-Of: odoo/enterprise#85891Purpose: Splitting QR codes should not be done in documents. They are unusable if broken and some of them have legal impications. Problem Cause: If the QR code is contained in `<div>` that has class `row`, the css property `display: flex;` would cause it to be split among pages when needed. All EDI modules with QR codes were visited, but the problem was only spotted in Mexico and Peru. Solution: `<div>` containing QR codes and having `row` class should also have class `avoid-pa
Original PR description
Purpose: Splitting QR codes should not be done in documents. They are unusable if broken and some of them have legal impications. Problem Cause: If the QR code is contained in `<div>` that has class `row`, the css property `display: flex;` would cause it to be split among pages when needed. All EDI modules with QR codes were visited, but the problem was only spotted in Mexico and Peru. Solution: `<div>` containing QR codes and having `row` class should also have class `avoid-page-break-inside` task-4756331 Forward-Port-Of: odoo/enterprise#85038
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86666 Forward-Port-Of: odoo/enterprise#86275
Original PR description
odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86666 Forward-Port-Of: odoo/enterprise#86275
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Original PR description
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 Forward-Port-Of: odoo/enterprise#86119
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This is misleading, as by-products are outputs of a production process and should reference a destination location. Steps to Reproduce: ============================ - Install the stock_barcode_mrp module. - Activate multi-step routes and By-Products. - Create a Manufacturing Order with by
Original PR description
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This…
Issue Before This Commit:
============================
In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.
Steps to Reproduce:
============================
- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
- The lines are grouped by Source Location.
- If you edit by-product line then user has option to edit source location.
- If the MO operation type has Source Location scan as mandatory,
user can't edit by-product line.
With This Commit:
============================
- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
users can still edit by-product lines.
This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.
task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)
Forward-Port-Of: odoo/enterprise#86608
Forward-Port-Of: odoo/enterprise#83617Forward-Port-Of: odoo/enterprise#86179
Original PR description
Forward-Port-Of: odoo/enterprise#86179
Resolved issues and error corrections
A point of sale test now creates its branch company with the required country information. This prevents an unrelated certification check from interrupting the test, helping keep automated quality checks reliable.
Original PR description
The test `test_pos_branch_account` was failing due to a `UserError` raised from the `l10n_de_pos_cert` module, which requires that a country be set on the company before opening the POS UI (`open_ui`). Since the test creates a new `res.company` record to represent a branch, the required `country_id` was missing, causing the test to crash instead of evaluating the intended logic. This change sets the `country_id` on the created branch company. build_error-223267
This fixes an issue where using Ctrl+Enter in a Point of Sale text dialog could confirm the action twice. For restaurant users, this prevents duplicate items such as two floors being created from a single entry.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale settings now prevent users from creating a new cash rounding method directly from the POS configuration screen. This ensures rounding methods are set up through the proper accounting form, reducing errors during cash in/out operations and session closing.
Original PR description
Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session). task-id: 4805617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The change updates an internal website shop loyalty test so it is not affected by tax settings that include taxes in product prices. This helps keep automated checks reliable across different configurations without changing customer-facing behavior.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Install `website_sale_loyalty` without demo data; 2. configure taxes to be included in the price; 2. run `test_apply_coupon_with_multiple_rewards`. Issue ----- Test fails. Cause ----- The test compares the product's list price to the order subtotal. With `price_include` set to `True`, the product's `list_price` does include taxes, making the comparison invalid. Solution -------- Explicitly set `taxes_id` to `False` on products created for the test. Also ensure the pricelist & partner don't change in the test. runbot-223362
This update corrects internal test checks for sales, purchasing, and stock transfer flows so they validate the right delivery steps. It helps prevent incorrect assumptions about shipments and internal transfers from hiding future issues.
Original PR description
The pick pickings are incorrect, because we get them from the next transfers of... the receipts. All next steps are wrong (some of the shippings are actually internal pickings) OPW-4552316
The html editor module metadata no longer lists the author as lowercase "odoo" and will instead use the standard company name, Odoo S.A. This is a minor cleanup that keeps module information consistent and professionally presented.
Original PR description
Author was set as "odoo" (lowercase). This commit removes the author key so it fallbacks to the default one, i.e. Odoo S.A. This also aligns keys with previous commits like 42bad1a6 and ef7005f5. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The rental search block now sends selected product attributes in the format expected by the shop page. This ensures customers see properly filtered rental results when using configured attribute options, reducing confusion and improving product discovery.
Original PR description
Description: Currently, when an attribute is selected in the Rental Search snippet options, the generated URL uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`, so the filter is not applied correctly and the search results are not filtered as expected. Steps to reproduce: - Add the "Rental Search" snippet to a website page. - Configure the snippet and select an attribute value in the snippet options. - Check the resulting URL: it uses the incorrect `attrib` param, so the filter does not apply on /shop.
This update makes an automated field service worksheet test wait for a pop-up to open before interacting with it. This reduces false test failures caused by timing issues, helping keep releases and quality checks more reliable.
Original PR description
The fsm_task_form_tour tour was failing because the modal was not open when the test tried to select the element. This change add a wait step was to ensure the modal is open before trying to select the element. Avoiding flaky behavior caused by timing issues in the UI. build_error-163017
Documentation and clarification updates
This pull request records a signed contributor license agreement for the contributor elierwclik. It supports the project's legal compliance process and does not change product features or user workflows.
Miscellaneous changes
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". ## Expected behavior: The original SO picking should have been cancelled, i.e. in st
Original PR description
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory…
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". ## Expected behavior: The original SO picking should have been cancelled, i.e. in state 'cancel', and only the PoS picking should be "Ready". ## Why that happens: When settling the SO from PoS, that will create a new order from PoS with its associated PoS picking. While doing that, we also confirm the original SO [1], changing its state from 'draft' to 'sale', and that will create a move and a picknig associated with that SO, both in state 'confirmed'. So at this point, we're heading toward having 2 pickings, one from the PoS order and the other from the SO, both in state 'confirmed', which is undesired! What we want is having the SO's picking in state 'cancel', and the picking from PoS in state 'confirmed' (since we have settled the order from PoS). To achieve this behavior, we check if the quantity delivered on the SO (i.e. `so_line.qty_delivered`) compensates for the qty that should be deliverd, i.e. for `so_line.product_uom_qty` [2], and if so, we cancel the SO picking ([3], [4]). However, if the order is "ship later", the `so_line.qty_delivered` will be 0 at first, and will only get updated when the picking has indeed being shipped [5], resulting in `new_qty` always being a positive number, and hence also the `product_uom_qty` on the SO pikcing [6], meanign that the SO picking will not qualify to be cancelled. ## The fix: Now, in the computation of `new_qty`, we don't only compare `so_line.product_uom_qty` with what quantity has indeed been delivered (i.e. `so_line.qty_delivered`), but also with the quantity that is expected to be delivered later (i.e. `get_expected_qty_to_ship_later`). [1]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L74 [2]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L88 [3]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L95 [4]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L103-L104 [5]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/sale_order.py#L57 [6]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L94 opw-4375941 opw-4457592 opw-4490398 opw-4628515 opw-4599490 Forward-Port-Of: odoo/odoo#197031
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212192
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212192
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_colum
Original PR description
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a…
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_column` is called with superuser privileges, which lack user context. This causes warehouses to always be linked to the superuser's company (id=1). As a result, modifying sales orders from different companies becomes impossible. opw-4735086 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207792
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble. We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected. This allows to silence errors coming from a failed
Original PR description
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble. We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected. This allows to silence errors coming from a failed load of an Element that was wrapped into a promise. Website uses that in image_processing for example. runbot-error-70404 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211827
Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places. opw-4745508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212186
Original PR description
Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places. opw-4745508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212186
Make the notification message searchable. Task-4828780 Forward-Port-Of: odoo/odoo#212047
Original PR description
Make the notification message searchable. Task-4828780 Forward-Port-Of: odoo/odoo#212047
There is a typo in the name of the Hebrew language. This commit fixes it. Task-4742567 Forward-Port-Of: odoo/odoo#212160
Original PR description
There is a typo in the name of the Hebrew language. This commit fixes it. Task-4742567 Forward-Port-Of: odoo/odoo#212160
The l10n_tr_nilvera_purchase_journal_id field was causing access errors due to its placement in the "Integrations" section without any group restriction, exposing it to users without the necessary rights. In contrast, the similar account_peppol_purchase_journal_id field is defined under the "Invoicing" section with the proper group restriction (account.group_account_manager), and behaves correctly. This fix moves the Nilvera field into the same restricted section as the Peppol field, align
Original PR description
The l10n_tr_nilvera_purchase_journal_id field was causing access errors due to its placement in the "Integrations" section without any group restriction, exposing it to users without the necessary rights. In contrast, the similar account_peppol_purchase_journal_id field is defined under the "Invoicing" section with the proper group restriction (account.group_account_manager), and behaves correctly. This fix moves the Nilvera field into the same restricted section as the Peppol field, aligning its access control and visibility with other similar fields in the same context. build_error-111279 Forward-Port-Of: odoo/odoo#210460 Forward-Port-Of: odoo/odoo#201563
### Before this commit: Empty paths in the config file are invalid but not verified, resulting in cryptic errors. ### After this commit: Empty paths are ignored, to prevent errors in the config. opw-4744154 Forward-Port-Of: odoo/odoo#209912
Original PR description
### Before this commit: Empty paths in the config file are invalid but not verified, resulting in cryptic errors. ### After this commit: Empty paths are ignored, to prevent errors in the config. opw-4744154 Forward-Port-Of: odoo/odoo#209912
Before this commit: - Vehicle number, document number, and date were rendered together without spacing, reducing readability. After this commit: - These fields are now separated by `&` for improved clarity in the vehicle details section. task-4807692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210830
Original PR description
Before this commit: - Vehicle number, document number, and date were rendered together without spacing, reducing readability. After this commit: - These fields are now separated by `&` for improved clarity in the vehicle details section. task-4807692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210830
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must not be duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of switching to the selected view. How to reproduce: ------------------------------------------ 1.Install Manufacturing, 2.Enable 2-step manufacturing, 3.Create MO for any product, e.g.Wood Panel 4.Go
Original PR description
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must…
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must not be duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of switching to the selected view. How to reproduce: ------------------------------------------ 1.Install Manufacturing, 2.Enable 2-step manufacturing, 3.Create MO for any product, e.g.Wood Panel 4.Go to the Transfers(having 1 picking), 5.Open Studio -> views -> Activate list view, Switching to Studio list view giving a ValidationError. Cause of the issue: ------------------------------------------ In the `action_view_mo_delivery` method when there is a single picking for the MO, only form view is passed in views, so it is not able to open other views. Solution: ------------------------------------------ In action_view_mo_delivery for single picking passes the form view and append the other views. This prevents the ValidationError and opens the selected view in Studio. This is similar to the issue previously fixed in: https://github.com/odoo/odoo/pull/37582 Forward-Port-Of: odoo/odoo#206269
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the P
Original PR description
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212091 Forward-Port-Of: odoo/odoo#182817
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86499
Original PR description
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86499