Daily updates from Odoo
Navigate
Branch
Tuesday, January 20, 2026
374 changes
14 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers (and variations with 'UA' prefixes) are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors related to incorrect length restrictions.
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
Resolved issues and error corrections
This update fixes an issue where the product comparison bar was hidden behind other website elements. By increasing the bar's visibility level, users can now consistently access and use the comparison feature regardless of the website's layout. This ensures a smoother shopping experience.
Original PR description
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded).…
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded). This low z-index value caused it to be overlapped by any website snippets using grid mode with more than 3 items, as grid items conventionally have incremental z-index values (1, 2, 3, 4, ...) for JavaScript consistency. The issue was not limited to s_banner_categories but affected all grid-based snippets, making the comparison bar inaccessible when positioned behind snippet content. Solution: Increase the comparison bar's z-index to -modal (1055 in Bootstrap), ensuring it always appears above regular page content including grid snippets, while still remaining below actual modals and dialogs. After this commit: The comparison bar consistently appears on top of all snippet content, ensuring users can always access and interact with product comparisons regardless of the page layout or snippet configuration. opw:5426163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243975
This update fixes an issue where newly created appraisal templates weren't appearing in the campaign selection list. The problem stemmed from a technical detail regarding how the system filtered templates based on company settings. The fix ensures that all templates, including newly created ones, are correctly displayed, streamlining the campaign setup process.
Original PR description
**Version:** - 19.-0 **Steps to reproduce:** - Install the Appraisal module. - Click the Launch Campaign button. - Open the wizard and create a new appraisal template. **Issue:** - Newly created appraisal templates do not appear in the selection list. **cause:** - When a new template is created, the company field is automatically set by default. - However, the domain used to fetch templates does not include the company condition, causing the newly created template to be excluded from the results. **Solution:** - remove domain and use check_company=True to get the company. Task-5416593 Forward-Port-Of: odoo/enterprise#102108
A technical issue in the Odoo loyalty program tour was preventing users from completing the setup. This fix addresses a problem caused by an infinite scroll feature within the pop-up modal, which was causing the tour to get stuck. Merging this change will ensure the loyalty program tour functions correctly for all users.
Original PR description
fw-port fails because of infinite scroll in pop modal .modal .partner-list 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#218604
This update resolves an issue that prevented users from clicking 'Show', 'Force CFDI', or 'Retry' buttons on invoices after cancelling payments. The fix addresses a technical error related to missing payment information, ensuring invoices can be processed correctly in the MX electronic invoicing process.
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 removes an unnecessary warning related to credit notes from the GSTR report, streamlining the reporting process. Previously, a warning appeared on invoices when a credit note was linked, which has now been corrected to clear only when the credit note is fully processed and checked. This simplifies reporting for users.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104701 Forward-Port-Of: odoo/enterprise#102106
This update resolves a technical error in the WPS report test process. Specifically, the test was incorrectly creating a bank account record. This change ensures the test accurately reflects the report generation process, improving the reliability of the test results.
Original PR description
The test was creating a res.partner.bank with the id of company passed as partner_id. This commit fixes this issue by passing the partner_id of the company instead. build_error-237562
This update prevents Attendance: Officer/Admin users from accessing the employee onboarding feature within the Attendances app. Previously, users lacked the necessary permissions, leading to a traceback error. This change ensures that only users with full Employee rights can access this functionality, improving data security and usability.
Original PR description
# Issue Getting a traceback when trying to access the onboarding menu with just Attendance: Officer access right. # Steps to reproduce 1. Log in with a demo user, with just Attendance: Officer access right. 2. Navigate to Attendances app, and yes, you don't see Configuration, but still you can access the Onboarding menu by typing some random text on search. 3. Now, navigate to the Onboarding menu, and try setting a badge of an employee 4. You get a traceback. # Fix Attendance: Officer/Admin without Employee rights (either Officer/Admin) will not be able to access the Attendances Onboarding menu. Only the user with both the rights can access it. task-5267189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235965
This update fixes a bug where the user's final answer in the chatbot wasn't saved or shown in the side panel. The change ensures the final answer is correctly recorded, displayed, 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 fixes a technical issue that caused errors when Odoo servers were shut down. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
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 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 rates when generating reports for Datev, ensuring data consistency and accurate financial reporting. This resolves a previous reporting discrepancy.
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 fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the currency rates set on invoices, ensuring accurate financial reporting for German customers. This improves the reliability of 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 corrects a technical issue where the kiosk system wasn't correctly receiving payment information from IoT payment terminals. The fix ensures the kiosk retrieves the accurate response data, improving the reliability of self-order transactions. This resolves a potential disruption to the customer ordering process.
Original PR description
In v19.0, IoT Boxes respond with a dict containing a `result` key holding the actual response of the action. The kiosk couldn't get the terminal answer as it was reading directly in the response dict, instead of its `result` key. Forward-Port-Of: odoo/enterprise#104799
This update prevents unnecessary WebRTC testing when working with stable IoT Boxes. This change avoids a potential performance issue and ensures the 'Test' button functions correctly for the intended use case. It improves the overall user experience for IoT Box management.
Original PR description
We now avoid testing WebRTC when pressing "Test" button on the IoT Box record, when the IoT Box is a stable IoT Box (which does not support it). Task: 5490291 Forward-Port-Of: odoo/enterprise#104716
17 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted. Now, 8-digit numbers (and 10 or 12-digit variations) are supported, resolving an issue where Ukrainian users were unable to correctly input their TINs.
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
Resolved issues and error corrections
This update resolves an issue where users were blocked from settling customer balances in Point of Sale when ZATCA integration was active. The fix removes the automatic requirement to generate an invoice for settlement payments, allowing users to complete the payment process correctly. This ensures seamless settlement operations for ZATCA users.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243786 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where the 'Settle Due' payment flag remained active after a user cancelled the payment process. This prevented users from adding regular products to the order and caused incorrect processing by other integrations. Now, the flag is reset to false, ensuring proper order handling.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104291 Forward-Port-Of: odoo/enterprise#98463
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled or deleted, leading to incorrect invoice data. This fix ensures a smoother process for generating and submitting CFDI invoices.
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 a technical issue that caused errors during server shutdowns. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures that these errors are now gracefully handled, improving server stability and reliability.
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 corrects a minor issue related to testing within the live chat feature. Previously, outdated tests were causing problems. The PR removes these unnecessary tests, ensuring the canned response functionality works as intended and avoids potential conflicts.
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 resolves an issue preventing the generation of QR codes for invoices when using automated workflows. The fix ensures that the necessary access information is available, allowing invoices to be properly linked to payment portals. This improves the functionality of invoice payment options.
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 fixes an issue where foreign currency rates weren't correctly applied during Datev CSV report exports. Now, invoices with foreign currency settings will accurately reflect the correct rates when generating these reports, ensuring data consistency for financial reporting. This resolves a potential discrepancy in exported data.
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 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 resolves an issue where tables inserted into the To-Do editor appeared after the existing text instead of before it. The fix streamlines the table insertion process, ensuring tables are placed correctly at the desired cursor position. This improves the user experience and prevents formatting inconsistencies.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244435 Forward-Port-Of: odoo/odoo#243242
This update fixes a minor usability issue in the contact record view. The GLN field was awkwardly positioned and lacked a label, making it difficult for users to find. The change repositions the field before the notes field for better clarity and discoverability.
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
This update prevents errors when creating inter-company invoices by ensuring that payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, leading to posting failures. Now, only company-specific payment terms are applied, streamlining inter-company transactions.
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 resolves an issue that prevented users from exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly identifies companies needing contact information before attempting the export. This improves the reliability of the SAFT generation process for Austrian clients.
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 resolves a compatibility problem between shipping carriers and shipping partners within the Odoo website's sales functionality. The change ensures that carriers are correctly recognized and utilized when processing orders, leading to more reliable shipping calculations and order fulfillment. This improves the overall customer experience and reduces potential errors.
Original PR description
Forward-Port-Of: odoo/odoo#244300 Forward-Port-Of: odoo/odoo#244035
This update fixes an issue where product prices in Point of Sale were incorrectly displayed due to a double currency conversion. The fix prevents the list price from being converted twice, ensuring accurate pricing for users with multi-currency POS configurations. This improves the reliability of sales transactions.
Original PR description
**Steps to reproduce:** - Have a company that has USD as currency - Make a PoS config that has another currency in the sales journal, such as AED - Open that PoS - Click on a product, then go the the Info tab - Some of the displayed prices will be wrong, as they are multiplied by the exchange rate twice **Why the fix:** If the config's currency is different from the company's currency, we convert the templates' list_price to match the config's currency. This is done in those lines https://github.com/odoo/odoo/blob/b64bdf67dcf273a7e666928ffa6df37b45566f2b/addons/point_of_sale/models/product_template.py#L277-L278 The current problem with this is that this function is called twice, thus multiplying the list_price twice and making it wrong. We can prevent this by checking if it has already been converted before multiplying the template's list_price. opw-5226656 Forward-Port-Of: odoo/odoo#241517
This update resolves an issue where shared folders with access tokens weren't initially displayed correctly for users. The fix ensures that subfolders are immediately accessible when a shared link is used, eliminating the need for a refresh. This improves the user experience for accessing and managing shared documents.
Original PR description
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) -…
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) - Copy the share link - Login with the portal user in an incognito window - Paste the share link in an incognito browser - Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture - Click on "brand 2" - Click back on "brand 1" and now the folder and picture are visible - If you click on a subfolder of "brand 1" you also get an error **Issue:** Discoverable subfolders accessed using `accessToken` are not available on the first read of a user and this happens for each level of the hierarchy (refresh is needed each time). When using sharing link to display folders with a user, the subfolder document access is created on `/documents/touch/` using `_from_access_token`. But on the js side the call is delayed (with debounce) and occurs after the `web_search_read`. This means that subfolders are only accessible after a refresh or by switching back and forth between folders. Also, even after the folder is displayed, if there are other subfolders in it, going deeper in the hierarchy won't work as well without a refresh due to the `search_panel_select_range` missing the new folder. **Fix:** Not sure on the best way to fix this, the issue will always be related to performance. Current fix checks if a reload is needed by sending a flag in the `/documents/touch/<access_token>` request result when a new document access was created. opw-5156297 Forward-Port-Of: odoo/enterprise#104585 Forward-Port-Of: odoo/enterprise#99820
This update resolves an issue where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix prevents multiple validation attempts, ensuring accurate stock tracking and avoiding data inconsistencies. 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#953294 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers – including those prefixed with 'UA' for European companies – are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors.
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
Resolved issues and error corrections
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled or deleted, leading to incorrect invoice data. This fix ensures a smoother process for generating and submitting CFDI invoices.
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 a technical issue that caused errors when Odoo servers were stopped. Specifically, the server shutdown process was incorrectly closing database connections before the system was fully ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
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 corrects a technical issue related to canned response testing in the live chat feature. Previously, outdated tests were causing problems. This PR removes these unnecessary tests, ensuring the live chat functionality operates smoothly and reliably.
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
14 changes
Resolved issues and error corrections
This update resolves an issue related to testing for canned responses in live chat. Previously, tests were outdated and unreliable. This PR removes these unnecessary tests, streamlining the development process and ensuring accurate results.
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
This update fixes an issue where printers would become unavailable for extended periods after disconnecting, leading to errors and double printing. The change introduces a safeguard to prevent unnecessary removal of printers from the system, ensuring they're reliably available for printing once they reconnect. This improves the user experience and prevents operational disruptions.
Original PR description
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2…
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface. The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box. However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds. Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects. The user in pos can then press "retry" which will lead to a double printing. This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups. Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed. The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving invoice generation reliability. This change impacts the Mexican e-invoicing reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460This update fixes an issue where the quantity delivered on sale orders wasn't accurately updated after a partial refund with a 'Ship Later' option. Previously, the system incorrectly reported zero delivered quantities. The fix ensures that delivered quantities are calculated correctly, including when refunds with 'Ship Later' are processed, leading to more accurate inventory tracking.
Original PR description
The qty_delivered on sale.order.line was not correctly computed when the original order was refunded with a ship later. Steps to reproduce: ------------------- * Create a sale order for 5 quantities of any product * Confirm the sale order * Settle the order in the PoS * At this point the qty_delivered on the sale order line is 5 * Now go back to the PoS and refund partially the order for 3 quantities and use the "Ship Later" option > Observation: The qty_delivered is 0 instead of 2 Why the fix: ------------ We group the pos.order.line by procurement group and then check if all pickings related to these lines are done before adding the qty to the qty_delivered. We also make sure to include the refund lines in the computation opw-5059560 Forward-Port-Of: odoo/odoo#240945
This update corrects a compatibility problem between shipping carriers and shipping partners within the Odoo website's sales functionality. The change ensures that carriers are correctly recognized and utilized when processing orders, improving the reliability of shipping calculations and order fulfillment. This resolves a previous issue impacting order accuracy.
Original PR description
Forward-Port-Of: odoo/odoo#244035
This update fixes an error in the financial reporting for Vietnam (l10n_vn_reports) that resulted in inaccurate calculations for key balance sheet codes (420.1 and 420.2). The changes ensure these figures accurately reflect equity and profit distributions, improving the reliability of financial reports.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104373
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled, leading to missing invoice data. This fix ensures a smoother process for generating and updating CFDI invoices for Mexican businesses.
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 a technical issue that caused errors when Odoo servers were shut down. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
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 fixes an issue where foreign currency rates weren't correctly applied during Datev CSV exports. Previously, invoices wouldn't reflect the intended currency rates when generating reports for Datev. This change ensures accurate currency conversion for Datev exports, improving data reliability.
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 fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately uses the specified currency rate from invoices, ensuring accurate reporting for German customers. This improves the reliability of financial data exports.
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
A test was failing due to a sale order not requiring payment. This update has been implemented to ensure all sale orders now require payment, resolving the test failure and maintaining proper order processing functionality. This change was made to improve the reliability of the website sale module.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244322
This update prevents errors when creating inter-company invoices by ensuring payment terms are correctly aligned with the destination company. Previously, payment terms from one company were incorrectly applied to invoices for another, causing posting failures. This fix ensures only compatible payment terms are used.
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
Code cleanup and technical improvements
This update enhances the testing process for Odoo's Arabic accounting modules (l10n_ar). Specifically, a new testing method and refactoring of the test suite ensure more reliable and comprehensive verification of these modules, improving overall stability and accuracy.
Original PR description
- Implemented a working `assert_json` method on `AccountTestInvoicingCommon`, that also supports the ignore_schema system and quick save using the `SAVE_JSON` test tag. - Refactors the whole test suite of `l10n_ar*` modules to use the new accounting test helpers properly. task-4891206 Forward-Port-Of: odoo/odoo#242309
This update streamlines the testing process for the Arabic Electronic Document Interface (EDI) module by automatically verifying data against JSON files. This change allows tests to run without external dependencies and simplifies updates to test data through a simple tag.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#103370
28 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, the system only accepted 12-digit numbers. Now, it supports 8-digit numbers for Ukrainian companies and 12 or 10-digit numbers for individuals, resolving an issue where Ukrainian TINs were incorrectly rejected.
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 ensures that only employees within our company can be designated as HR Responsible. Previously, external users could be assigned this role, leading to potential data inconsistencies. This change improves data integrity and prevents incorrect assignments.
Original PR description
Updated the "HR Responsible" field under the Approvers group in the Employee settings to ensure better data integrity. Changes: Added a domain filter to the hr_responsible_id field. Restricted selection to Internal Users only (share=False). Restricted selection to users belonging to the current company. This prevents external or portal users from being incorrectly assigned as HR responsibles and ensures cross-company data isolation. 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
Resolved issues and error corrections
A recent issue prevented users from configuring their websites after installing the website module. This fix ensures the website configurator automatically launches during installation, streamlining the setup process and allowing users to quickly begin customizing their online presence. This resolves a critical blocker for new website deployments.
Original PR description
Since [1], installing the website module fails to launch the configurator, preventing users from setting up their website immediately. This issue occurs because `website_generator` is set to auto-install. During the installation sequence, `website_generator_wait` overrides `website_configurator_todo`, causing the latter to be bypassed. This commit provides a temporary fix to ensure the configurator is correctly triggered [1]: https://github.com/odoo/enterprise/commit/c0f26ac040b1d8ff81a2f53306e81da1778d70c2 Forward-Port-Of: odoo/enterprise#104789
This update ensures live chat agents consistently receive the latest conversation updates by correctly subscribing to the necessary channels. Previously, the system wasn't reliably setting up the bus subscription, leading to potential delays in receiving updates. This fix guarantees that agents always see the most current information in live chat sessions.
Original PR description
The `test_form_view_embed_thread` ensures that the live chat list view redirects to the discuss app and that the bus subscription for the selected channel is properly made. This ensure that a live chat agent looking at a channel will receive the latest updates for the conversation. To ensure the bus subscription is made, the bus service is patched in order to detect calls to add or remove methods. However, we only wait for `whenReady` which is not enough to guarantee the bus is already exposed via `odoo.__WOWL_DEBUG__`. This PR ensure we wait for the list view to be displayed, which ensures the webclient is mounted and the debug info is already set. runbot-234928 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#244512
This update fixes an issue where the product comparison bar was hidden behind other website elements, particularly grid-based snippets. By increasing the bar's visibility level, users can now consistently access and use the comparison feature regardless of the website's layout. This ensures a smoother shopping experience.
Original PR description
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded).…
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded). This low z-index value caused it to be overlapped by any website snippets using grid mode with more than 3 items, as grid items conventionally have incremental z-index values (1, 2, 3, 4, ...) for JavaScript consistency. The issue was not limited to s_banner_categories but affected all grid-based snippets, making the comparison bar inaccessible when positioned behind snippet content. Solution: Increase the comparison bar's z-index to -modal (1055 in Bootstrap), ensuring it always appears above regular page content including grid snippets, while still remaining below actual modals and dialogs. After this commit: The comparison bar consistently appears on top of all snippet content, ensuring users can always access and interact with product comparisons regardless of the page layout or snippet configuration. opw:5426163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243975
This update fixes an issue where products created through the website automatically appeared as published without a category assigned. The fix removes code that forced publishing and ensures products remain unpublished until a category is selected, aligning with the user's expected experience. This improves consistency and prevents accidental product listings.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244414 Forward-Port-Of: odoo/odoo#242779
This update ensures the website's product barcode lookup functionality aligns with a recent community change. Previously, products created through the website weren't automatically published if a category wasn't selected. This fix corrects the test to accurately reflect this behavior, preventing potential issues with product visibility.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#104709 Forward-Port-Of: odoo/enterprise#103778
This update fixes an issue where newly created appraisal templates weren't showing up in the selection list during campaign setup. The problem stemmed from a technical detail in how the system filtered templates, now it correctly includes templates created within a campaign, ensuring a smoother workflow for performance reviews.
Original PR description
**Version:** - 19.-0 **Steps to reproduce:** - Install the Appraisal module. - Click the Launch Campaign button. - Open the wizard and create a new appraisal template. **Issue:** - Newly created appraisal templates do not appear in the selection list. **cause:** - When a new template is created, the company field is automatically set by default. - However, the domain used to fetch templates does not include the company condition, causing the newly created template to be excluded from the results. **Solution:** - remove domain and use check_company=True to get the company. Task-5416593 Forward-Port-Of: odoo/enterprise#102108
This update resolves an issue where the link popover remained open after a snippet was removed from the website builder. The fix ensures the popover closes automatically when a snippet is deleted, improving the user experience and preventing visual clutter. This change was made to enhance the stability and usability of the website editing tool.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its pointerdown handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document pointerdown listener, but this also triggered when interacting with the link type dropdown and color picker, closing the popover triggers applyCallback and causing nested links to be created.
After this commit:
- Close the link popover from on_will_remove_handlers before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243556
Forward-Port-Of: odoo/odoo#237679This 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 incorrect data. This fix ensures these actions function correctly without causing errors.
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 prevents Attendance Officer/Admin users from accessing the employee onboarding feature within the Attendances module. Previously, users with limited access could trigger a traceback when attempting to set badges. This change ensures that only users with full Employee rights can access this functionality, improving stability and security.
Original PR description
# Issue Getting a traceback when trying to access the onboarding menu with just Attendance: Officer access right. # Steps to reproduce 1. Log in with a demo user, with just Attendance: Officer access right. 2. Navigate to Attendances app, and yes, you don't see Configuration, but still you can access the Onboarding menu by typing some random text on search. 3. Now, navigate to the Onboarding menu, and try setting a badge of an employee 4. You get a traceback. # Fix Attendance: Officer/Admin without Employee rights (either Officer/Admin) will not be able to access the Attendances Onboarding menu. Only the user with both the rights can access it. task-5267189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235965
This update resolves a test failure in the live chat module. The issue stemmed from a mismatch between the demo data's time zone setting and the test's expectations. The fix ensures the test accurately reflects the OdooBot's time zone, improving the reliability of the live chat testing process.
Original PR description
This PR fixes a failing assertion in `test_channel_get_livechat_visitor_info`. The test fails since [*] because the demo data sets the OdooBot time zone to 'Europe/Brussels', while the test was asserting it to be False. This PR explicitly sets the time zone of the OdooBot partner record and updates assertions accordingly. [*] https://github.com/odoo/odoo/pull/210094 runbot-237778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244422
This update resolves a sporadic failure in the 'Copy Message Link' test within Odoo. The previous test relied on unreliable keyboard shortcuts, leading to inconsistent results. The updated test uses a more robust method to ensure the copy functionality works correctly and reliably.
Original PR description
Before this commit, the "Copy Message Link" test was sometimes failing. It happens for two reasons: - It presses "ctrl+v" with the intent of copying the message link in the composer but doesn't check if the composer is focused (it should not be as the test clicks away to copy the link). - It then presses "enter" with the intent of posting the message, without checking if the composer is filled or even ready to send. This test replaces the "press" steps: - "ctrl+v" is replaced by `insertText`: we already check that the copy works and "press" is less reliable. - We click on the send button when enabled. runbot-237538 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#244547
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV report exports. Now, invoices with specified foreign currency rates will accurately reflect those rates when generating the CSV file, ensuring accurate financial reporting. This resolves a potential discrepancy in data export.
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 fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the foreign currency rate 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 corrects a test failure related to user access permissions within the Odoo Enterprise payroll system. A change was made to allow specific group access to the GOSI API, resolving a technical issue that prevented automated testing. This ensures consistent and reliable payroll testing.
Original PR description
The test_employee_fields_groups unit test from hr/tests/test_self_user_access.py was not successful on the runbot due to access restriction. I added the groups parameters to the l10n_sa_gosi_api_is_available field definition in the hr_employee extension from the l10n_sa_hr_payroll_gosi module. Runbot error: 233954
This update resolves a bug that prevented users who are employees in multiple companies from accessing their timesheets. The fix ensures the correct company-specific resource is selected, allowing seamless timesheet access. This improves usability for employees managing time across different business units.
Original PR description
In this commit, we fix an issue that occurs when opening Timesheets with the current user being an employee in multiple companies. Previously, an error was raised because there are multiple resources associated to the current user. The issue is fixed by selecting the resource associated to the employee of the current user in the current company. # Steps to reproduce the issue - Create new company and select it - Go to "users", select current user (i.e., admin) and click on "create employee" (must be in debug mode) - Open timesheets # Expected Behavior - Should open the timesheets of the current user in the current company # Current Behavior - Crashes as there are multiple resources for the user (one per company) task-5729113
This update resolves two issues related to overtime calculations. First, it prevents the creation of overtime work entries when no 'paid' rules are present in a ruleset. Second, it corrects a bug where regenerating work entries caused shifts in hours between consecutive days. This ensures accurate overtime tracking and payroll processing.
Original PR description
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that…
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that normally generates overtime. - Navigate to the work entries in payroll. - Overtime work entries are created! This fix will skip generating work entries when their will be no `paid` rules in a ruleset. # Bug 2: ## Steps to reproduce: - Create attendances with overtime for multiple consecutive days. - Navigate to Work Entries in Payroll. - Click on Reset->"Regenerate Work Entries” on the same period for bulk regeneration. - Observe that attendance and overtime hours are shifted between days. ### Fix: In `_get_overtime_intervals`, the overtime list was recreated inside the per-day loop, causing previously computed overtime intervals to be lost when multiple days were involved. Overtime intervals are now accumulated per resource across all days in the requested range before building the final Intervals. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151) Forward-Port-Of: odoo/enterprise#104295 Forward-Port-Of: odoo/enterprise#103028
This update resolves an error that occurred when users deleted the 'Balance' line in the General Ledger Report. The fix prevents the report from crashing when a balance isn't present, ensuring a smoother user experience. This improves the reliability of a core accounting function.
Original PR description
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting >…
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting > Configuration > Accounting (section) > Accounting Reports - Open the General Ledger report - Delete the balance line from the Column tab - Go to Reporting > General ledger >> Error occurs (If an error does not occur, try opening the detailed view of the journal in the report.) Error: `KeyError: 'balance'` This issue was generated because at code line [1] tries to access `balance` key from the `colname_to_idx[col_group_key]` but since the user deleted `balance` it will not fount there and we got an error. This commit fixes the issue by preventing the processing of `line_balance` when the balance key is not present in `colname_to_idx[col_group_key]`. [1]: https://github.com/odoo/enterprise/blob/340abdc1b00df4d3d6130b26650519ae8354d199/account_reports/models/account_general_ledger.py#L326 sentry-7105657812 Forward-Port-Of: odoo/enterprise#104170 Forward-Port-Of: odoo/enterprise#102113
This update fixes a minor issue where the employee onboarding tour sometimes finished prematurely, leaving the form in an incomplete state. This prevented users from properly completing the tour and accessing related features. The fix ensures the tour waits for form autosaves, guaranteeing a clean and functional experience.
Original PR description
This commit fixes an indeterministic error in the hr_salary_calculator_tour where, sometimes, the last tour's steps finish too quickly and doesn't wait for the form's autosave (triggered by the employee autocomplete selection) to complete, leading to a "Tour finished with a dirty form view being open" error. This is kind of a follow-up of https://github.com/odoo/enterprise/commit/5497e947cdfa242c090a3d77d900375bfb067b0f runbot-237794 Forward-Port-Of: odoo/enterprise#104725
This update fixes a problem that occurred when Odoo servers stopped, causing errors related to database connections. The fix ensures 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
A recent test failed due to a problem with how payment providers were linked to companies within the demo data. This update ensures that each website has only one payment provider assigned, and that provider's company is aligned with the website's company information. This prevents errors and improves the reliability of the website's payment functionality.
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 preventing branch companies from registering for Peppol when sending from the parent company. The change allows users to correctly activate Peppol in both the main and branch companies, ensuring seamless integration with the Peppol network. This improves the ability to utilize Peppol for international payments.
Original PR description
1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company; 3. Activate Peppol in the branch and select "Send from parent company"; => Error message: "Cannot register a user with a receiver application". opw-5725278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244520
This update resolves an issue that prevented users from 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 for the company partner. This improves the reliability of SAFT report generation.
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 a reporting issue related to Bebat, a Belgian organization recycling batteries. It ensures the correct tax codes (64 for 'Special agreement' and CAV for 'Battery collection and recycling') are used when generating UBL invoices, aligning with Bebat's activities and regulatory requirements.
Original PR description
[FIX] account_edi_ubl_cii: EPD allowance/charge code should be 64, not 66 64 stands for "Special agreement" 66 stands for "New outlet discount" opw-5478324 [FIX] account_edi_ubl_cii: Bebat allowanceChargeReasonCode should be CAV Bebat is a non-profit organization in Belgium that collects, sorts, and recycles used batteries. Currently, whatever the recycling tax applied, we report is as AEO for "Collection and recycling - The service of collection and recycling products." However, since Bebat is about recycling batteries, we have to use CAV instead for "Battery collection and recycling - The service of collecting and recycling batteries." opw-5474752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243064
This update resolves a crash issue within the website builder when users customize shadow properties. The fix prevents errors caused by mismatched shadow formats, ensuring a more stable experience for users modifying column styles. This improves the overall reliability of the website builder.
Original PR description
Forward-Port-Of: odoo/odoo#244244
This update resolves a technical issue preventing a key test for embedded actions in the Odoo web interface. The fix ensures the test correctly handles the opening of dropdown menus, improving the reliability of our action testing process. This contributes to a more stable and functional Odoo experience.
Original PR description
In this commit, we fix an embedded action test that failed because when clicking on the sliders to show the top bar, the dropdown was directly opened as there is only one visible action (since this commit: https://github.com/odoo/odoo/pull/208005/commits/a5709e870e033b83d50a2f581c81cceb2a98d91b). We then adapt the test to wait for the dropdown to open automatically, and then when it's the case, create the new custom embedded action. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244508
This update fixes a performance issue in the translation sidebar. By preloading translated elements, the sidebar now renders fully before tests begin, preventing delays and ensuring tests pass consistently. This improves the reliability of our translation testing process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#244519 Forward-Port-Of: odoo/odoo#242490
9 changes
Enhancements 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
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
11 changes
New functionality added to Odoo
This update introduces seamless integration with the Australian Taxation Office (ATO) for Single Touch Payroll (STP) submissions and superannuation contributions. It ensures compliance with Australian regulations by securely accessing the ATO's Super Choice API and implementing audit logging for tracking payroll changes.
Original PR description
This module adds single-touch payroll integrations with the ATO using the Super Choice API. The IAP server is used in the middle to ensure security and prevent unauthorised access to the ATO's API. It includes the following features: - Employer registration for STP - STP submission and retrieval of STP reports - Super Choice API integration for super contributions (Compliance Requirement) Add audit logging for Australian Payroll. A mixin that logs the selected field changes in the l10n_au.audit.log model. This is later synced to the IAP server. Add security constraints for STP compliance. Tasks: 4201473 4201471
Enhancements to existing features
This update enhances the reliability of communication between Odoo and external services (IAP server) by allowing longer timeout periods for requests. Previously, a default 30-second timeout could cause delays when multiple external API calls were needed. Now, administrators can adjust the timeout to ensure these requests complete successfully, preventing potential disruptions to financial processing.
Original PR description
Some requests may require a longer timeout than the default 30 seconds when pinging the IAP server as they may need several external API calls. This commit adds a `request_timeout` argument to the `_make_request` method to allow specifying a custom timeout value for the request. 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 incorporates the latest Romanian VAT regulations, specifically the addition of 11% and 21% tax rates. The changes ensure that Odoo correctly handles these new rates within fiscal positions, maintaining accurate accounting and tax reporting for Romanian businesses.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#243452
Resolved issues and error corrections
This update resolves an issue where updating BoM quantities on draft manufacturing orders could trigger errors. The fix ensures BoM updates are handled correctly, preventing crashes and maintaining accurate inventory calculations. This improves the stability of the production workflow.
Original PR description
Description of the issue/feature this PR addresses: Updating quantities in a Bill of Materials (BoM) on a draft Manufacturing Order (MO) and clicking the “Update BoM” button could trigger an error.…
Description of the issue/feature this PR addresses: Updating quantities in a Bill of Materials (BoM) on a draft Manufacturing Order (MO) and clicking the “Update BoM” button could trigger an error. This happens because the _link_bom function unlinks existing mrp.workorders before writing to product_qty, causing the _compute_qty_remaining compute on now-unlinked workorders to fail. Closes #243774 Current behavior before PR: - Editing a BoM quantity on a draft MO and pressing “Update BoM” sometimes raises an error. - The system fails to properly update mrp.workorder quantities after unlinking existing workorders. Desired behavior after PR is merged: - The BoM can be updated safely on draft MOs without raising errors. - Moves and workorders are unlinked only after the BoM is reassigned. - `product_qty` and `product_uom_id` are safely reset, and `_compute_qty_remaining` runs correctly. - Overall, the draft MO workflow behaves as expected, avoiding crashes when updating BoMs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where product names on invoices were being incorrectly concatenated due to newline characters. The fix replaces newlines with spaces, ensuring names and descriptions remain readable and adhere to API specifications, preventing data processing errors. This improves invoice accuracy and compliance.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120
This update corrects a previous error that prevented the installation of the `l10n_mx_hr_payroll` module. The demo company's name has been restored and updated to align with other accounting modules, ensuring proper functionality and installation.
Original PR description
This is a fix of commit 6bf73fe9e7fdba62411bee188a28f7ad4c489093 that mistakenly removed the demo company's name in `l10n_mx_hr_payroll`. As a result, the installation of `l10n_mx_hr_payroll` fails (unless `l10n_mx` is installed, in which case the demo company already exists). We need to reinstate the demo company's name, while changing it to `ESCUELA KEMPER URGATE` for consistency with the accounting modules. runbot-237826
This update fixes a technical issue that caused errors when Odoo servers were shut down. Specifically, a problem with how server stops handled database connections resulted in errors. This change ensures a smoother and more reliable server shutdown process, preventing disruptions.
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 fixes an error in the Swiss VAT reporting module (l10n_ch) that caused negative values to be displayed for reverse charge tax figures. The fix adjusts how these figures are calculated to ensure accurate VAT reporting for foreign vendor transactions.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244452
A test was failing due to a sale order not requiring payment. This update forces the sale order to always require payment, ensuring the test now passes. This resolves a technical issue that could have impacted the reliability of the website sale functionality.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244322
This update fixes an issue where discounts on non-subscription products within subscriptions were being reset to zero after the subscription's start date was set. The change ensures that discounts are correctly retained during temporal computations, providing accurate pricing for subscription orders. This improves the reliability of subscription pricing calculations.
Original PR description
Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring…
Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring plan 4. Add a non-subscription product to the order line 5. Manually set the Discount field to any non-zero value 6. Save the subscription 7. Open the Other Info tab, set the Start Date, and save again Observation: ----------------------------------- After saving the start date, the Discount value on the order line is reset to 0.00 Issue: ----------------------------------- https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777 For regular products, In the discount recomputation logic, the discount is explicitly set to 0 before checking for a pricelist. When a pricelist is present the computation continues to the next iteration, leaving the discount already reset This issue only affected non-subscription products because subscription products have their own discount computation logic in `sale_subscription` https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97 This implementation preserves discounts during temporal computations (start_date) and doesn't rely on pricelist rules Solution: ----------------------------------- Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all Related community PR: https://github.com/odoo/odoo/pull/242759 opw-5428077
This update fixes an issue where discounts on non-subscription products within subscriptions were being reset to zero after the subscription start date was saved. The change ensures that discounts set manually on order lines are correctly preserved during subscription calculations, particularly when pricelists aren't involved. This improves the accuracy of pricing for subscription orders.
Original PR description
Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring…
Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring plan 4. Add a non-subscription product to the order line 5. Manually set the Discount field to any non-zero value 6. Save the subscription 7. Open the Other Info tab, set the Start Date, and save again Observation: ----------------------------------- After saving the start date, the Discount value on the order line is reset to 0.00 Issue: ----------------------------------- https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777 For regular products, In the discount recomputation logic, the discount is explicitly set to 0 before checking for a pricelist. When a pricelist is present the computation continues to the next iteration, leaving the discount already reset This issue only affected non-subscription products because subscription products have their own discount computation logic in `sale_subscription` https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97 This implementation preserves discounts during temporal computations (start_date) and doesn't rely on pricelist rules Solution: ----------------------------------- Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all Related Enterprise PR: https://github.com/odoo/enterprise/pull/103639 opw-5428077
3 changes
Enhancements to existing features
This update adjusts the size of the 'Fapiao' field in the Chinese localization (l10n_cn) module to 20 characters. Previously, it was limited to 8 characters, which caused issues with longer invoice numbers. This change ensures accurate data capture and avoids data loss when recording Chinese invoices.
Original PR description
with this commit:- - We're changing the char size to 20 from 8. - We remove the constraint that prevents us from saving the record if the size is not 8. task-5501485
This update ensures our Peruvian EDI (l10n_pe_edi) tests accurately reflect recent changes in the UBL standard. Specifically, the tests now account for a new 'DeliveryParty' node that was added, ensuring proper processing of invoices according to current regulations. This improves the reliability of our Peruvian accounting module.
Original PR description
This commit is a part of a bigger commit on the community PR side. Tests on `l10n_pe_edi` have been updated to reflect the latest change; where the `DeliveryParty` node is now added (previously it was never filled). related-community-PR: https://github.com/odoo/odoo/pull/243590 task-4891206
Resolved issues and error corrections
This update backports key testing components and fixes related to UBL (Universal Business Language) invoice generation in Odoo. Specifically, it addresses issues caused by changes in the UBL XML format, ensuring accurate test results and compliance. The changes improve the reliability of UBL invoice exports, crucial for accurate accounting and reporting.
Original PR description
*: `account`, `l10n_account_edi_ubl_cii_tests` This commit backports the AccountTestInvoicingCommon test helpers (in particular for record creation and XML save/assert mode) and also the new UBL…
*: `account`, `l10n_account_edi_ubl_cii_tests` This commit backports the AccountTestInvoicingCommon test helpers (in particular for record creation and XML save/assert mode) and also the new UBL tests developed by Laurent in 18.0, in 17.0. A couple fix was also backported to ensure the asserted test files stay as similar as possible betweeen the new versions and 17.0: - `cac:DeliveryParty` node now have `cac:PartyName` > `cbc:Name`, instead of `cac:Party` > (...) - allowance charge reason code for EPD taxes is now 64 instead of 66 - allowance charge reason code for fixed taxes is now conditional either 'AEV' or 'CAV' - added multiplier factor node - add tax currency node when the currency of the invoice is not the same as the company - prevent raising the constraint when having a python tax in the invoice These changes affected the general UBL XML generation, and caused some tests on `l10n_account_edi_ubl_cii_tests` to fail, most commonly because they're missing the `TaxCurrencyCode` as they were written without using local currency in mind. These errors have been corrected in their respective files. related-enterprise-PR: https://github.com/odoo/enterprise/pull/104758 task-4891206