Daily updates from Odoo
Navigate
Branch
Thursday, January 15, 2026
227 changes
22 changes
Enhancements to existing features
This update improves the Odoo Guatemala localization by adding necessary accounting accounts and configuring asset models for managing fixed assets. This allows businesses operating in Guatemala to accurately track their financial transactions and depreciation schedules within Odoo.
Original PR description
This commit updates the Guatemala localization to include missing accounts and configures the Asset Models for fixed assets management. Changes: -Updated `account.account` to include new accounts for fixed assets and expenses. -Added `account.asset` data to handle automated depreciation for various asset types. task-5149265 Forward-Port-Of: odoo/odoo#240487
Resolved issues and error corrections
This update resolves an issue where the 'Add to Cart' button on product pages was refreshing the entire page instead of opening a modal. The fix changes the button's type to 'button', ensuring the modal pop-up functionality works as intended, improving the customer's shopping experience.
Original PR description
[Issue] Customer embedded the "Add to Cart" button id="s_add_to_cart" to the [form](https://github.com/odoo/odoo/blob/edaa02dc0e67d6ccd17cc3be9a98d94276bcd403/addons/website_sale/views/templates.xml#L2066) inside the product webpage. By default, buttons inside forms use the type="submit" attribute, which causes the form to refresh after the button is clicked. Therefore, the modal pop-up is essentially rendered useless because it just refreshes the page. [Solution] added type="button" to the button inside "s_add_to_cart" to make it a normal button without the "submit" functionality opw-5417500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241694
This update resolves an issue where the 'Source Document' field was incorrectly empty after reversing invoices. This meant users couldn't easily track the original invoice linked to the reversed transaction. The fix ensures that the correct invoice origin is displayed during reverse moves, improving reporting and reconciliation accuracy.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
A technical bug related to a record rule was causing a crash when opening contacts. This fix resolves an ambiguous column reference within the system's query logic, ensuring the contact application functions correctly. The update prevents a traceback and improves overall stability.
Original PR description
### Issue: When creating a record rule on moves using partners, a traceback is raised when opening a contact. ### Steps to reproduce: - Install 'account_followup' and 'contacts' - In Settings >…
### Issue:
When creating a record rule on moves using partners, a traceback is raised when opening a contact.
### Steps to reproduce:
- Install 'account_followup' and 'contacts'
- In Settings > Technical > Security > Record Rules create a new rule
- name: Test Rule
- model: Journal Entry
- definition: `[('partner_id.is_company', '!=', True)]`
- Open the Contact app and try to open a contact
- Traceback
### Cause:
The newly created rule is used in the query computed by `_compute_has_moves()`. To do this the tables 'account_move' and 'res_partner' are joined. Then `subselect()` simply adds the select element with the string it is given, resulting in:
```sql
SELECT commercial_partner_id
FROM "account_move"
LEFT JOIN "res_partner"
...
```
But both `account_move` and `res_partner` have a column named "commercial_partner_id" resulting in an ambiguous column reference traceback.
### Solution:
We need to add precision on which table should be used. `subselect()` cannot guess which one should be used. We cannot add the precision in the definition of `field_names` because it is not compatible with the domain used by `_search()`.
So we add `'account_move.'` to the field name before giving it to `subselect()`.
opw-5467608
Forward-Port-Of: odoo/enterprise#103792This update fixes an issue where matching a partner by bank account could inadvertently overwrite a previous match found by name. Now, the system prioritizes the bank account match, ensuring accurate partner identification when processing bank statements. This improves data reliability and reduces potential errors.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update corrects a technical issue where bank statements were incorrectly granted elevated permissions. Removing this sudo access enhances security and ensures proper data access controls within the Odoo accounting system. This change improves the overall stability and security of the SaaS platform.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243161 Forward-Port-Of: odoo/odoo#242771
This update resolves an issue where multiple actions on a device weren't consistently recognized. By providing a unique session ID in the response, the system now correctly handles concurrent actions, ensuring users receive confirmation for all initiated tasks. This improves the reliability of device interactions.
Original PR description
Instead of passing `session_id` in the device class parameters, we provide it directly in the response dictionary, in order to allow concurrent actions on the device. Before this commit: - send an action from a PoS: `session_id` is set to `1`, - before the end of the execution, send a second action from the same PoS on the same device (e.g. on another browser): `session_id` is updated to `2`, - you get only one confirmation in the PoS. After this commit: we get both confirmations. Forward-Port-Of: odoo/odoo#243155 Forward-Port-Of: odoo/odoo#243031
This update corrects a display issue where product prices were incorrectly shown as excluding tax, even when tax-included settings were selected in the Point of Sale system. The fix adjusts how prices are calculated to accurately reflect the chosen tax settings, ensuring consistent and correct price displays for users.
Original PR description
Steps to reproduce ------------------ 1. Set the PoS taxes display to tax-included 2. In PoS, add a product, change its quantity to 2, and change its price too Notice that the new price / unit is shown as price excluded, even though we set the prices to tax-included in the PoS settings. Reason ------ We were using the getter `currencyDisplayPriceUnit` which uses `displayPriceUnit` which always shows the price as `tax_exluded`. Fix --- Now we change `displayPriceUnit` to adapt to the `iface_tax_included` config in PoS. That follows well the convention used for the non-unit price getter, `displayPrice`. For the cases where we want to explicitly use the tax excluded unit price, we have created the getters `displayPriceUnitExcl` and `currencyDisplayPriceUnitExcl` for that, which replaces some usages of the old getters. opw-5405572 Forward-Port-Of: odoo/odoo#240091
This update resolves an issue where the price display in the Point of Sale (POS) system was incorrect. The fix replaces a string-based currency display unit with the correct numeric display unit, ensuring accurate price presentation for customers. This improves the overall user experience and prevents potential pricing errors.
Original PR description
We were using `currencyDisplayPriceUnit` inside `Math.sign()`. However, `currencyDisplayPriceUnit` returns a string. Now we use `displayPriceUnit`. opw-5405572 Forward-Port-Of: odoo/enterprise#102160
This update fixes a calculation error related to employee offers for part-time roles. Previously, the system incorrectly attempted to adjust percentages based on full-time salaries. Now, the system accurately reflects the gross salary or employer cost set for part-time offers, streamlining the offer creation process.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer Forward-Port-Of: odoo/enterprise#103936
This update fixes a minor issue where search errors were hidden, now consistently displaying a helpful 'Domain is invalid' message. Additionally, the search logic has been optimized for performance and allows users to easily filter for records that don't meet specific criteria (e.g., 'Is Not Set').
Original PR description
Search method logic was rewritten so since commit:
https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa
`raise NotImplementedError(_("some text"))`
no longer raises an error nor does it ever show the error message. Instead a notification that says "Domain is invalid. Please correct it" is always displayed when the method is unable to run the search. Therefore we update the legacy way of doing it in these search methods so that the code is clean (i.e. so no one copies it) and to avoid translating strings that will never be visible.
Additionally, the search logic was also updated such that the `value` exists is no longer needed and the `=`/`!=` operators are handled by `in` for optimized code. This change makes it so users can now do the "Is Not Set" search since it will return only the records that do not match the "Is Set" logic.
Forward-Port-Of: odoo/enterprise#104115This update corrects a bug where customer statements incorrectly showed zero amounts due in certain reconciliation scenarios. The fix ensures that outstanding balances, including partially reconciled invoices, are accurately reflected in the Customer Statement. This improves the accuracy of financial reporting and customer account management.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update fixes an issue where popups added to product descriptions on the website sale page were appearing behind the product images. The fix ensures popups are always displayed above images, improving the user experience and preventing disruptions when adding information to product details. This change was made to enhance visual clarity and usability.
Original PR description
Steps to reproduce: =================== - Go to website sale & pick any product. - Go to edit mode & drop a popup in the product description -> Popup appear behind of the product image. Cause: ===== Product popups inserted inside the description column (#product_details) inherit it's z-index, while the adjacent .o_wsale_product_images column stays with z-index: 1. Since the details column z-index: 0, any popup inside it remained under the image column. Solution: ========= Override the z-index only when a popup is present opw-5458436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243136
This update ensures that the wizard automatically closes after report downloads, regardless of whether a custom report handler (like for IoT) is used. Previously, using a custom handler caused the wizard to remain open, leading to an inconsistent user experience. This fix maintains the expected behavior of closing the wizard after a report is successfully printed.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
This update corrects a database error that prevented the Tax Report from properly expanding invoice lines. The fix ensures accurate report generation by using the correct table alias to retrieve tax descriptions. New test cases have been added to verify the report's functionality and hierarchical structure.
Original PR description
Before: The `query_tax_lines` method was incorrectly using the account tag alias to access the `description` field, which does not exist on that table. This caused a database error when expanding invoice lines from the Tax Report. After: Now the query correctly uses the `account_tax` table alias to fetch the tax description. - Also added test cases for sales and purchase reports to ensure correct generation of report lines and proper expansion of the hierarchical structure. task-5461512 Forward-Port-Of: odoo/enterprise#103668
This update fixes an issue where tax invoices in Thai were consistently displaying the branch name in English. The change ensures the branch name is now translated based on the language setting of the customer's account, improving accuracy and a better user experience for Thai-speaking clients. This was a minor fix to improve localization.
Original PR description
Currently, l10n_th_branch_name is not translatable. Regardless of the language setting, it is printed in English on the tax invoice. This PR addresses that. Task-5438534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242484
This update corrects a discrepancy in ZATCA invoice XML generation, ensuring accurate line amounts and preventing validation errors. The fix addresses an issue where rounding differences between line items and the overall tax amount were causing ZATCA to reject the invoices. This ensures invoices are correctly formatted for ZATCA submission.
Original PR description
**Steps to reproduce:** * Install the **l10n_sa_edi** and **accounting** modules. * Create a **15% tax** (tax-included). * Create a customer invoice with two lines with amounts 18 and 14 and apply…
**Steps to reproduce:**
* Install the **l10n_sa_edi** and **accounting** modules.
* Create a **15% tax** (tax-included).
* Create a customer invoice with two lines with amounts 18 and 14 and apply
the tax on an invoice line.
* Post the invoice and **send it to ZATCA**.
* Review the generated XML or submit it for ZATCA validation.
**Observed behavior:**
* The XML nodes **LineExtensionAmount**, **TaxAmount**, and
**RoundingAmount** contain inconsistent values.
* ZATCA validation raises warnings due to rounding mismatches.
* Example:
* in xml data look like this
* `15.66(LineExtensionAmount) + 2.34(TaxAmount) != 17.99(RoundingAmount)`(v19)
* The required relation
**LineExtensionAmount + TaxAmount = RoundingAmount**
is violated.
**Cause:**
* In v19.0, `_round_base_lines_tax_details()` distributes rounding deltas so
that the **sum of rounded line taxes** matches the **rounded global tax**.
* When taxes are **included in price** and there are **multiple invoice lines**,
this distribution adjusts the per-line tax and base amounts.
Example pattern:
* Raw line taxes sum to something like **4.1739…**
* Rounded global tax = **4.17**
* Sum of individually-rounded line taxes = **4.18**
* A **-0.01 delta** is distributed across the lines
* Result:
* Line 1 base becomes **15.66**, tax **2.34**
* Line 2 base becomes **12.17**, tax **1.83**
So the XML correctly reports:
* **LineExtensionAmount = 15.66**
* **TaxAmount = 2.34**
* However, **RoundingAmount** is computed differently:
https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L439-L444
* Here, `base_line['tax_details']['total_excluded_currency']` **does not include the distributed delta**. It still reflects the *pre-distribution* base (e.g. **17.99 total excluded**), while **LineExtensionAmount** uses `vals['total_excluded_currency']`, which *does* include the delta.
* Result: the required identity
`LineExtensionAmount + TaxAmount = RoundingAmount`
is broken — producing inconsistencies such as:
`15.66 + 2.34 ≠ 17.99`
**Fix:**
* Use the same **vals[total_excluded_currency]** as it has a tax-excluded price with the delta included.
opw-5402750
Forward-Port-Of: odoo/odoo#240833This update resolves a minor typo within the Odoo Enterprise system. The change ensures the naming of attachment files accurately reflects their associated external IDs and functionality, improving data consistency. This fix prevents potential confusion and ensures proper system operation.
Original PR description
Fix typo – Correct the ir_attachment file name to match the external ID and its functionality. OPW-5428700 Forward-Port-Of: odoo/enterprise#103809
This update fixes an issue where preparation timers for courses within a restaurant order were incorrectly shared. Now, each course has its own dedicated timer, ensuring accurate timing for preparation steps and improving the overall order flow. This enhances the restaurant's operational efficiency and customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update fixes an issue where the Point of Sale system couldn't reliably find customer records, particularly with demo data. A new setting allows searching both local and server-based customer records, resolving offline test case failures and ensuring accurate customer retrieval.
Original PR description
before this commit: - By default, clicking on a customer only searched local records. - Since the local cache is limited to 100 customers, with demo data it was possible that the required customer was not found. after this commit: - Added 'pressEnter' boolean parameter to search more to also fetch customers from the server. - The boolean parameter was introduced because some test cases require offline mode where fetching from the server would cause issues. runbot-232714, 232715 Forward-Port-Of: odoo/odoo#228786
This update resolves a minor issue with the automated tests for the Helpdesk Live Chat module. The fix ensures the tests run smoothly and reliably, improving the overall stability of the Helpdesk feature. This change focuses on internal testing processes and doesn't impact end-users.
This update resolves an issue where Nilvera e-invoice synchronization was causing conflicts between sales and purchase document updates. By using unique configuration keys based on the transaction type (sale or purchase), the system now ensures that each flow can independently fetch and update invoices without interference, leading to more reliable data synchronization.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently,…
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently, this parameter is shared between sales and purchase flows, causing their synchronization states to overwrite each other. # Current behavior before PR: When sales and purchase documents are synchronized from Nilvera, both flows use the same configuration parameter to store the last fetched date. As a result, running one synchronization (e.g. sales) may prevent the other flow (e.g. purchases) from fetching new documents, leading to missing or incomplete imports. # Desired behavior after PR is merged: Sales and purchase synchronizations maintain independent last fetched dates by using journal-specific configuration keys. This allows both flows to run reliably and incrementally without interfering with each other. taskId - 5494295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243791
7 changes
Enhancements to existing features
This update enables public users to access documents without needing to create a traditional Odoo user. When a user invites a public member, they can now create a linked user account, streamlining the document sharing process and improving user convenience. This change simplifies document access for external partners.
Original PR description
Purpose ======= We can share a document to a partner without a user, and with `access_via_link == 'none'`. In that situation, the partner is forced to create a user, but if he clicks on signup, then the new user won't be linked to the partner set on the `documents.access` (a new partner will be created). Now, when inviting a member, if he doesn't have a user, we invite him to create a user. If the partner has a user, then we just redirect him to the login page. Task-5242208 Forward-Port-Of: odoo/enterprise#104339 Forward-Port-Of: odoo/enterprise#100628
Resolved issues and error corrections
This update resolves an issue where a payroll rule parameter setup could trigger a system error. The fix ensures that computed fields are always initialized, preventing errors when conditions aren't met. This improves the stability and reliability of payroll calculations.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update fixes an issue where preparation timers for courses within a restaurant order were incorrectly shared. Now, each course has its own dedicated preparation timer, ensuring accurate timing and a better customer experience. This improves the reliability of order preparation workflows.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update fixes a potential issue where applicants could incorrectly reopen and re-sign expired job offers. The system now prevents access to these offers, ensuring data integrity and a smoother applicant experience. A database constraint has also been added to enforce valid offer durations.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#103734 Forward-Port-Of: odoo/enterprise#101834
This update resolves two issues impacting the Knowledge editor. First, it prevents copy-pasting headings from causing URL redirection problems by resetting unique identifiers. Second, it stabilizes the heading link button by throttling mouse movements, reducing unnecessary page reloads.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684
A technical issue preventing users from creating and saving bank statements within the Bank Journal Transactions module has been resolved. The fix addresses a problem where the system couldn't access necessary data, resulting in an error. This ensures users can now correctly create and save bank statements.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#101232
Shopee has updated the API paths used for testing their integration with Odoo. This update requires a change to the Odoo testing environment to ensure continued functionality. The team has corrected the API path configuration to align with Shopee’s new requirements.
Original PR description
Shopee has changed the API path and the original testing API paths are no longer valid. Forward-Port-Of: odoo/enterprise#103939
14 changes
Enhancements to existing features
This update enables public users to access documents via a link, simplifying document sharing. Previously, users without accounts were forced to create one, but this change allows them to register directly, linking their account to the document access, improving the user experience.
Original PR description
Purpose ======= We can share a document to a partner without a user, and with `access_via_link == 'none'`. In that situation, the partner is forced to create a user, but if he clicks on signup, then the new user won't be linked to the partner set on the `documents.access` (a new partner will be created). Now, when inviting a member, if he doesn't have a user, we invite him to create a user. If the partner has a user, then we just redirect him to the login page. Task-5242208 Forward-Port-Of: odoo/enterprise#104339 Forward-Port-Of: odoo/enterprise#100628
Resolved issues and error corrections
This update resolves a migration issue preventing the Odoo 18.3 version from properly updating from 16.0 for Italian businesses. The fix adds a missing column, 'l10n_it_exempt_reason', required during the migration process. This ensures a smooth and successful upgrade for Odoo's Italian localization.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
This update resolves a technical issue that prevented the creation of payroll rule parameters with future dates, resulting in a system error. The fix ensures that the system correctly handles these parameters, improving the stability and usability of the payroll configuration. This change avoids potential disruptions to payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update fixes a display issue in the restaurant order preparation screen (PDIS) where the first course's timer incorrectly showed 0 until the second course was initiated. Now, each course accurately reflects its preparation time when it's added to the order, ensuring accurate timing for kitchen staff and customers.
Original PR description
Before this commit: -- - In the preparation display (PDIS), the first course shows a preparation time of 0 untill the second course is fired. - After course 2 fired, course 1 and course 2 have same preparation time value. After this commit: -- - Each course shows its correct preparation time when fired. task-5421616 Forward-Port-Of: odoo/odoo#241251
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific configuration with a single value in a free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791This update adds two missing Unit of Measure (UoM) codes – MIN (Minute) and KWH (Kilowatt hour) – to Odoo, aligning with UNECE Recommendation No. 20 for Peppol. This ensures proper support for UBL/CII electronic invoices, resolving an issue where the default 'Units' code was used instead, and addresses a need identified by localization modules.
Original PR description
**Issue:** 2 UoM that is in the UNECE Recommendation No.20 for Peppol don't exist in Odoo: - MIN: Minute - KWH: Kilowatt hour Even if they are created manually, they are not used in the UBL/CII electronic invoices. Instead, the default code (i.e. "C62" for "Units" is used). Some localization modules create the "Kilowatt hour" UoM as they need it. (l10n_cl and l10n_tr_nilvera) So it's better to have a "generic" one available for every module. opw-5269119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243535 Forward-Port-Of: odoo/odoo#238342
This update fixes a validation error that occurred when creating partial backorders within wave transfers. The issue stemmed from the system incorrectly identifying an active batch as a candidate for new backorders, leading to a user error. This change ensures that the current batch is excluded during the auto-batch process, resolving the validation conflict.
Original PR description
## How to reproduce: - Enable Wave transfert in setting - Go to the Receipt Operation type: - Create Backorder: always - Automatic Batches: Enabled - Wave Grouping: Products - Create and confirm…
## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
- Create Backorder: always
- Automatic Batches: Enabled
- Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."
## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.
## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.
OPW-5413921
---
Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ...
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ======================================================================
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
wave.action_done()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
return pickings.with_context(**context).button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
res = super().button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
records.write({self.name: write_value})
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
self.batch_id._sanity_check()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243519This update corrects a bug where clicking 'Back' in the cart sometimes caused unexpected product additions. The fix clarifies the trigger used to add products, preventing duplicate actions and ensuring consistent cart behavior. This improves the overall user experience and reduces potential errors during checkout.
Original PR description
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ... With the following scenario, step CartPage.clickBack() can take few…
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ...
With the following scenario, step CartPage.clickBack() can take few times to show the back screen, but as the trigger is the same for clickProduct on a product list screen than a cart screen, the last step clik on "o_self_product_box" ... but in the cart (and not in the product list)
ProductPage.clickProduct("Coca-Cola"), => OK
ProductPage.clickProduct("Coca-Cola"), => OK
Utils.clickBtn("Checkout"), => OK
CartPage.checkProduct("Coca-Cola", "5.06", "2"), => OK CartPage.clickBack(), => OK
ProductPage.clickProduct("Coca-Cola"), => NOK
To fix it, it is enought to just be more precise on the trigger to avoid confusions.
This fix fixes probably a pair of tours.
error-runbot-id~227669
(and probably others)
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-prThis update fixes an issue where the DDT number was missing from delivery confirmation reports for Italian companies. The change ensures the DDT number is generated and included before the email is sent, resolving a reporting discrepancy. This improves the accuracy and completeness of delivery documentation.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update automatically corrects discrepancies between check amounts and payment amounts when using third-party checks for vendor payments. Previously, users had to manually adjust payment amounts, leading to errors and delays. This change ensures accurate payment processing and eliminates manual intervention.
Original PR description
Current behavior: when using third-party checks to create vendor payments, withholding amounts are creating a difference between the checks amount and the payment amount, resulting in a warning and requiring manual adjustment of the payment amount until the amount minus withholdings matches checks amount. Solution: adding an automated adjustment algorithm to the wizard. task-4257629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219922
This update resolves an issue where group chat channels (group DMs) were displaying incorrect status information, leading to confusing user experiences like a 'back on' banner and incorrect IM status. The fix removes a calculation that caused this behavior, ensuring group DMs display their status accurately.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243628 Forward-Port-Of: odoo/odoo#242058
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 forced invoice requirement for settlement orders, allowing users to complete payments without generating duplicate e-invoices to ZATCA.
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#243604 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user canceled a payment attempt. By resetting the order flag, this prevents incorrect processing and ensures compliance with integration rules. This improves order accuracy and avoids potential errors.
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#104197 Forward-Port-Of: odoo/enterprise#98463
This update fixes a reporting issue related to Bebat, a Belgian organization recycling batteries. It ensures that recycling taxes are correctly identified as 'Special Agreement' (64) or 'Battery Collection and Recycling' (CAV) instead of the previous 'New Outlet Discount' (66) or 'Collection and recycling' (AEO) classifications, aligning with 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
2 changes
Resolved issues and error corrections
This update addresses a technical issue related to how Odoo handles deleted records, specifically those linked to emails and activities. The change ensures that Odoo doesn't unnecessarily query related records after a cascade delete, improving performance and stability. This is a critical fix to prevent potential slowdowns.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104095 Forward-Port-Of: odoo/enterprise#101185
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing documents sent from records they couldn't access. The system now verifies read access to the related record before redirecting, ensuring a smoother sign-off experience for all users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#100961
22 changes
New functionality added to Odoo
This update introduces a new connector to seamlessly integrate Lazada sales orders into Odoo. It automatically imports orders from multiple Lazada accounts, synchronizes inventory levels, and facilitates shipment management, streamlining the fulfillment process for Lazada sales.
Original PR description
* Authorize Lazada shop to be accessed via Lazada API * Import orders from multiple accounts and shops Orders are matched with Odoo products based on their internal reference (item_id or model_id in Lazada) Support for both Fulfillment by Lazada (FBL), Fulfillment by Merchant (FBM): FBL: Importing the completed orders FBM: Delivery information is fetched from Lazada, track and synchronize the stock level to Lazada. * Push inventory levels of matched products to Lazada * Arrange shippment for orders and download shipping label to Odoo task - 3478992 Forward-Port-Of: odoo/enterprise#83214
Enhancements to existing features
This pull request makes small adjustments to the HR Payroll module's user interface. Specifically, the location of a disabled field has been changed. These adjustments are intended to improve the overall usability and clarity of the payroll system.
Original PR description
- changed the position of the disabled field. task-5452740
This update allows system administrators to customize the main Odoo home menu with a message. Administrators can set a configurable message through the database, such as a maintenance notification, ensuring key information is prominently displayed to users. This provides greater control over user communication and alerts.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#104248
Forward-Port-Of: odoo/enterprise#102239Resolved issues and error corrections
This update fixes an issue where preparation timers for courses within a split order were incorrectly shared. Now, each preparation order has its own timer, ensuring accurate timing for each course and improving the restaurant's order fulfillment process. This change enhances the overall customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update ensures that archived employees are no longer included in payroll runs and pay slip forms. This prevents incorrect payments and simplifies payroll processing by focusing only on active employees. The changes remove outdated filters and improve data accuracy.
This update resolves a technical issue that caused a traceback error when removing a selected pay category for employees in the payroll section. The fix ensures the system handles the removal of pay category selections correctly, preventing errors and improving payroll stability. This change impacts the HR Payroll module.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432
This update fixes a minor issue in the Thai tax reporting module where trailing spaces were causing incorrect calculations in tax reports. The change removes this space, restoring the reports to accurately reflect tax liabilities. This ensures data integrity for Thai businesses using Odoo Enterprise.
Original PR description
-Report line formula was converted from Char to Text, which no longer strips trailing spaces. -The fix removes the trailing space from "formula" to restore correct behavior. Related Community PR: https://github.com/odoo/odoo/pull/242462 task-5468804
This update corrects a database error that prevented the Tax Report from properly expanding invoice lines. The fix ensures accurate report generation by using the correct database table for tax descriptions. New test cases have been added to verify the report's functionality.
Original PR description
Before: The `query_tax_lines` method was incorrectly using the account tag alias to access the `description` field, which does not exist on that table. This caused a database error when expanding invoice lines from the Tax Report. After: Now the query correctly uses the `account_tax` table alias to fetch the tax description. - Also added test cases for sales and purchase reports to ensure correct generation of report lines and proper expansion of the hierarchical structure. task-5461512 Forward-Port-Of: odoo/enterprise#104111 Forward-Port-Of: odoo/enterprise#103668
This update fixes a technical issue preventing AI server tools from running correctly. The problem stemmed from an unnecessary inclusion of '__end_message' in tool arguments, causing validation errors. The fix ensures correct tool execution by removing this element before validation.
Original PR description
When executing AI server actions, tools with `ai_tool_schema` defined would fail with "Missing definition for __end_message" error. Root cause: - `_prepare_tools` adds `__end_message` to the schema sent to the LLM - The LLM returns tool calls with `__end_message` in arguments - `_ai_tool_run` validates arguments against the original schema (which doesn't have `__end_message`) - Validation fails with "Missing definition for __end_message" Fix: Use `pop` instead of `get` to extract and remove `__end_message` from arguments before calling the tool executor. This ensures that it's not passed to the tool validation. TASK-ID: 5423756 Forward-Port-Of: odoo/enterprise#103779
This update fixes an issue where the 'Out of Contract' calculation was incorrectly extending beyond the payslip period. The change ensures that contract overlap dates are accurately limited to the payslip's start and end dates, preventing inaccurate payroll reporting. This improves the reliability of employee compensation data.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103539 Forward-Port-Of: odoo/enterprise#100694
This update enhances the logging of errors related to Stripe expense transactions. Specifically, it now captures full traceback information when errors occur during webhook events, providing more detailed insights for troubleshooting. Additionally, a fix was implemented to prevent unnecessary actions when a Stripe card is marked for destruction, ensuring data integrity.
Original PR description
## [IMP] hr_expense_stripe: full traceback logging When a pyhon error is raised during a webhook event we only get the error main line, not the full traceback. This adds the full traceback message to the log ## [FIX] hr_expense_stripe: Fix returned card error When a card is returned to the factory for destruction, when Stripe sends us the information, we sent a payload to stripe. This makes no sense as the card has been updated by Stripe into a state that doesn't allow further changes Forward-Port-Of: odoo/enterprise#103940
This update fixes a dashboard display issue that previously showed incomplete employee information during payroll exports. The changes now correctly list employees without version ID export codes and incorporate Prisma code for a better user experience. This ensures accurate and complete payroll export data.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681
Forward-Port-Of: odoo/enterprise#98389This update fixes a random failure in a key tour that simulates unpacking packages onto pallets within the stock management system. The issue stemmed from a timing conflict during the tour's steps, leading to incomplete actions. The fix adds a verification step to ensure the first pallet line is fully unpacked before proceeding, improving the tour's reliability.
Original PR description
Before this commit, the tour `test_internal_picking_reserved_move_packages_into_new_palet` was randomly failing. In this tour, we have two palets we unpack. The issue is, after unpacked the first one, we complete the second one line and then we unpack it. But it can happen the click on the button to complete the second line was done too quickly (in the meantime the first palet line is unpacked) and thus, because of this race condition, the second palet line was not complete (either it's just a visual bug due to a refresh in the wrong time, either the complete action is dropped due to the first line unpacking action.) To fix that, this commit adds a step to verify the first line is correctly unpacked before going further. runbot-build-error: [237801](https://runbot.odoo.com/odoo/runbot.build.error/237801) Forward-Port-Of: odoo/enterprise#104261
This update resolves a technical error that occurred when a sale order lacked an invoice date. The fix ensures that stock move filters now correctly use either the order's last invoice date or today's date, preventing a traceback and ensuring accurate stock management for subscription orders. This improves the reliability of the subscription order fulfillment process.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
This update resolves an issue where wage calculations were producing incorrect results and causing validation errors when changing working schedules. The changes improve the accuracy of hourly wage calculations by dynamically determining working hours from company calendars and removing unnecessary dependencies, leading to a more stable and reliable payroll system.
Original PR description
- All percentage fields now use self.env.remove_to_compute to break circular dependencies, so UIs no longer need the ad-hoc skip_percentage_calc context. - _l10n_in_get_montly_wage now derives monthly hours from the version’s or its company’s resource calendar via hours/week previously it was static to 22 days. - fix raises validation when opening offer after changing working schedule it raise validation error which isn't expected behaviour. task-5421228 Forward-Port-Of: odoo/enterprise#103889 Forward-Port-Of: odoo/enterprise#102488
This update fixes a bug where document favoriting wasn't working correctly, particularly when multiple documents were involved. The change ensures consistent behavior for toggling favorites, even with different user permissions, and adapts the process for batch operations. This improves the overall user experience for managing document favorites.
Original PR description
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but…
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but also the inverse method.
Note that this behavior is currently used in
documents/static/src/views/kanban/documents_kanban_renderer.js (useCommand, Toggle favorite that writes on the selection the opposite of is_favorited of the first record on the whole selection).
[IMP] documents{_spreadsheet}: adapt toggle favorite for batch of records
We update the document toggle_favorited method to work in batch with the following logic: if all documents share the same state (either all favorited or all not favorited), the method toggles their state; otherwise, it marks all items as favorites. Then using that updated method, we improve the toggle favorite method of the document service to support multiple documents and manage the reload.
We also apply the correction of the shortcut command for favorite introduced in odoo/enterprise#89928 but not propagated to master. That correction ensures we use the toggle_favorited method rather than writing on the is_favorited field, so that it also works in all situation (even if the user doesn't have write permission on the document).
Partially based on the forward port of odoo/enterprise#89928 (by adsh-odoo).
Task-5095066This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104240 Forward-Port-Of: odoo/enterprise#95174
This update fixes an issue preventing non-administrator users from updating GI CFDI sequences. Previously, the system required elevated privileges, limiting functionality. Now, sequence updates are available to all users, streamlining the process for generating CFDI documents.
Original PR description
In odoo/enterprise#102500, support was added for custom GI CFDI sequences at branch level. However, the sequence consumption fails for non-admin users due to missing write access on ir.sequence, so sudo() is required when updating number_next. Forward-Port-Of: odoo/enterprise#104242
This update corrects a calculation error in part-time contracts. Previously, the system incorrectly attempted to adjust percentages when a 4/5 or part-time offer was created, leading to inaccurate salary calculations. This fix ensures that offer percentages are automatically determined based on the specified part-time rate.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer Forward-Port-Of: odoo/enterprise#104294 Forward-Port-Of: odoo/enterprise#103936
This update resolves an issue related to the DmfA declaration in the Belgian payroll module. The change adapts the payroll calculations to align with recent refactoring efforts within the Odoo Enterprise platform. This ensures accurate and compliant payroll processing for Belgian employees.
Original PR description
Forward-Port-Of: odoo/enterprise#104175
This update hides the 'suggest next documents' tab within the signing feature from users who are not logged into Odoo. This change ensures that sensitive document suggestions are only visible to authorized personnel, enhancing security and data protection. It aligns with our security protocols for confidential document workflows.
Original PR description
This commit makes the suggestion tab of signing next documents hidden to public users, as they should be logged in to be able to see the next documents to be signed. task-5487349 Forward-Port-Of: odoo/enterprise#104287
Code cleanup and technical improvements
This pull request improves the consistency and readability of the Amazon and Shopee integration code by applying linting and formatting. Specifically, error handling has been refined to focus only on errors related to API requests, ensuring a cleaner and more maintainable codebase. This change doesn't impact functionality.
Original PR description
task-5436779 See also: - https://github.com/odoo/odoo/pull/243877
11 changes
New functionality added to Odoo
This update brings localized payslips for Bangladesh, incorporating new fields needed for accurate tax calculations. This ensures compliance with Bangladeshi tax regulations and provides a more accurate payroll experience for users in Bangladesh.
Original PR description
Implemented localization for payslips in Bangladesh, also added two new fields to the HrEmployee model that are needed for tax computation.
Resolved issues and error corrections
This update fixes an issue where preparation timers for courses in a restaurant order were incorrectly shared. Now, each course has its own dedicated preparation timer, ensuring accurate timing for each stage of the order. This enhances the restaurant's order fulfillment process and improves customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update resolves an issue where a specific configuration in the payroll rule parameters could trigger an error. The fix ensures that computed fields are correctly initialized, even when conditions related to future dates are not met. This prevents a traceback and maintains the stability of payroll calculations.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update resolves a technical issue where location IDs could incorrectly identify related locations, leading to test failures. Replacing `includes` with `indexOf` ensures accurate sublocation detection, improving the reliability of the stock barcode functionality. This fix addresses a build error and prevents potential disruptions in the system.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292)
A recent update to the 'account_no_followup' module caused a memory error during installation on older Odoo versions. This fix avoids a large data calculation that was overwhelming the system's memory. The change ensures smoother installations and prevents potential performance issues.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue. Forward-Port-Of: odoo/enterprise#102330
This update fixes a previous error that occurred when users deleted the 'Balance' line in the General Ledger Report. The fix prevents the report from crashing and ensures it functions correctly, even when balance information is removed. This improves the user experience and report reliability.
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#102113
This update corrects a visual inconsistency within the Odoo Enterprise VoIP module. Previously, the subtitle color in the 'Recent' tab differed from other tabs. This commit ensures all tab subtitles have the same color, improving the overall user experience and maintaining a consistent design.
Original PR description
Since commit [1], the subtitle color has been changed but not for the "Recent" tab, which creates inconsistencies. This commit ensures that the subtitle color is consistent across all tabs. [1]: https://github.com/odoo/enterprise/commit/568d29af1e1d792642f0dc288d57871fc7781f38 task-5485493 | Before | After | |--------|--------| | <img width="800" height="662" alt="Capture d’écran 2026-01-12 à 11 19 34" src="https://github.com/user-attachments/assets/8beb175a-27c8-4d73-899c-6fc3ab22c0e6" /> | <img width="800" height="657" alt="Capture d’écran 2026-01-12 à 11 19 49" src="https://github.com/user-attachments/assets/e2542822-6b05-4b15-b3e8-a4aa7c1b611c" /> | Forward-Port-Of: odoo/enterprise#103996
This update resolves a technical issue preventing users from creating and saving bank statements within the Bank Journal Transactions section. The problem stemmed from an error in how data was accessed, which caused a system crash. This fix ensures stable bank statement functionality.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#101232
This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report incorrectly showed duplicate lines and linked to the wrong journal entries. The fix ensures accurate grouping by analytic accounts, directing users to the correct journal entries.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#104082 Forward-Port-Of: odoo/enterprise#103169
This update ensures that historical survey answers retain their original date and datetime formatting, even if the question type is changed afterward. Previously, modifying a question type could cause formatting errors in exported spreadsheets. This change improves data consistency and reliability for survey results.
Original PR description
Current behavior before PR: - Survey spreadsheet export derived date and datetime formatting from the current question type. - Changing a question type after submission (date to datetime) could lead to incorrect formatting or export errors for existing answers. Desired behavior after PR is merged: - Spreadsheet export now derives value conversion and formatting from the stored answer type instead of the question definition. - Historical answers keep their original date or datetime format, even if the question type is modified later. Task: [5410758](https://www.odoo.com/odoo/project/2328/tasks/5410758)
This update resolves a technical issue that caused a traceback error when using pivot tables in the spreadsheet feature. The fix ensures pivot tables function correctly, even when certain data dimensions are missing, improving the reliability of reporting and analysis. This impacts users who rely on spreadsheet-based reporting.
Original PR description
Task: 5085724
15 changes
Resolved issues and error corrections
This update corrects a problem that prevented the migration of Odoo from version 16.0 to 18.0 for the Italian accounting module (l10n_it). The fix adds a necessary column to the database, resolving the migration failure. This ensures a smooth upgrade process for Italian businesses using Odoo.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
This update ensures that pressing the mobile back button closes the chat window, mirroring the functionality of the 'X' button. Previously, the back button caused unexpected navigation. This improves the mobile chat experience and prevents users from losing their place within conversations.
Original PR description
**Current behavior before PR:** - The back button on mobile does not close the open chat window. - Pressing it navigates away from the page instead of closing the chat window. - Only the "X" button can be used to exit a chat. **Desired behavior after PR is merged:** - Pressing the mobile back button will now behave the same as clicking the "X" button. - It will close the current chat window and prevents unwanted navigation in browser history. task-[4563827](https://www.odoo.com/odoo/project/1519/tasks/4563827) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with approved expenses are now correctly copied, improving the accuracy and completeness of financial records. This prevents data loss and provides a more reliable view of expense details.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#241044
This update ensures that the DDT number is correctly included in the delivery reports sent to customers. Previously, the number was missing because it was generated after the email was sent. This fix resolves a reporting issue, improving the accuracy and completeness of delivery confirmations for Italian businesses using the l10n_it_stock_ddt module.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update resolves an issue where pivot tables in the spreadsheet module weren't correctly calculating data. By adding a key to the pivot registry, the system now accurately re-evaluates pivot data, ensuring correct and reliable reporting. This improves the overall accuracy and usability of the spreadsheet feature.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update provides users with more detailed error messages when sending documents to HMRC. By including the specific error code and message from HMRC, users can quickly understand and resolve issues, reducing the need for support. This enhancement improves the user experience and streamlines the document submission process.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests.
This update fixes a bug where inviter notifications were sent to portal users when they connected for the first time, causing unnecessary alerts. Now, inviter notifications are only triggered for internal users, streamlining the process and improving the user experience. The notification message has also been updated for clarity.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited…
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users. For portal users, this resulted in unnecessary toast notifications and chat window pop-ups. **Current behavior before PR:** --------------------------------- - The inviter is notified when any invited user connects for the first time. - This includes portal users. - Unnecessary notifications and chat pop-ups are shown for portal user connections. **Desired behavior after PR is merged:** ----------------------------------------- - The inviter is notified **only when an internal user** connects for the first time. - Portal users no longer trigger first-connection notifications. - The notification message is updated to: “[Username] just connected for the first time. Wish them luck!” **Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where discoverable subfolders accessed via sharing links weren't initially displayed correctly. The fix sends a flag to refresh the document access when a new folder is loaded, ensuring subfolders are immediately visible to users. This improves the user experience when sharing 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
This update resolves a potential error that could occur in the accounting system when all possible distribution factors are zero. The change ensures the system handles this specific scenario correctly, preventing a traceback and maintaining accurate accounting calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none
This update fixes an issue where the quantity delivered on sale orders wasn't accurately updated after a partial refund with a 'Ship Later' option. The fix ensures that the delivered quantity reflects the actual items remaining after the refund is processed, improving order accuracy and reporting. This resolves a discrepancy in how the system tracks inventory following a partial refund.
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
This pull request enhances message access and search functionality within Odoo by ensuring consistency across read, search, and portal user experiences. Specifically, it addresses issues with document-level access checks, symmetric search results, and portal user domain application, ultimately improving data accuracy and usability.
Original PR description
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need…
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need write access to create a message (post) but on some models you can post when you can read. Calendar events message access depends on calendar privacy settings. This is controlled via '_get_mail_message_access'. However currently it is "globally called", for all documents. It should be done on a per-document basis, as each document could define different access check. Keep code somewhat optimized by doing access checks in batch for a given operation. Make _search and read symmetric. Reading documents should be allowed on search results, and search results should match what is available for reading. Portal users have some specific domains applied when accessing messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for 'website_message_ids' domain, mail controllers, ...). However there are still some cases where search and read are not coherent with portal users. This is not really annoying as most messages are accessed using sudo and correctly tailored domains via controllers but let us try to have a more correct code. Fix discuss support of post check capabilities * not taking into account '_get_mail_message_access' to check if user has right to post (generally used to indicate users can post on readonly records, but not limited to that) in 'readonly' computation in frontend and in controllers; * not adding the same check on Activities button as on Send message and Log note. We consider generally that rights should be aligned and UX should match that behavior; * not adding the same check on attachments buttons, currently limited to write access (or always accessible). This is a preliminary work for attachments, further fixes are probably incoming; Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 . Task-5138368 opw-4785878 Forward-Port-Of: odoo/odoo#233725
This update ensures that EDI identification details used during registration are consistently synchronized across systems, particularly for Peppol integrations. Previously, provided identification numbers could be outdated, leading to potential registration issues. This fix improves data accuracy and reliability for Peppol-related processes.
Original PR description
We introduced for Peppol the possibility to deduce an identification from another one therefore, the provided edi_identification at registration can sometimes not be the one that is actually used when registering to the AP. This commit adds ways to synchronize it to keep it consistent. See https://github.com/odoo/iap-apps/pull/1334 task-none
This update enhances the Point of Sale system by introducing a background queue for 'isUnsyncedPaid' orders. This prevents slowdowns and errors when many orders are being processed simultaneously, ensuring reliable and efficient order synchronization. The system now handles errors gracefully, retrying failed orders to maintain data accuracy.
Original PR description
Implement a background queue system to handle isUnsyncedPaid orders separately from regular order synchronization. This prevents issues when multiple pending orders are being synced simultaneously. Orders are now categorized into three types: - Orders from options.orders: sync normally with await - Non-isUnsyncedPaid pending orders: sync normally - isUnsyncedPaid orders: process sequentially through background queue The queue processing pauses during explicit sync operations and resumes automatically afterward. This prevents race conditions and ensures orders are synced reliably one-by-one. Error handling differentiates between error types: - RPCError: removes order from queue and shows user notification - ConnectionLostError: pauses queue and keeps order at front for retry - Timeout/other errors: moves order to end of queue for retry opw-5111772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where calendar events synced to Outlook would sometimes create duplicate events in both Odoo and Outlook due to network delays. The fix ensures that Odoo correctly links events created with Microsoft after a timeout, preventing these duplicates from occurring.
Original PR description
When creating an event in Odoo that syncs to Outlook, a timeout or network error during the response from Microsoft can leave the system in an inconsistent state, leading to duplicate events in both…
When creating an event in Odoo that syncs to Outlook, a timeout or network error during the response from Microsoft can leave the system in an inconsistent state, leading to duplicate events in both Odoo and Outlook during subsequent synchronizations.
### Steps to reproduce
1. Create a calendar event in Odoo with Outlook synchronization enabled.
2. Simulate a network timeout (currently set to `3 seconds`) after Microsoft processes the creation request but before Odoo receives the response (e.g., by mocking a timeout in `_microsoft_insert`).
3. Observe that the event exists in Outlook but the Odoo record lacks the `microsoft_id`.
4. Run the synchronization manually.
5. A duplicate event is created in Outlook (due to retry) and/or a duplicate event is created in Odoo (fetched from Outlook as "new").
### Root Cause
The synchronization logic in
`microsoft_calendar/models/microsoft_sync.py` relies on receiving a successful response from the Microsoft Graph API to link the Odoo record with the created Outlook event.
Specifically, in the `_microsoft_insert` method, the call to `microsoft_service.insert` sends the creation request. If Microsoft successfully processes this request and creates the event, but the network connection times out while waiting for the response, the subsequent line `self.write({'microsoft_id': event_id, ...})` is never executed.
At this point, the Odoo record remains with `microsoft_id=False` and `need_sync_m=True`, even though the event actually exists in Outlook.
During the next synchronization:
1. `_sync_odoo2microsoft` identifies the Odoo record as unsynced (`microsoft_id=False`) and sends a new insertion request, creating a second event in Outlook.
2. `_sync_microsoft2odoo` fetches the original event from Outlook. To match Outlook events back to Odoo records, the logic in `MicrosoftEvent._load_odoo_ids_from_db` searches for Odoo records having a matching `microsoft_id` or `ms_universal_event_id` (a global ID provided by Microsoft). Since the Odoo record was never updated with these IDs, the match fails. Odoo treats the incoming event as a new external item and creates a duplicate record in Odoo.
### Fix Rationale
To resolve this, we utilize the `transactionId` property of the Microsoft Event resource. The `transactionId` is an optional, client-provided string that Odoo can attach to an event during creation. This ID is stored by Microsoft and remains accessible in the event's properties, allowing the client to identify the event independently of the server-generated IDs.
1. We now generate a deterministic `transactionId` for each insertion using the format `<database.uuid>_<record.id>`. This ID is unique to the Odoo record and remains stable across synchronization retries.
2. This `transactionId` is included in the payload of the event creation request within the `_microsoft_values` method of the `calendar.event` and `calendar.recurrence` models.
3. The matching logic in `MicrosoftEvent._load_odoo_ids_from_db` is extended with a fallback mechanism. If an incoming Outlook event cannot be matched by its server-generated IDs, the code checks for a `transactionId`. If the `transactionId` matches the current database UUID and contains a valid Odoo record ID, Odoo identifies the record it originally intended to create and links them.
This ensures that if an insertion response was previously lost due to a timeout, Odoo can still find and link the existing Outlook event during the next synchronization instead of creating a duplicate.
opw-5031073Features or functions removed from Odoo
This change removes a reference to an unused test file within the l10n_sa_edi module. This cleanup improves the organization and efficiency of the Odoo codebase. It's a minor technical update that ensures the system remains tidy.
Original PR description
In this [commit], the file name `test_account_move` is removed from `__init__.py`, but the file itself is not deleted. This commit cleans up an unused file reference. [commit]: https://github.com/odoo/odoo/commit/06e21763130d8fcefe9bb62a8b6525fd660874b4#diff-fa673cbfe1fe7ca858fc60e30493a49cc060c245a9a5c9f266ad2e92c9594a8fL6 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
7 changes
Enhancements to existing features
This update ensures invoices display the correct tax labels based on the 'invoice_label' field, rather than the default 'name' field. This is crucial for accurate tax reporting and compliance with localized requirements, providing a more user-friendly and reliable tax display on invoices.
Original PR description
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate…
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate tax labels that may differ from the internal tax name. Technical details: - Added `is_invoice` context when calling `tax_ids.compute_all()` in `account.move.line._compute_all_tax()` method - Modified `account.tax.compute_all()` to check for `is_invoice` context and select appropriate field name (`invoice_label` for invoices, `name` for other documents) - The selected field name is used when building the tax values dictionary returned by `compute_all()` This change ensures that invoice tax lines display the correct label as defined in the tax's `invoice_label` field, which is particularly useful for localized tax reporting requirements where the invoice label may differ from the internal tax name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
A bug was found in the Dutch Profit & Loss report where Cost of Goods Sold and Cost of Sales codes were incorrectly linked. This resulted in inaccurate financial reporting. This update corrects the code mapping to ensure proper financial data is displayed.
Original PR description
**Steps to reproduce:** 1. Install l10n_nl_report. 2. Go to Accounting → Configuration → Accounting Reports. 3. Open Profit and loss report (tags). 4. Click on Cost of Goods Sold or Cost of Sales and check the related codes. **Issue:** In the Dutch Profit and Loss report, the codes assigned to the "Cost of Goods Sold" and "Cost of Sales" line items are swapped. Currently: - Cost of Goods Sold is linked to code: NL_SALE - Cost of Sales is linked to code: NL_COGS This results in incorrect mapping and misleading financial reporting. **Cause:** The codes were incorrectly applied, leading to reversed definitions between Cost of Goods Sold and Cost of Sales. See: https://www.investopedia.com/terms/c/cogs.asp Solution: Swap the code values so that: - NL_COGS → Cost of goods sold - NL_SALE → Cost of sales
This update fixes an issue where users couldn't manage their consent for online account synchronization. The change introduces a message to the account synchronization link, allowing users to control their data sharing preferences. The update also enhances the system's flexibility by using provider type to support various synchronization providers.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621
This update corrects a bug where loyalty points weren't accurately calculated when re-loading saved Point of Sale (PoS) orders. Previously, points weren't correctly applied after saving and reloading an order, leading to incorrect point totals. This fix ensures accurate point calculations for loyalty programs when orders are reloaded.
Original PR description
When an order was saved then reloaded in the PoS, the points awarded for a loyalty program were not computed correctly. Steps to reproduce: ------------------- * Create a loyalty program that gives one point for every € spent * Activate the trusted pos option in the PoS settings * Open a PoS session and create an order * Add 1 product A for a total of €10 * Set a partner * You should get 10 points * Save the order * Reload the saved order * Change the quantity of product A to 2 > Observation: You still have 10 points instead of 20 Why the fix: ------------ When saving the order, it is synced with the backedn and the comboLines are reloaded from the backend when reloading the order. However, it becomes an empty list and the line would be treated as a combo header. This backport a part of this commit : https://github.com/odoo/odoo/pull/220828 opw-5118716
This update fixes a discrepancy in how tax reports are tested within several Odoo localization modules (l10n_at, l10n_dk, etc.). The change ensures tests accurately reflect the 'invoice label' used for tax information, leading to more reliable report generation. This improves the accuracy of tax reports for our international customers.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236497
This update fixes an issue where returning a received subcontracted product didn't properly decrease the purchase order quantity. Now, customers can accurately process multiple return and re-receipt scenarios, ensuring correct quantity tracking for subcontracted products. The change addresses a technical update related to Odoo 18.0's exchange workflow.
Original PR description
Problem: If a customer ends up returning their subcontracted products and then creates a second return to receive the products again the received quantity on the purchase order line updates…
Problem: If a customer ends up returning their subcontracted products and then creates a second return to receive the products again the received quantity on the purchase order line updates correctly. However, if they return the second receipt, then it increases the received quantity on the purchase order line instead of decreasing it. Purpose: This will allow a customer to process a chain of returns for subcontracted products while keeping the received quantity correct. I have removed the check for origin_returned_move_id because of the return for an exchange workflow in Odoo 18.0. This field does not get set because the exchange moves should be independent of their origin moves. Steps to Reproduce on Runbot: 1. Create a purchase order for a subcontracted product. 2. Validate the receipt on the purchase order. 3. Return the receipt and validate it. 4. Create a return of the previous return and receive the products again. 5. Create a return of the return from the previous step and validate it. 6. Observe the received quantity on the purchase order line increased instead of decreasing after step 5. opw-4839366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request confirms the developer has signed a Contributor License Agreement (CLA) for Odoo. This ensures compliance with Odoo's open-source licensing and legal requirements. The change is a standard documentation update related to the CLA process.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr