Friday, May 30, 2025
33 changes · 18.0
Enhancements to existing features
When a contact is moved under a different parent company, related accounting entries are updated to match the new commercial partner. This keeps receivables and payables reporting consistent, while limiting the action to users with Accountant permissions.
Original PR description
- Update accounting entries to reflect the new commercial_partner_id: * Ensures consistency across account.move.line and partner_id fields. * Changes are restricted to users in the Accountant group. 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
Restaurant staff can now switch individual UrbanPiper delivery platforms online or offline directly from the point of sale. This helps businesses quickly pause or resume specific aggregators without going into backend settings, with notifications confirming each change.
Original PR description
Following this commit : ==== - An online/offline toggle option is provided for the food delivery dropdown. - If the user has configured more than one provider and wishes to close/off one of the aggregator, then without going on the backend from the UI itself, the user can offline that particular provider and vice versa. task-4582032
The EC Sales List now warns users when multiple partners share the same VAT number, helping prevent inaccurate Intrastat submissions. Users can identify highlighted duplicates and choose a main partner to consolidate related records and keep reporting consistent.
Original PR description
When submitting the EC Sales List via Intrastat, redundant partner entries with the same VAT number (but different commercial entities) may lead to inaccurate reporting and validation issues. - Detecting partners with duplicate VAT numbers. - Displaying a warning banner at the top of the report when duplicates are present. - Highlighting duplicated partners in the report with a yellow background. - Adding a "Set as main" button to duplicated rows, allowing users to set a partner as the commercial partner for all others sharing the same VAT. task-4707491
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
Resolved issues and error corrections
Odoo now avoids showing push notifications when a user is already focused on the relevant mail conversation. This reduces duplicate alerts and makes the Discuss/chat experience less distracting.
Original PR description
**Current behavior before PR:** Push notifications are shown even when the user is already viewing the same conversation in the Discuss app or in the ChatWindow. The Service Worker does not currently…
**Current behavior before PR:** Push notifications are shown even when the user is already viewing the same conversation in the Discuss app or in the ChatWindow. The Service Worker does not currently check whether the conversation is focused, leading to redundant and unnecessary notifications. **Desired behavior after PR is merged:** The Service Worker now intelligently checks the state of the Discuss and ChatWindow before displaying push notifications. Notifications are only shown when the user is not actively focused on the same conversation. The updated logic ensures: - Chat bubble minimized and tab focused → Show - Chat window open, tab focused, but a conversation not focus → Suppress - Chat window open, tab focused, the conversation is focused → Suppress This behavior is achieved by the Service Worker sending a message to the client window to get the active thread and its focus status before deciding whether to show a notification. This results in a cleaner user experience by avoiding redundant alerts when they’re not needed. task-[4582533](https://www.odoo.com/odoo/my-tasks/4582533) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This updates Odoo’s spreadsheet engine to the latest version, bringing targeted fixes for spreadsheet users. It improves autocomplete dropdown readability and addresses an issue with pivot charts when fields contain a mix of text and numbers, helping reports remain clearer and more reliable.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d201086ee [REL] 18.0.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d201086ee [REL] 18.0.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ab92eab3c [REV] pivot: chart field with mix of text and numbers [Task: 4800411](https://www.odoo.com/odoo/2328/tasks/4800411) https://github.com/odoo/o-spreadsheet/commit/5831ad228 [FIX] autocomplete_dropdown: Improve dropdown readability [Task: 4813433](https://www.odoo.com/odoo/2328/tasks/4813433) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
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
This fix prevents portal token access from changing the global chat user identity. It keeps live chat and portal conversations separate, avoiding stalled chatbots or messages appearing under the wrong user after redirects.
Original PR description
*: portal, portal_rating, test_mail_full. Before this commit, the chat bot could stop when redirecting to a page where the portal is enabled. Both the portal and live chat modules rely on the discuss store’s `self` field which identifies the authenticated user. However, the portal also supports authentication via a token in the URL, which temporarily identifies the user on a specific thread. Previously, the portal would overwrite the global `self` value, causing inconsistencies for other users of the store such as messages appearing as if sent by another user. Since token authentication is specific to portal threads, it should only affect actions on the granted thread without altering the global user identity. This fix prevents the portal from overwriting the global `self` value and instead returns the thread-specific `portal_partner` field. opw-4722466
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 fix prevents Point of Sale sessions from getting stuck when a loyalty reward has an invalid product rule. Instead, the shop opens normally and staff see a clear warning so they can continue serving customers while the reward configuration is corrected.
Original PR description
Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is…
Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is unable to open and keeps loading with an error visible on the console. This is because when the session tries to open, the compute_discount_product_ids method is called which runs into an error because it cannot use the domain. Ideally, the pos screen should still load and give an alert message saying “The reward "xxx” contains an error in its domain, your domain must be compatible with the PoS client” and after closing the popup, the pos shop can be used however this does not happen as the code line for deleting the erroneous loyalty reward runs into an error because the delete method expects a record but receives an id. The alert message written before never appears because this delete statement runs into an error.
Purpose: Passing the correct argument to the delete function so that the loyalty program with issues in domain can be properly deleted from loaded models. After this correction, the pos session will load and there will be an alert warning the user of the reward error.
Steps to Reproduce on Runbot:
1. Choose any discount program for the pos shop. Open the reward pop up and choose to put the discount on specific products.
2. Edit domain in the “Discount Product Domain” and put <Products> <contains> <screen> in the rule `[("product_variant_ids", "ilike", "screen")]`. We can see 3 records here on the reward.
3. Save and close the program screen. Open the pos shop and check the console. The screen keeps loading and there is a traceback error in the console.
opw-4350676
opw-4352567
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSubcontracted manufacturing orders now automatically record the receipt that triggered their creation. This restores traceability between related manufacturing orders, making it easier for teams to follow subcontracting flows and investigate issues.
Original PR description
This commit ensures that the 'Source' field of a subcontracted MO is automatically filled with the name of the receipt that led to its creation. Steps to reproduce the bug: - Create a storable…
This commit ensures that the 'Source' field of a subcontracted MO is automatically filled with the name of the receipt that led to its creation.
Steps to reproduce the bug:
- Create a storable product “P3”:
- route: Drop-ship
- Vendor: vendor P3
- BoM:
- type: subcontracting
- Subcontractors: Vendor P3 - Components:
- P2:
- Vendor: Vendor P2
- Route: drop-ship subcontractor on order
- BoM:
- Type: Subcontracting
- subcontractor: Vendor P2
- Components:
- P1:
- Vendor: Vendor of product P1
- Route: Drop-ship subcontractor on order
- Create a quotation:
- Customer: Azure Interior
- Product: P3
- Confirm the quotation -> A purchase order is created for P3
- Open the PO
- Confirm it
- A purchase order is created for P2, and an MO is generated for P3
- Confirm the PO for P2 → an MO is created for P2
Problem:
The Origin field is not set for either MO, preventing the linkage between parent and child MOs.
Backport of:
https://github.com/odoo/odoo/commit/cca6c7abc1adcf688123a1e41033a3e25daf8d6a
opw-4788501This 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
Receipts for Indian point-of-sale transactions now display the tax percentage alongside the tax type. This makes receipts clearer for customers and improves accuracy for tax transparency and compliance needs.
Original PR description
Before this commit: ==== - Previously, only the tax type was displayed on receipts and the tax percentage was missing for Indian localisation. Following this commit: ==== - The tax percentage is now displayed alongside the tax type on receipts, improving transparency and accuracy. task-4464136
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
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