Daily updates from Odoo
Tuesday, January 20, 2026
59 changes · 19.0
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets within Odoo. These tests ensure correct functionality regarding hidden sections, drag-and-drop behavior, and optional product logic, enhancing the reliability and accuracy of sales order management.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEnhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, the system only accepted 12-digit numbers, preventing users from correctly entering 8-digit Ukrainian company numbers. This change ensures accurate data entry and processing for Ukrainian businesses.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469 Forward-Port-Of: odoo/odoo#243258
This update corrects a previous issue where the Apps application incorrectly displayed zero counts for industry modules. By adding version information to the route arguments, the system now accurately reflects the number of modules by category, aligning with recent changes in the apps.odoo.com API.
Original PR description
Before this commit, the count of industry modules by category in Apps application was always 0. With the change of API of apps.odoo.com, there is a possibility to display the exact count by category. In this aim, this commit adds the version to the route arguments such that the count is correctly displayed. task-5222706
This update improves the accuracy of Ecuadorian accounting by streamlining expense account categories and adding support for 8% VAT. Specifically, redundant expense groups have been consolidated, and expense accounts like salaries and wages are now automatically closed at the end of each accounting period, reducing reconciliation efforts.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
This update enhances the payment process for self-order kiosks by utilizing a new IoT protocol. It centralizes payment requests through a more reliable HTTP service, streamlining transactions and improving kiosk functionality. This change focuses on stability and efficiency for self-service ordering.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests.
This update simplifies the process of generating consolidated invoices from Point of Sale orders. Previously, invalid orders (like those already invoiced) would halt the entire process. Now, any problematic orders are automatically ignored, allowing users to generate invoices for the valid orders efficiently. This enhances bulk invoice generation capabilities.
Original PR description
When trying to create a consolidated invoice in the POS from multiple orders, if any of them would not be valid (i.e. invoice already generated, or order still in draft), then Odoo would throw an error and not do anything. Now the orders for which invoices can't be generated will just be ignored, but for the rest of the orders the invoices will be generated as usual. This should make it easier to bulk select and generate invoices only where necessary. Task-[5491082](https://www.odoo.com/odoo/project/1737/tasks/5491082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the restaurant POS system by automatically summing guest counts when multiple linked tables are used. Previously, each table was tracked separately. Now, when tables are linked, the system combines guest numbers for a more accurate total. This improves reporting and management of customer counts.
Original PR description
When two tables are linked in the pos, we would like to sum the guests. Here an example : If Table 1 has two guests and Table 2 has three guests, then Table 1&2 will have five guests. task: 5490906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the process for managing product pricing tags. The 'update all' button has been removed, and now only the update button for edited products is available. This simplifies the user experience and reduces the potential for errors when updating pricing.
Original PR description
To ease update of pricer tags, we removed the "update all" button to only have the one that update edited products. Task: 5380332
Resolved issues and error corrections
A bug was preventing users from creating vendor bills when using the German language in Odoo Enterprise. This was due to an issue with how attachments were being processed, specifically related to folder sorting. This update corrects the process to ensure consistent behavior across all languages.
Original PR description
Currently, an error occurs when a user tries to create a vendor bill in the German language. **Steps to replicate:** * Install `documents_account` * Documents > Finance > Upload a document * Change…
Currently, an error occurs when a user tries to create a vendor bill in the German language. **Steps to replicate:** * Install `documents_account` * Documents > Finance > Upload a document * Change language to German > Uploaded Document > Create a Vendor Bill **Observed Behavior:** The user gets the error `This action was not made available on the containing folder.`, even though it works in English and most other languages. **Root cause:** * The issue does not occur in English and most other languages because the sub-action `Create Vendor Bill` is executed before `Move Document to Taxes `due to [child record ordering](https://drive.google.com/file/d/1tSfqymtaLmABsVEh2tKaq7mtM7yOCZaP/view?usp=sharing) at [1]. * Although a sort method exists, no sort key is defined, so the records are effectively not sorted, preventing the issue. * In German and some other languages,` child_ids `are fetched in the [correct order](https://drive.google.com/file/d/1BKQA8bYvWYcQSy3jqC-1YEI-l7lUoxLX/view?usp=sharing) causing the attachment to be moved to the `Taxes` folder first. * This triggers the compute method [2] again because the attachment’s `folder_id` changes to `Taxes` folder. * Since the `Taxes` folder has no embedded server actions, the user error at [3] is raised. **Solution:** Explicitly set a `sequence` on the server action record so that `child_ids` are fetched in the same order as in English. [1]: https://github.com/odoo/odoo/blob/edc67e78046cddb5ca06aa8f928075337a328aa9/odoo/addons/base/models/ir_actions.py#L1020 [2]: https://github.com/odoo/enterprise/blob/50750a830e1c92348da89e894aa01c5cb2644aff/documents/models/documents_document.py#L848-L858 [3]: https://github.com/odoo/enterprise/blob/50750a830e1c92348da89e894aa01c5cb2644aff/documents/models/ir_actions_server.py#L60-L61 opw-5418708
This update resolves an issue where the final chatbot answer wasn't saved or shown in the side panel. The fix ensures the backend route is triggered, the user's answer is correctly recorded, and the chat session is properly closed, improving the user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due…
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called. **Current behavior before PR:** --------------------------------- - The final chatbot answer is not visible in the side panel - The chat session remains open after the final step **Desired behavior after PR is merged:** ----------------------------------------- - The final chatbot answer is saved and displayed in the side panel - The backend route is triggered for the last step - The chat session is properly marked as closed **Task:** 5172125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235102
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' actions on MX electronic invoices. The problem stemmed from a system error when payments were cancelled, leading to missing invoice data. This fix ensures these actions function correctly.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the foreign currency rates set on invoices, ensuring accurate reporting for our German clients. This improves the reliability of financial data exported to Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 Forward-Port-Of: odoo/enterprise#101910
This update fixes a problem that occurred when Odoo servers stopped, causing errors related to database connections. The fix ensures that these errors are ignored during shutdown, preventing disruptions and maintaining stability. This improves the overall reliability of the Odoo platform.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
This update resolves an issue affecting Odoo's spreadsheet functionality, specifically related to older versions of the ODOO.FILTER.VALUE feature. By updating the spreadsheet code, this change ensures compatibility with existing spreadsheets and prevents potential disruptions for users. This ensures a smoother experience for all users.
Original PR description
Task-5477426 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with automated tests related to canned responses in the live chat feature. Previously, tests were incorrectly flagging a change that restored auto-focus functionality. This PR removes these outdated and unreliable tests, ensuring the live chat functionality works as intended.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244472
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV exports. Now, invoices with foreign currency settings will accurately reflect the correct exchange rates in the exported reports, ensuring data consistency for financial reporting. This resolves a potential discrepancy in data accuracy.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239649
This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix ensures that the validation process is only executed once, preventing data inconsistencies and reducing potential errors. This improves the reliability of transfer processing.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#102465
Forward-Port-Of: odoo/enterprise#95329This update fixes a usability issue by moving the GCC format option within the invoicing settings to a more accessible location under the 'Customer Invoices' block. This ensures that users can easily find and configure this setting, regardless of whether the broader Fiscal Localization section is visible.
Original PR description
This fix moves the GCC Format checkbox under the 'Customer Invoices' block so it remains accessible in branches where the Fiscal Localization section is hidden. task-5723793
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, leading to posting failures. Now, the system correctly applies company-specific payment terms, streamlining inter-company billing.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update fixes a minor usability issue in the contact address view. The GLN field was awkwardly positioned and lacked a label, making it difficult to find. The change repositions the field before the notes field for better clarity and ease of access.
Original PR description
The field is placed weirdly in the view when opening the contact view of the delivery address. There is no label, making it almost impossible to discover, and it is in the middle of everything. Let's put it down before the notes field. Before: <img width="971" height="510" alt="image" src="https://github.com/user-attachments/assets/2e0e7d96-1a7f-4fe5-b17d-4c5b25a3e7bf" /> After: <img width="824" height="554" alt="image" src="https://github.com/user-attachments/assets/3bc47f20-72a9-4247-8dd3-9e939046c6d7" /> task-none Forward-Port-Of: odoo/odoo#244554
A recent test failed due to a problem with how payment providers were being set up across different companies in our demo data. This update ensures that each website only uses one payment provider, and that provider's company information matches the website's, resolving the error and improving data accuracy.
Original PR description
What is fixed ------------- The test_payment_provider_visibility_with_portal didn't pass due to a multi company issue. In demo data, "Demo" payment provider exists for different companies which led the search method to return every one of them. Trying to assign the shop website id to each of them then raises an error as their company_id are inconsistent. The fix ------------- We now ensure only one provider is selected and its company is the same as the website's company. Runbot error : 237822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244441
This update resolves an error that occurred when exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly validates the presence of at least one contact before generating the SAFT file. This prevents export failures and improves data accuracy.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task Forward-Port-Of: odoo/enterprise#104633 Forward-Port-Of: odoo/enterprise#104144
This update fixes an issue preventing QR code generation for invoices when using automated workflows. The change allows QR codes to be created without requiring a direct HTTP request, ensuring invoices with payment links are generated correctly. This improves the functionality of invoice automation.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF"; 2. create an automation rule for the `account.move` model; 3. set "Trigger" to…
Versions
--------
- saas-18.3+
Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
```python
env['account.move.send']._generate_and_send_invoices(records)
```
7. call `action_post` on an invoice via RPC or Odoo Shell.
Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound
Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.
When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.
[^1]: feature added via commit bcb73cd159885
Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.
opw-5487075
Forward-Port-Of: odoo/odoo#243528This update resolves a bug in the website builder that caused a crash when users modified shadow settings beyond the standard options. The fix ensures the system gracefully handles custom shadow definitions, preventing errors and maintaining builder functionality. This improves the stability and usability of the website builder for all users.
Original PR description
Forward-Port-Of: odoo/odoo#244244
An error occurred when editing event details (address or organizer) within the event editor. This issue was caused by a problem with how many2one fields were being searched. The team has reverted a recent change to restore the original functionality, ensuring event editing works correctly.
Original PR description
Currently, Editing the address or organizer on an event page currently triggers an error. steps to reproduce: 1) Install `website_event` module 2) Login as admin and create one event click on `Go to…
Currently, Editing the address or organizer on an event page currently triggers an error.
steps to reproduce:
1) Install `website_event` module
2) Login as admin and create one event click on `Go to Website` smart button.
3) Switch to Editor mode> Click on `My Company` under Organizers
(also works with Location).
4) on the right side bar click on `Contact drop-down`
Error:
`ValueError: Domain() invalid item in domain: ')'`
Root Cause:
after [this commit](https://github.com/odoo/odoo/pull/219810/commits/221127900bb6f72bf00715ff90727a87ef5d982c), the domain for many2one fields was fetched from the backend. In this case, the domain received looks like:
```
'(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of',
[company_id])] or ['|', ('company_id', '=', False), ('company_id', 'parent_of', '')]) + ([])'
```
At [1], this domain is passed to `search`, and `Object.values` turns it into an array of single-character strings. Passing this array to `name_search` causes the error.
FIX:
Revert the changes from PR https://github.com/odoo/odoo/pull/219810. as the original purpose of that PR is still met without them.
[1]- https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L101-L112
sentry-6916986959This update resolves an issue where the system incorrectly set a tax calculation flag when ‘price include’ was enabled. Removing the automatic setting prevents inaccurate downstream calculations and simplifies tax implementation for users. This ensures tax amounts are calculated correctly based on the intended pricing model.
Original PR description
Removed the onchange method because it automatically sets include_base_amount to True whenever price_include is enabled. This triggers incorrect downstream calculations. By removing it, we prevent the system from forcing this setting, which previously required the user to remember to manually uncheck the field during tax implementation.
This update enhances the testing environment by expanding the mocked XMLHttpRequests (XHR) API. Previously, testing was limited due to incomplete mocking, but this change adds more comprehensive coverage to prepare for future module development and ensure robust testing.
Original PR description
### [FIX] web: tests - add missing XHR members Before this commit, the mocking of XMLHttpRequests was incomplete; this was due to the fact that `rpc.js` was basically the only user of that feature, and as such only the properties and methods used in that file were mocked. However, it is only a matter of time before modules expose this XHR object (or declare their own) and manipulate them arbitrarily, increasing the need for a more complete mocked API. This commit adds most[1] features of the XHR API into the mocked one. [1] there may be edge cases that have not been considered to considerably simplify mocked XHRs. If there is an actual need at some point, a similar commit may have to be written in the future. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users with limited inventory access were prevented from completing dropshipping orders. The fix adds necessary permissions to correctly calculate product costs during the order validation process, ensuring dropshipping orders can be successfully processed.
Original PR description
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method…
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO). 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights). 5. Create a dropship order using the product and validate the picking. ``` You are not allowed to access 'Product Value' (product.value) records. This operation is allowed for the following groups: - Inventory/Administrator Contact your administrator to request access if necessary. ``` Issue:- During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169) if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error Fix:- To fix this sudo is added during getting _run_avco opw-5431121 upg-3762999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for major shipping carriers (UPS, FedEx, USPS, DHL). The changes ensure consistent carrier name mapping, allowing the connector to function properly with these popular shipping providers. This improves the accuracy and reliability of sales order fulfillment related to Amazon shipments.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update corrects a technical issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the system converts HTML. The fix ensures URLs are displayed correctly, preventing user confusion and improving the overall WhatsApp messaging experience. This was a minor issue impacting message clarity.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises…
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#104252 Forward-Port-Of: odoo/enterprise#101083
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for optimized domain searches, ensuring that grouped record sets display the expected nested data. This improves the accuracy and usability of reporting and analysis within the accounting module.
Original PR description
Access records in a grouped by `account_root` list failed, showing an error message:
Unsupported operator on Root 'Account' (account.account) in [('root_id', 'any', [('display_name', 'in', [10])])]
Step to reproduce:
- New DB with `accountant` module
- Accounting -> Chart of accounts
- Group By "Root"
- Open any grouped record set
When opening the record set, Odoo fetches data using the domain `[('id', '=', '10')]`
The domain goes through optimization as follows:
```
[('id', '=', '10')]
basic : [('id', 'in', ['10'])]
full : [('root_id', 'any', [('display_name', 'in', [10])])]
```
However, the `_search_account_root` method protects the technical field `account_root`.
This commit adapts it to allow full optimized domain search and solving the error.
Ticket [link](https://www.odoo.com/odoo/project.task/5178896)
opw-5178896
Forward-Port-Of: odoo/odoo#238841This update resolves a compatibility problem between shipping carriers and shipping partners within the Odoo website's sales functionality. Previously, certain carriers weren't correctly recognized, leading to potential errors during order processing. This change ensures all carriers work seamlessly with shipping partners, improving order accuracy and reliability.
Original PR description
Forward-Port-Of: odoo/odoo#244300 Forward-Port-Of: odoo/odoo#244035
This update resolves an issue where embedded buttons in the control panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the appearance and usability of the control panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234120
This update fixes an issue where the default identification type (VAT) was incorrectly applied to new contacts, regardless of the company's location. Now, the identification type automatically adjusts to the correct format (e.g., CUIT for Argentina, RUT for Uruguay) based on the selected company, ensuring accurate data and a better user experience.
Original PR description
When the country of a partner is changed, the identification type should be updated accordingly. This ensures that the identification type remains consistent with the partner's country, improving…
When the country of a partner is changed, the identification type should be updated accordingly. This ensures that the identification type remains consistent with the partner's country, improving data integrity and user experience. Description of the issue/feature this PR addresses: When creating a new contact, the field `l10n_latam_identification_type_id` (Identification Type) defaults to 'VAT' regardless of the active company. This PR ensures that the default identification type dynamically changes based on the selected company. For instance, it should automatically set to 'CUIT' for Argentinian companies or 'RUT' for Uruguayan companies. Current behavior before PR: The value 'VAT' is hardcoded as the default for the `l10n_latam_identification_type_id` field, regardless of the country or localization of the current company. Desired behavior after PR is merged: The `l10n_latam_identification_type_id` field should be updated via an onchange method to reflect the appropriate identification type according to the current company's localization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where users were getting stuck in the Point of Sale system due to IoT actions being ignored. The change ensures that actions are correctly processed, even when orders are cancelled, by using a data hash instead of a fixed UUID to identify actions.
Original PR description
This PR fixes the user getting stuck on the point of sale if some actions are being ignored by the iot box because these are considered as already executed. Currently the uuid asigned to an action doesn't change if an order is being cancelled so the iot box will systematically ignore the cancellation of pos orders if they were sent to the preparation printer before. This PR fixes this issue by instead using a hash of the data used to generate the receipt as a uuid of an action. If anything in the data changed the iot box will not ignore such actions anymore Community: https://github.com/odoo/odoo/pull/243822
This update fixes an issue where the carrier selected for a partner wasn't automatically applied when adding shipping to a sale order. The change ensures that if a partner has a preferred carrier set, it's now automatically used, streamlining the shipping process and improving accuracy. This resolves a previous bug impacting order fulfillment.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Go to partner *Azure Interior*: - Set 'property_delivery_carrier_id' to any carrier - Create a sale order: - Customer: Azure Interior - Add 1 unit of P1 - Click on "Add shipping" Problem: Since this commit: https://github.com/odoo/odoo/pull/203955/files#diff-9f1fd37c63903c4c029f099d485a3f9831446850be55695a4603c05ef298885bL134-L137 the carrier defined on the partner is no longer loaded by default. Solution: Check if the carrier defined on the partner is among the allowed carriers, and if so, set it automatically. opw-5220118 Forward-Port-Of: odoo/odoo#235336
This update reverts a recent change that added new features to the mobile spreadsheet dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Some adjustments were made to ensure compatibility with the existing chart-only functionality.
Original PR description
### [REV] spreadsheet_dashboard: go back to chart-only mobile dashboard This commit reverts 5cde5114d971a9edc12c9708ae0ea86bfb6db3b2, so the mobile dashboards go back to showing only the figures. Some adaptations were necessary to make the new features (carousel, granularity selector, ...) work. Task: [5447027](https://www.odoo.com/web#id=5447027&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a misleading message in the HR contract salary payroll module. We've updated the calculation to reflect part-time gross salaries instead of full-time salaries. This ensures accurate reporting and avoids confusion for payroll processing.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading.
A bug prevented users from successfully using the Odoo obfuscation command. The issue stemmed from the command incorrectly handling database names. This update corrects the command to properly process a single database, ensuring the obfuscation process functions as intended. This resolves a technical issue impacting database security.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280
This update corrects a bug where users could incorrectly modify the category snippet, leading to empty blocks on the website. The change ensures the snippet is used only for categories, preventing unintended content changes and maintaining website consistency. This resolves an issue impacting product display.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284
This update prevents the HTML Builder editor from freezing due to rare errors. A timeout mechanism is implemented as a last resort to release the editor and alert the user to potential data issues. The change also adds safeguards to long-running operations to ensure a smoother user experience.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911
This update resolves an issue where the payer company was incorrectly identified in the 1099 report when generating reports across multiple companies. The fix ensures that each 1099 line accurately reflects the correct payer company, improving the accuracy of tax reporting for businesses with multiple entities.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes an issue where changing the rental period of an order didn't automatically update the associated rental transfers. The fix mimics the rescheduling behavior of purchase orders, ensuring that rental transfers are accurately adjusted when the rental period is modified. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#102437 Forward-Port-Of: odoo/enterprise#101334
This update addresses a technical issue that caused list views to crash when aggregating data from fields with monetary values. The fix ensures that the system gracefully handles missing currency information, preventing aggregation errors and improving the stability of list views. This resolves a bug impacting data reporting.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692
This update resolves an issue where combo choices weren't displaying correctly in the self-order and kiosk modes. Previously, users had to reconfigure combo choices after setting a product variant. This change ensures combo choices are displayed correctly without requiring manual reconfigurations, improving the self-order experience.
Original PR description
Before the fix, when we set a product variant as combo choice. In self/kiosk, we'll see the product template instead of the product itself. And we need to configure it again. It occured because for all of the products in the kiosk/self, we display the product template. The expected behavior if we set a product variant as combo choice is to have the product variant in the combo directly without having to reconfigure it. The bug occurs only since 19.0 because a fix was already done from 18.3 to 18.4 in this pr : #219908 but the fwport for 19.0 has never been merged. task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the presence status widget was incorrectly displayed for archived employees in the HR module. The change hides this widget when an employee is marked as inactive, improving the user experience and ensuring consistent data presentation. This ensures archived employee records are displayed cleanly.
Original PR description
**Steps to reproduce:** Navigate to Employees -> Open an archived employee -> the presence status appears below the Archived banner **Solution:** Hide the presense status widget when the employee is inactive Task: 5350479
This update resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The change ensures avatars are displayed properly using the ‘object-fit: cover’ style, providing a consistent and professional user experience. This improves the visual quality of user profiles.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243181 Forward-Port-Of: odoo/odoo#242320
This update removes a redundant 'OK' button from form dialogs within the Point of Sale (POS) system. Previously, this button was only removed when the 'pos_appointment' module was installed. Now, the change is applied consistently across all POS form dialogs, creating a more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165
This update fixes an error in the Point of Sale order report that incorrectly calculated margins for refunded orders. The fix ensures that refunds are properly accounted for, displaying accurate margins based on order value, improving reporting accuracy for financial analysis.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change was only applied when a specific module was installed. Now, the change is consistent across all POS form dialogs, providing a cleaner and more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197
This update fixes an issue where overtime calculations were inaccurate when employees were on leave. Now, if an employee works on a day they are off, all hours worked are treated as overtime, excluding breaks. This ensures accurate overtime payments for all employees.
Original PR description
This PR aims to fix how the overtime is being calculated with quantity based rules : - The expected _hours didn't take into account the leaves of the day , so if the user was on a leave, it would considered him absent ( give him negative overtime) , because he has no attendances that day. - if the employee took a whole day off, and decided to work on it, all the hours should be considered as overtime, the brake shouldn't be included (ex : his normal work sched is morning (9h-12h) , break(12h-13h), afternoon(13-17h) , he's already getting paid for that time , so every single hour worked that day from 12am to 12 pm is added time , and there is no break in added time) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where a default rate was incorrectly overriding the rate specified during testing for the FedEx delivery module. By clearing these outdated rates in the test environment, we ensure accurate rate calculations and prevent potential discrepancies in delivery cost reporting. This improves the reliability of our testing process.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965
This update fixes tests related to overtime calculations based on quantity. The changes reflect a recent update to how overtime is calculated, ensuring the tests accurately reflect the new logic. This improves the reliability of our overtime tracking system.
Original PR description
this PR made some changes to how overtime is calculated by quantity based rules. This PR aims to adapt the test to the new calculation logic
This update resolves a bug where the link popover would incorrectly appear on input fields within protected nodes. The fix ensures the popover only displays when an editable element is focused, improving the user experience and preventing unexpected behavior when renaming files within the HTML editor.
Original PR description
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span protected non-editable><input></span>` If the selection is inside the link and the link preview popover is visible, clicking on the input triggers a selection change. Since the input is inside a protected node, the editor keeps the previous editable selection. As a result, `LinkPlugin.handleSelectionChange` still treats the selection as being inside the link and reopens the link popover. Solution: Only show the link popover when the `activeElement` is the editable element. Steps to reproduce: - Add a link. - Upload a file. - Place the selection on the link. - Focus the file name input to rename it. - Observe that the link popover is shown on the file name input. opw-5414078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a calculation error in the fleet module related to the initial acquisition date of vehicles. By setting a default acquisition date, the system now accurately calculates baseline ATN (Asset Tracking Net) values, leading to more precise reporting and financial analysis. This ensures better tracking of vehicle depreciation and asset management.
This update resolves an issue where government entities using TAN-based GSTINs were incorrectly flagged with validation errors when creating contacts in Odoo. The change adjusts the validation process to correctly handle TAN-based GSTINs, ensuring proper partner creation for these important customers. This improves data accuracy and usability.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356
This update corrects a visual glitch where an 'Add Item' button incorrectly appeared on web page snippets after all topics were removed. The fix ensures the button disappears when no topics are present, improving the user experience and preventing unexpected errors. This change impacts multiple snippet types.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244034
This update corrects a bug where the partner ID wasn't consistently passed through the stock move creation process, specifically in multi-step delivery scenarios. The change ensures that the correct customer or supplier is associated with stock moves, resolving issues with order fulfillment. This impacts sales and purchase order processing.
Original PR description
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock ### Issue: The partner_id (contact field) of stock move is no longer propagated in pull chain since the…
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock
### Issue:
The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a
#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.
### Cause of the issue:
Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.
### Additional changes:
1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381
2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.
3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346
4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23
5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11
opw-5428063
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a potential issue where users could create duplicate tax names in different branches of Odoo. Previously, the system only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee each tax name is unique, preventing conflicts and ensuring data accuracy across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185