Daily updates from Odoo
Thursday, February 5, 2026
178 changes
33 changes
Resolved issues and error corrections
A performance issue impacting the Odoo.com website forum search has been resolved. The fix prevents the search from incorrectly indexing forum post content, leading to faster and more reliable search results. This enhancement improves the user experience for forum visitors.
Original PR description
Improve the performance of the website forum search. Issue: There is a significant performance issue with a large number of forum posts impacting odoo.com. This is due to the use of the `<%` operator…
Improve the performance of the website forum search. Issue: There is a significant performance issue with a large number of forum posts impacting odoo.com. This is due to the use of the `<%` operator on the content field of forum posts. It occurs when using the javascript search which autocompletes results in a dropdown on the search bar. To deactivate the search on the `content` column, displayDescription needs to be set to false. but this was not possible due to the data attribute which contains text. setting it to 'false' was still truthy and therefore enabled the fuzzy search in the content column. Fix: - fix a js bug to properly cast the value to a boolean - this was done for other data attributes at the same time. - set the display_description value to false to disable search on the content field. This is aligned with the python post search settings defined in: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/website_forum/controllers/website_forum.py#L95 Forward-Port-Of: odoo/odoo#246581
This update resolves a bug where custom mixins added fields to `res.partner` records caused errors due to incorrect data synchronization. The fix ensures that changes made by mixins are consistently included during the `write()` process, regardless of the order mixins are applied, preventing data inconsistencies.
Original PR description
Description of the issue/feature this PR addresses: When `res.partner` is inherited together with a custom mixin that adds additional values to `vals` inside the `write()` method, the behavior…
Description of the issue/feature this PR addresses:
When `res.partner` is inherited together with a custom mixin that adds additional values to `vals` inside the `write()` method, the behavior depends on the inheritance order. If the mixin is inherited after `res.partner`, the values added by the mixin are not included in the data collected by `res.partner.write()` for later synchronization, which can lead to runtime errors.
Current behavior before PR:
If the inheritance order is:
```python
_inherit = ['res.partner', 'custom.mixin']
```
the custom mixin’s `write()` method is executed after `res.partner.write()`.
As a result, any values added by the mixin are missing from `pre_values_list`, which is built by `res.partner.write()` and later accessed by `_fields_sync()`, causing failures when those fields are expected to be present.
This issue does not occur when the inheritance order is:
```python
_inherit = ['custom.mixin', 'res.partner']
```
because the mixin modifies `vals` before `res.partner.write()` is executed.
Steps to reproduce:
1. Create a mixin model with a new field, then add this field into `vals` inside the `write()` method so it is included in the update flow.
```python
class CustomMixin(models.AbstractModel):
_name = "custom.mixin"
custom_field = fields.Char()
def write(self, vals):
vals['custom_field'] = "foo"
return super().write(vals)
```
2. Inherit the mixin in `res.partner`
```python
class ResPartner(models.Model):
_name = "res.partner"
_inherit = ["res.partner", "custom.mixin"]
```
3. Update a `res.partner` record, an error will be raised
```bash
Traceback (most recent call last):
...
File "/opt/odoo/code/projects/odoo/odoo/orm/fields.py", line 1845, in __set__
records.write({self.name: write_value})
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo/code/projects/odoo/odoo/addons/base/models/res_partner.py", line 907, in write
updated = {fname: fvalue for fname, fvalue in vals.items() if partner[fname] != pre_values[fname]}
~~~~~~~~~~^^^^^^^
KeyError: 'custom_field'
```
Desired behavior after PR is merged:
Values added to vals by a custom mixin during `write()` are consistently available to `res.partner` internal synchronization logic, regardless of the inheritance order.
`res.partner.write()` and `_fields_sync()` should behave correctly even when mixins extend vals and are inherited after `res.partner`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246927This update prevents users from selecting payment method lines associated with archived journals when managing contacts. Previously, users could inadvertently choose outdated payment methods, leading to configuration issues. Now, archiving a journal automatically removes it from the selectable options, simplifying the process and preventing data duplication.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245947
Forward-Port-Of: odoo/odoo#240369This update enhances the clarity of accounting entries related to company-account expense payments. By leveraging the 'payment_reference' field, the payment term line now displays user notes, providing better context and traceability for financial records. This aligns with standard invoice practices and improves overall accounting accuracy.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244392 Forward-Port-Of: odoo/odoo#241353
This update fixes a security vulnerability where scheduled actions could continue running even with archived or unauthorized users. Previously, any user could trigger a server action, regardless of their access rights. Now, actions will only run with valid, active users (excluding system accounts), improving security and preventing unintended actions.
Original PR description
Any user can be used to run a server action, even if archived or without corresponding access right. Steps: - Create a scheduled action running with an administrator (code: empty) - Archive the used administrator - Do the same steps with random user Actual result: - Action continue to run with an archived user - Action continue to run with a user without corresponding access right Expected result: - Action should not run on a archived user (except System) - Action can run if user has corresponding access right opw-5475805 Forward-Port-Of: odoo/odoo#244416
This update fixes an issue where multiple overtime rules were incorrectly adding undertime amounts, leading to inaccurate overtime calculations. The change ensures that only the largest undertime value is considered, providing a more accurate reflection of actual overtime hours. This improves the reliability of overtime reporting.
Original PR description
### Issue:
When having a ruleset with multiple rules, their undertime amounts are added.
### Steps to reproduce:
- Create an overtime ruleset with two rules:
- Based on quantity, worked hours on a Day differs from a specific duration of 8h
- Based on quantity, worked hours on a Day differs from a specific duration of 10h
- Assign this ruleset to an employee
- On a day with no attendance, create one for this employee from 1pm to 6pm
- The computed overtime hours is -8 hours
### Cause:
The undertimes from each rule are added. The first rule computes 3 hours of undertime (8 - 5), the second 5 hours (10 - 5), resulting in 8 hours of undertime.
### Solution:
Instead of adding them, we only keep the greatest undertime.
This ensures that the undertime amount is technically the opposite of the overtime amount.
We only take the undertime value into consideration, whatever the period type of the rule.
opw-5452854
Forward-Port-Of: odoo/odoo#244462This update fixes an issue where the Avco audit report was missing certain stock moves. Previously, the report incorrectly filtered out moves based on company settings. Now, the report accurately includes all relevant stock moves, ensuring more reliable cost reporting for products.
Original PR description
When looking at the Unit Cost History we should ignore moves for standard cost method. Before this fix, we also ignore moves for FIFO or AVCO when the property_cost_method of the product category is not NULL (because is set to a company Y), but it is not set to the current company X. After this fix, we check if the property_cost_method is set to the specific company so that we don't ignore them. OPW-5434503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244495
This update resolves an issue preventing duplex printing on the Windows IoT device. We've replaced Ghostscript with SumatraPDF, a simpler PDF viewer that natively supports duplex printing. This ensures users can now print PDFs double-sided, improving workflow efficiency.
Original PR description
When printing a PDF using the Windows IoT, first the PDF file is temporarily saved, and then it is printed using Ghostscript which handles parsing the PDF and saving it to the printer. Unfortunately, Ghostscript is unable to print using duplex (double-sided) no matter what settings are provided. To fix this, we replace Ghostscript with [SumatraPDF](https://github.com/sumatrapdfreader/sumatrapdf), which is an open source PDF viewer for Windows, but it is also capable of being used from the command line to print. We simply provide the duplex printing option in the command to SumatraPDF, and it works as expected. [1]: https://github.com/sumatrapdfreader/sumatrapdf task-5149706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242307
This update resolves a validation error that occurred when installing modules in companies with branches. The fix ensures the parent company's chart of accounts is loaded first, preventing the creation of duplicate accounts within the branch. This improves module installation stability and functionality.
Original PR description
Issue: Validation Error on installing some modules in companies with branches Step to reproduce: - Create a company in UK - Create a branch to this company - install l10n_uk - install l10n_uk_reports_csi Current behavior: - raise validation error Solution: In AccountChartTemplate, `ref()` function allow searching object from company and parents company. https://github.com/odoo/odoo/blob/468c25b924979f4614705fe43f909af13f83c6a3/addons/account/models/chart_template.py#L1262-L1266 In `_load_data`, it tries to load existing record before creating new account. Loading the parent company first prevent creating a second account in the branch which raise the error. opw-5443912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that prevented users from opening the cashbox when using the payment screen. The fix ensures the system correctly handles the 'Open Cashbox' click event, preventing a traceback error and ensuring the necessary context is available. This improves the reliability of the payment process.
Original PR description
In this commit: - Fixes a Traceback error when clicking "Open Cashbox" on the payment screen. - Ensures the correct context by using an arrow function. - Prevents `iface_cashdrawer` being undefined during the click event. Task:5890341
This update corrects a technical issue where API documentation wasn't accurately reflecting the types of list parameters in Odoo. The fix ensures that the documentation now correctly displays parameter types like 'list[int]' instead of just 'list', leading to more precise and reliable API documentation for developers.
Original PR description
In python 3.10; When the type of a method parameter is a container (eg: `list[T]`), `stringify_signature` was not getting the full type but only the origin of it (eg: `list` instead of `list[int]`). This commit fixes the issue by stringifiying the container types separately. runbot-237782 Forward-Port-Of: odoo/odoo#247149
Previously, removing or reordering images in the website gallery would lose all associated links. This fix ensures that image links are preserved when the gallery is updated, improving the user experience and preventing broken links. The change involved updating how image links are handled during gallery rebuilding.
Original PR description
Before this change, using the website editor with image galleries, removing or reordering an image caused all image links to be lost. This happened because the gallery was rebuilt using image nodes only, dropping anchor wrappers during the process. ### How to reproduce: * Open the website editor. * Add an Image Gallery block. * Add links to some of the images. * Remove or reorder an image. * All image links are lost. ### Solution: Pass image holders instead of raw images to setImages and handle the different gallery modes. opw-5422081 Forward-Port-Of: odoo/odoo#244417
This update fixes a minor issue where some onboarding tours weren't properly waiting for the portal chatter to load, leading to potential delays for users. The fix ensures tours wait for the chatter to be ready before proceeding, improving the overall user experience and preventing a warning related to DOM updates during selection. A minor typo in a file name was also corrected.
Original PR description
### Before commit Some tours did not wait for the portal chatter to load when needed: - `portal_chatter_bundle`: the `run` function creates a promise but the tour finishes before it resolves. - `fullscreen_slide_text_highlights`: `PortalChatterService` adds an element in the DOM while the selection is updated in the `selectText` tour step. This caused the following warning to show: ``` should not have any "characterData", "remove" or "add" mutations in current step when you update the selection ``` ### Fix Properly wait for `portalChatterReady` to resolve before proceeding with the rest of the tour steps. (Also fixed the typo in the filename `slide_portal_chatter_bundle.js`) runbot-229803 Forward-Port-Of: odoo/odoo#247203
This update resolves a problem where the Open Graph image URL in website configurations was incorrectly set to absolute URLs, causing errors when viewing pages on different domains. The fix ensures that the image URL is relative, preventing this issue and improving website SEO and compatibility with custom domains. This was initially addressed in 19.0 and further refined in this release.
Original PR description
In 17.0 up to master, website_meta_og_img for newly added cover image should be a relative URL instead of an absolute URL since 27th september 2025 commit 4c5d9861e389534f9ca684b9faa1ce6289df5639. In…
In 17.0 up to master, website_meta_og_img for newly added cover image should be a relative URL instead of an absolute URL since 27th september 2025 commit 4c5d9861e389534f9ca684b9faa1ce6289df5639. In combination with: - [1] python fix in 19.0: accept absolute URL in website_meta_og_img - [2] upgrade script in saas-19.1: removes absolute URL that existed in 19.0 when upgrading to saas-19.1 We wanted to removed the error that happened in 19.0 when configuring a cover image (in Optimize SEO) and also using a custom domain These fixes worked up to 19.0, but there is still a possible issue in saas-19.1: - open "Optimize SEO" wizard of a page - click on save without changing the image - set a domain on the website - go to the page with the cover image => result an absolute URL is saved and we get a traceback error when visiting on wrong domain. Cause: The 4c5d9861e389534f9ca684b9faa1ce6289df5639 was only getting relative URL when an image was selected. This didn't work if we open and saved the modal when there was no website_meta_og_img and the image was gotten from the META og:image element. In 19.0, since there was a python fix for existing errors [1] this case was hidden and didn't cause an issue. Fix: Forward-port cdffe8ab905068a3947ea62562c7209d216b2b8d in upper versions. A fix should also be done after to ensure we don't save absolute URL: for example if the image we save matches the og:image in DOM, don't save it. [1]: cdffe8ab905068a3947ea62562c7209d216b2b8d [2]: odoo/upgrade@5408746b110d660901645b9c7b9aa9cee7aaf235 opw-5867113 opw-5874045 opw-5874931 opw-5875254 opw-5884536 opw-5885941 opw-5887081 opw-5888627 opw-5889050 opw-5891942 opw-5897982 opw-5898621 opw-5898731 opw-5899722 opw-5900450 opw-5906008
This update resolves a technical issue where the user ID (UID) was incorrectly set during the MFA process. A recent code change inadvertently caused this, which was preventing proper MFA functionality. This fix ensures the UID remains correctly set to 'None' during MFA, improving system stability and security.
Original PR description
Before this fix the uid was set in the environment even when the MFA was not yet complete. The uid is set in finalize function and was accidentally set before due to a refactor of DLE. This was indeed a bug since the code expects the uid to be set to None. Task-5910537 Forward-Port-Of: odoo/odoo#247230
This update corrects a visual bug where highlights on RTL websites (like Arabic) were incorrectly positioned. The fix adjusts how the highlight element and its associated SVG are positioned, ensuring the highlight appears correctly regardless of the website's language direction. This improves the user experience for international visitors.
Original PR description
Scenario: - add a RTL language to website (eg. arabic) - go to the website and add a highlight to part of a line - switch to RTL language Result: the highlight is not at the correct X position. This…
Scenario:
- add a RTL language to website (eg. arabic)
- go to the website and add a highlight to part of a line
- switch to RTL language
Result: the highlight is not at the correct X position.
This commit fixes the issue for most browser by changing in RTL that:
- the SVG is positionned from the right so the SVG right matches
the boundary rect right
- mirroring the SVG so when the 1x1 pixel is scaled, it is scaled toward
the left and it matches the left boundary rect
This is not always working (mostly for safari) because the positionning
of position:absolute SVG inside highlighted position:relative SPAN is
behavior differently in RTL (an even behave differently in case of mixed
RTL / LTR strings in dir:rtl blocks).
This is reproduced in this code:
https://gist.github.com/nle-odoo/21fea59d338b55b3e2a337cf360ef878
So to fix that issue, after inserting a SVG element in RTL in DOM, we
correct the X position by the current error from what we intended.
opw-5049432
opw-5344412
opw-5867908
## PR NOTE:
### 1) For the part:
```diff
- const firstRect = highlightEl.getClientRects()[0];
+ const rtl = window.getComputedStyle(highlightEl).direction === "rtl";
+ let firstRect;
+ if (rtl) { // Take the first top right element instead of top left
+ firstRect = [...highlightEl.getClientRects()].sort((a, b) => a.top - b.top || (b.left + b.width) - (a.left + a.width))[0];
+ } else {
+ firstRect = highlightEl.getClientRects()[0];
+ }
+
...
- const spanOffsetX = firstRect.x - containerRect.x;
const spanOffsetY = firstRect.y - containerRect.y;
- svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
svg.style.top = `${(rects.y - containerRect.y - spanOffsetY) * scale}px`;
svg.style.bottom = `0px`;
- svg.style.right = `0px`;
+ if (rtl) { // Position from the right instead of left and mirror the SVG
+ const spanOffsetX = containerRect.x + containerRect.width - firstRect.x - firstRect.width;
+ svg.style.left = `0px`;
+ svg.style.right = `${(containerRect.x + containerRect.width - rects.x - rects.width - spanOffsetX) * scale}px`;
+ svg.style.transform = 'scale(-1, 1)';
+ } else {
+ const spanOffsetX = firstRect.x - containerRect.x;
+ svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
+ svg.style.right = `0px`;
+ }
```
I don't understand why the other SVG are positioned relative to the first one(but the original code did that and making it but with the logic of RTL instead of LTR seems to be the only way to make it work).
Note that in saas-18.3 the logic seemed to be a lot more simple, but there was a "display: inline-block;" on the highlight item which simplified the logic a lot (you can just have 100% width to match the item highlighted), but would make (LTR in RTL content, or RTL in LTR content) "`<highlight>hello</highlight> world`" appear in RTL as "`world <highlight>hello</highlight>`".
Forward-Port-Of: odoo/odoo#226359This update addresses discrepancies in invoice totals, particularly for Peppol transactions, caused by rounding of product prices. The change ensures that invoice totals more closely match original documents by removing fixed decimal precision from 'Product Price' fields. This improves data accuracy and compliance.
Original PR description
Imported invoices can show different totals than what the original document show. This especially an issue for Peppol. Because `price_unit` is rounded, by computing the total of a line with `quantity * price_unit`, it may not be possible to obtain the same total as the one from the original document. To face this issue, the float fields related to "Product Price" don't have a decimal precision set anymore. To keep the UI clean, the precision set on "Product Price" is now interpreted as a "minimal precision". So if it set to 3, we'll see at least 3 digits. If there's more, all the digits are shown. As so: `4.0` -> `'4.000'` `4.23` -> `'4.230'` `4.235` -> `'4.235'` `4.2358` -> `'4.23458'` task-4895014 Forward-Port-Of: odoo/odoo#247064 Forward-Port-Of: odoo/odoo#243987
This update fixes an issue where the HTML editor toolbar would unexpectedly close and not reopen after a link popover was closed. The fix ensures the toolbar correctly reopens when focus returns to the editor, improving the user experience when working with rich text content. This resolves a previous bug that caused cursor issues.
Original PR description
#### Description of the issue this PR addresses: `focusEditable`: - The previous focusEditable logic failed in the website because `this.editable` is `contenteditable="false"` and there is often a…
#### Description of the issue this PR addresses: `focusEditable`: - The previous focusEditable logic failed in the website because `this.editable` is `contenteditable="false"` and there is often a non-editable ancestor near the selection. - As a result, the editor did not receive focus, and focusing the wrong element caused the cursor to collapse or move unexpectedly. `Toolbar not remains open`: - The toolbar closed when focus leaves iframe but not getting reopen when focus returns. ### Desired behavior after PR is merged: - The focusEditable focuses the nearest element with `contenteditable="true"` and then restores the cursor when the selection lies inside a non-editable region. - We dispatch `selection_enter_handlers` when focus returns to the iframe document. - This reopens the toolbar when the selection is not collapsed. task-5261404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244970 Forward-Port-Of: odoo/odoo#237953
This update resolves an issue where resizing an image within a link would unexpectedly make it fill the entire link width. The fix ensures that image resizing within links maintains the intended proportions, providing a more consistent and user-friendly experience. This improves the visual quality of linked images.
Original PR description
Problem: Resizing an image inside a link causes it to snap to 100% width on mouseup. Cause: The percentage calculation uses the parent element's width as reference. When the parent is inline (like `<a>`) or has fit-content width, its width equals the image width, resulting in 100% every time. Solution: Find the first ancestor with content width larger than the image and use it as reference for the percentage calculation. Steps to reproduce: - Add an image inside a link - Resize the image - Observe the image snaps to 100% width on release opw-xxxx --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247229
This update fixes an issue where components added to manufacturing orders through the product catalog weren't correctly transferred to the pre-production warehouse. The fix adds a warehouse ID to the moves created by the catalog, ensuring proper stock movement and fulfilling multi-step manufacturing requirements. This improves the accuracy of inventory tracking.
Original PR description
Issue
-----
In multi step manufacturing, components added to MO through the catalog don't get transfered to the pre-prod location.
Steps to reproduce
-----
- 2 step manufacturing
- Create 2 products
- Create a MO for the first product
- Open the product catalog
- Add some qty of the second product
- Go back to the MO & confirm it
> No procurement transfer for the second product from stock to pre-prod
Cause
-----
The move created by the catalog has no `warehouse_id` so in `adjust_procure_method` we don't find any rule which means it gets set to MTS
https://github.com/odoo/odoo/blob/6ecd271ff34313d900a0ad14b1c20679808ba9b8/addons/stock/models/stock_move.py#L2366-L2368
-----
Ticket:
opw-5221418
Forward-Port-Of: odoo/odoo#243036
Forward-Port-Of: odoo/odoo#239265This update fixes an issue where combo items weren't always printed correctly on preparation printers. Now, the system considers both the combo's and individual item's categories, ensuring all items in a combo are printed as intended. This improves the accuracy of order fulfillment for combo sales.
Original PR description
Previously, combo choice items with categories assigned to a preparation printer were skipped when their category differed from the combo parent product’s category. This commit ensures that both the combo parent product’s category and the item product’s category are taken into account to correctly print items to the preparation printer. Task: 5902389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247028
This update enhances the reliability of syncing user data with Google Calendar. Previously, the sync process could time out with a large number of users due to a single, lengthy operation. Now, multiple sync cron jobs are used, targeting different user groups, to distribute the workload and prevent timeouts.
Original PR description
Before this commit, the sync cron of google could only work by performing a search on the users and starting the sync. But the cron could timeout with a large amount of users. As users were fetched in the same order, some users could never be synced. This change allows to create several cron with different type of user in self (by company, department, etc) to allow distribute the sync effort over several crons. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210286
This update resolves an issue where searching large datasets, particularly with many2many fields, could cause performance problems and errors due to excessive filtering. By adding a context to control grouping, the system now avoids unnecessary searches, improving stability and speed for users. This primarily impacts the Mail and Attachment modules.
Original PR description
Add a context to know if we are grouppnig. This allows us to stop `_search` methods which need to search and filter manually all records. For example, when asking if a field is groupable, `_description_groupable` will run a dummy search for many2many fields, for a normal user searching on ir.attachment, it would search for all attachments and try to filter them in memory leading to OOM error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up the process of importing products into Odoo, particularly when dealing with a large number of stock locations. The change optimizes a slow database query, resulting in a much faster import time. This improves overall system performance and reduces import delays.
Original PR description
Problem: When importing products in Inventory, _compute_quantities_dict fetches data from all internal stock.location. For databases with many internal locations (e.g., 37K), the query using LIKE ANY with a large array of parent paths is very slow. Solution: - Replace LIKE ANY(%s) pattern matching with a semi-join subquery using EXISTS, allowing the query to terminate on the first match. - Add an index on (parent_path, id) to convert sequential scans into index-only scans. Benchmark: |Number of rows| Before | After | |--------------|--------|-------| |37K | 4.xxs | 1.xxs | Simplied plan (a few hundred records instead of 37K) |Before|After| |-|-| |https://explain.dalibo.com/plan/8gb1257c6712age5|https://explain.dalibo.com/plan/5ef9c3g7aab3dfag| Related ticket: opw-5500169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245939
This update corrects a bug causing dynamic website snippets to flicker in and out of view. The issue stemmed from a mismanaged CSS class, which has now been restored to its original state: snippets should be initially hidden and then displayed based on content. This ensures a consistent and reliable user experience for website visitors.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523 Forward-Port-Of: odoo/odoo#240807 Forward-Port-Of: odoo/odoo#238305
This update resolves minor visual inconsistencies in the new image gallery template. Specifically, it corrects issues with missing styling and undefined class names, ensuring a more polished and reliable display of images for users. This improves the overall user experience.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#245357 Forward-Port-Of: odoo/odoo#241785
This update corrects a technical issue where inconsistent environments were causing errors in automated mail sending processes within Odoo. By standardizing the environment context, the system now reliably avoids these concurrent update errors, ensuring stable operation.
Original PR description
### [FIX] base: ensure an uniform environment between action variables The aim of this commit is to make the environment and context uniform across the variables that can be accessed in an action. Context: The mail override of `<ir.actions.server>._get_eval_context` that modifies the `env` wasn't reflected on the other variables which lead to a difference of context. Before this commit: This difference resulted in a concurrent update error caused by a direct mail send in method like `_cron_try_auto_reconcile_statement_lines`. After this commit: The environment and its context are uniform as expected and cron don't trigger a mail send directly, removing the concurrent error issue. task-id: None The issue was brought in the internal channel, temporarily fixed by adding the context in the server action and seen again in odoo.com logs through another cron. Forward-Port-Of: odoo/odoo#247255
This update fixes an issue where recurring prices on ecommerce product pages were displayed with incorrect grammar, specifically using singular forms for billing periods longer than one. The change ensures all recurring price labels are pluralized, providing a more professional and user-friendly experience for customers.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937 Forward-Port-Of: odoo/enterprise#105127
This update fixes an issue where annual returns incorrectly used a fiscal year filter when a company's fiscal year differed from the calendar year. Now, annual returns always follow the company's fiscal year, ensuring accurate reporting and eliminating confusion for users. This improves the reliability of financial data presented in reports.
Original PR description
When a company fiscal year differs from the civil year, the annual return incorrectly falls back to the report’s FY-aligned year filter. The return should always follow the civil year, so the fallback is skipped and the return period filter is shown instead. task-5511074 Forward-Port-Of: odoo/enterprise#104726
This update resolves an issue preventing the legal validation of annual VAT reports for Luxembourg. The PR adds missing required fields to the XML export, ensuring compliance with tax regulations. This corrects a previous validation error related to specific data fields.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update corrects a bug where subscriptions with zero-sum quantities resulted in invoices being set to the subscription start date instead of the correct invoice period. The fix ensures accurate invoice date calculations for subscriptions with mixed positive and negative quantities, preventing incorrect billing.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#106364 Forward-Port-Of: odoo/enterprise#103705
This update resolves an issue where the printer selection wizard could generate errors if it encountered printers that were no longer active in the system. The change filters out these inactive printers, ensuring the wizard functions smoothly and avoids potential disruptions. This improves the user experience and data integrity.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device. Forward-Port-Of: odoo/enterprise#106268
This update ensures that freight costs are now accurately included in the customs documents generated for international sales. Previously, these costs were missing, leading to potential discrepancies in customs declarations. This change aligns with SendCloud API specifications and improves the accuracy of international shipping documentation.
Original PR description
Issue ----- For international deliveries, the customs document does not include the freight costs. Steps to reproduce ----- - Create an international sale (eg BE -> US) - Validate delivery - Open the commercial invoice > Freight costs is set to 0 Change ----- The `freight_costs` should be included in the `customs_information` field of the request (along with all customs-related data, as other fields have been deprecated) https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/operations/create-a-parcel#:~:text=object%2E-,customs%5Finformation ----- Ticket: opw-5486742 Forward-Port-Of: odoo/enterprise#106387 Forward-Port-Of: odoo/enterprise#105543
1 change
Resolved issues and error corrections
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows a partner to be both a customer and supplier, resolving a discrepancy in balance classification and ensuring accurate reporting.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#105893 Forward-Port-Of: odoo/enterprise#100749
18 changes
Resolved issues and error corrections
This update prevents users from selecting payment method lines associated with archived journals when managing contacts. Previously, users could accidentally configure outdated payment methods. Now, archiving a journal automatically removes it from the selectable options, simplifying the process and preventing configuration issues when a journal is reactivated.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245947
Forward-Port-Of: odoo/odoo#240369This update enhances the clarity of expense bills by automatically displaying notes entered in the payment reference field on the payment term line. Previously, these notes were missing, but this change ensures consistent and informative accounting entries, improving traceability.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244392 Forward-Port-Of: odoo/odoo#241353
This update fixes an issue where the toolbar remained visible on mobile devices when the side menu or a popover was open. Now, the toolbar automatically hides when these elements are displayed, providing a cleaner and more user-friendly mobile experience. This ensures a better workflow for users creating and editing notes on their mobile devices.
Original PR description
In mobile, when the side menu or a popover is opened, the toolbar remains displayed above the keyboard. This commit hides the mobile toolbar while such elements are opened. Steps to reproduce: - In mobile, go to a "To do" note - Put cursor inside text to display the toolbar - Open the hamburger menu => The toolbar remained displayed on top of the side menu - Open the gear menu => The toolbar remained displayed while the menu was opened task-5222582 Forward-Port-Of: odoo/odoo#241611
This update resolves a discrepancy in how the 'Line Extension Amount' is calculated within the account_edi_ubl_cii module. The change ensures accurate untaxed and total amounts in invoices, particularly when dealing with tax rounding across multiple lines. This improves invoice accuracy and compliance with tax regulations.
Original PR description
…-10] According to [BR-CO-10], LineExtensionAmount should be: <quantity> * <price_unit_wo_tax> + charges - allowances It was implemented as: <quantity> * <price_unit_wo_tax> + charges - allowances + <delta_total_excluded> <delta_total_excluded> is needed because it's the additional delta distributed by the global rounding of taxes accross the lines. If you don't add it, you will change the untaxed and total amount of your document. Instead, this commit adds 2 new values in the base_lines's tax_details: gross_total_excluded & discount_amount being the rounded versions of raw_gross_total_excluded & raw_discount but taking care of maintaining a global consistency regarding the global rounding. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246382
This update resolves a bug that caused invoice generation to fail when handling multiple tax lines, specifically during Peppol integration. The fix ensures accurate tax calculations by grouping tax lines before aggregation, preventing a division-by-zero error. This ensures invoices are correctly generated and sent to Peppol.
Original PR description
Steps: - Belgian localisation - Activate peppol - Have two fixed sales taxes (T1 3.5 and T2 4.5) - Have 4 product: - P1: Any sale price, taxes 21% and T1 - P2: Any sale price, taxes 21% and T2 - P3: sale price 0, taxes 0% and T1 - Create an invoice, with following invoice lines: - P1, quantity 2 - P2, quantity 2 - P3, quantity -4 - Confirm and send it to peppol -> Traceback (ZeroDivisionError) The reason is that we try to extract emptying taxes like "Vidanges" and aggregate them into new base lines, but we treat all these taxes as they are the same but they are not always the same. Therefore we aggregate both price unit and quantity and we try to divide the aggregated price by the aggregated quantity. In our case we end up with a price unit of 2 (9 + 7 - 14) and a quantity of 0 (2 + 2 + -4) which leads to a zero division error. The fix adds a grouping function in order to group the extra lines by taxes before aggregating them. opw-5384928 Forward-Port-Of: odoo/odoo#244314
This update fixes an issue where vendor bill labels on payable lines were empty when a payment reference wasn't provided. Now, the payable line automatically displays the bill reference, and updating the payment reference correctly updates the label. This ensures better clarity and accuracy in vendor billing information.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864 Forward-Port-Of: odoo/odoo#247191 Forward-Port-Of: odoo/odoo#221491
This update fixes an issue where tax amounts were incorrectly reported as discounts in the MyInvois XML invoices when taxes are configured as 'Included in Price'. The fix ensures that tax amounts are handled correctly, aligning with Peppol Malaysia e-invoice specifications and preventing inaccurate reporting of discounts. This ensures compliance with invoicing regulations.
Original PR description
The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the…
The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.
This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
discount_amount = price_unit * qty - total_excluded
= tax_included - tax_excluded
= TAX AMOUNT (not a discount!)
Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount
refs:
The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:
https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges
https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)
Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount
The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876
Ticket [link](https://www.odoo.com/odoo/project.task/5476526)
opw-5476526
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246490
Forward-Port-Of: odoo/odoo#245535This update allows users to reset Vendor Bills issued by ANAF (the Romanian tax authority) to a draft state, even if they are currently in an ‘EDI’ status. This change is necessary due to a recent update merging the ‘efactura’ module into the broader ‘l10n_ro_edi’ module, ensuring compliance with new regulations. It improves the flexibility of e-invoice management.
Original PR description
Adjusting the visibility check for "Reset to draft" button to allow Vendor Bills received from ANAF to be reset even when they have a EDI state. Will require to be shifted to `l10n_ro_edi` in 18.0+ as the efactura module is merged into it. task-5892651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247083 Forward-Port-Of: odoo/odoo#246697
This update fixes an issue where the HTML editor would incorrectly retain selections of tables and separators after the user clicked outside the editor. Now, when you click outside the editor, all selections – including text, tables, and separators – are properly deselected, providing a more consistent and user-friendly experience.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In Todo, Type some text. - Insert a table and a separator. - Select text along with table and separator. - Click outside the editor. The text is deselected but table and separator are still selected. **Desired behavior after PR is merged:** Custom selection such as table and separator is deselected along with browser selection when clicking outside the editor. task-5479981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing sales users from creating orders with products that have custom value attributes. The fix corrects a previous access restriction, ensuring sale users can properly add and utilize these attributes when creating sales orders. This expands the functionality of the sales module and improves the user experience for sales teams.
Original PR description
### Issue: Due to this issue, sale group cannot create a sale order with a product with custom value attribute. #### Steps to reproduce: 1- Create a product using admin with a custom value attribute. 2- Using demo user with sale access group, create a so. 3- Add the created product, and fill the custom value. The sale order cannot be saved due to access error. ### Cause: This is due to #197286. However that shouldn't have been applied to `product.attribute.custom` as that shouldn't be only accessed by people who can manage product like the rest of deleted accesses, but also it's needed by sale groups creating SOs. opw-5498719
This update fixes an issue where network interruptions during check-in/out could lead to duplicate attendance records and incorrect data. The fix introduces a timeout for geolocation requests and prevents multiple clicks, ensuring accurate attendance tracking even with unreliable network connections.
Original PR description
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend…
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend not updating, allowing multiple clicks and creating duplicate attendance entries - Incorrect check-in/check-out data __Steps to reproduce:__ 1. check in while online and server reachable 2. disconnect network or make server unreachable 3. check out Currently, getCurrentPosition would hang indefinitely. till the network is restored. then it will trigger the rpc call much later than the action time. in the meantime, the user could click multiple times, creating multiple attendance records. With this fix, getCurrentPosition will timeout after 10 seconds, then it will proceed without position. and if the server is unreachable, it will show an error notification without allowing multiple clicks. __FIX__ - Adds a timeout to getCurrentPosition - Uses a `_attendanceInProgress` flag to prevent multiple clicks - Ensures only the first callback (success or error) triggers the RPC opw-5414044 Forward-Port-Of: odoo/odoo#247140 Forward-Port-Of: odoo/odoo#244477
This update fixes a bug where the Tax ID (VAT) was not correctly displayed in document layouts like invoices and previews. The issue stemmed from a missing piece of code in the document template. Now, the Tax ID value is accurately reflected in the generated documents, ensuring accurate reporting and compliance.
Original PR description
Steps to reproduce 1. Install `account`. 2. Go to Settings → Configure Document Layout. 3. Enter a value in the Tax ID field. 4. Generate a document (invoice / preview document). Issue Unlike other fields in the document layout, the `Tax ID` value is not updated and does not appear in the document preview. Cause The VAT (Tax ID) rendering logic was missing from the document layout template XML. Solution Add proper logic to display the Tax ID using the company VAT Before: <img width="1089" height="750" alt="image" src="https://github.com/user-attachments/assets/8d27808f-d605-447c-807a-d5f3450eef36" /> After: <img width="1080" height="722" alt="image" src="https://github.com/user-attachments/assets/0af04d77-a318-4e39-9a4b-0911f2446e60" /> opw-5373374 Forward-Port-Of: odoo/odoo#240234
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox, impacting data reporting for Swedish point-of-sale systems. A secondary change restricts blackbox device selection within the POS configuration, enhancing security and data accuracy. This ensures reliable blackbox integration for financial reporting.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update fixes an issue where Odoo didn't properly account for credit notes during bank reconciliation. Now, when reconciling a bank transaction with a partially paid invoice and a credit note, the system correctly uses the remaining balance ($800) instead of the full invoice amount ($1000). This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663
This update resolves an issue preventing the legal validation of annual VAT reports for the LU region. The fix adds missing required fields to the XML export, ensuring compliance with Luxembourg tax regulations. This ensures accurate reporting and avoids potential validation errors.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and improving compatibility with financial institutions. This ensures seamless payment processing for SEPA transactions.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#105792 Forward-Port-Of: odoo/enterprise#105518
This update fixes an issue where WhatsApp messages to blacklisted numbers weren't being blocked correctly when the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers, regardless of the recipient's location, are properly blocked, improving communication security and preventing unwanted messages.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update fixes an issue where the quantity of components in a manufacturing order wasn't correctly updated after exiting the barcode MRP operation. Specifically, the system incorrectly displayed quantities after editing a component's quantity. The fix ensures that move quantities are accurately reflected, preventing discrepancies in inventory tracking.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
5 changes
Resolved issues and error corrections
This update resolves a failing test case related to Indian GST reports. A recent community fix changed how payable lines are labeled, now including the bill reference. The test cases have been updated to reflect this new labeling format, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#91535
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with the UrbanPiper platform.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#105861
This update resolves a bug in the POS Restaurant Preparation Display module where incorrect order quantities were sometimes sent to the kitchen. A small delay was added to ensure the quantity is updated before submitting the order, preventing test failures and ensuring accurate order transmission.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We add a small delay after using the numpad to ensure the quantity is updated before sending the order. Forward-Port-Of: odoo/enterprise#106187
This update resolves a bug where the POS ID wasn't correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, and a secondary change restricts blackbox device selection to the Fiscal Data Module in POS configuration, improving data security and consistency.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update resolves an issue preventing the legal validation of the annual VAT report for Luxembourg. It adds missing required fields to the XML export, ensuring compliance with tax regulations. This fix addresses a technical problem related to data validation within the LU reporting module.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
19 changes
Resolved issues and error corrections
This update fixes an issue where the softphone couldn't be closed using the same key that opened it. The change adds the same hotkey attribute to the close button, restoring the expected user experience. This ensures users can consistently close the softphone.
Original PR description
Since [1] the softphone cannot be closed with the same hotkey that opens it. This commit restores this behavior by adding the same hotkey attribute to its close button. [1]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be
This update adjusts the layout of the bank journal dashboard to accommodate the Connect Bank button, ensuring it's always visible. A previous, unnecessary code block has been removed to streamline the process. This improves the user experience by providing consistent access to the Connect Bank feature.
Original PR description
[IMP] account_online_synchronization: Remove useless t-if/t-elif This commit removes an useless t-if/t-elif introduces by this commit [[1]]. It seems this is useless as we have the same code inside the t-if or the t-elif. Only the conditions are different. no task id [1]: https://github.com/odoo/enterprise/commit/5c879c9097a2f3ebaf7b7b751a95de8d8f95527a [IMP] account_online_synchronization: Wrapping connect bank in dashboard The aim of this commit is making sure we are wrapping the Connect Bank button in the bank journal dashboard when we don't have enough place for it. no task id Before: <img width="402" height="329" alt="connect bank before" src="https://github.com/user-attachments/assets/110e417c-72b1-4294-a7fa-abab865658b5" /> After: <img width="385" height="325" alt="connect bank after" src="https://github.com/user-attachments/assets/6222059a-d83a-4e98-a5db-e288369800b8" />
This update corrects a bug preventing sales order items within subcategories from being included in commission reports. The fix ensures that all sales, regardless of product category hierarchy, contribute to salesperson achievements. This improves the accuracy of commission calculations and reporting.
Original PR description
### Issue: Due to this issue, only products which are inside `plan_achievement.product_categ_id` itself are included in achievements, and products which are in subcategory are not considered. #### Steps to reproduce - Using demo data: 1- Create a commission plan and add Mitchell admin as a Salesperson. 2- In the plan, create a new achievement. Set category to saleable. 3- Create a a SO with Large Desk. confirm and invoice it. 4- Navigate back to to the created commission plan. 5- Open commissions from smart button. 6- The created SO is not included is not considered. Expected: The created SO should be included in commissions. ### Cause and Fix: This limitation is due to not taking category.parent_id into consideration. This can be fixed by checking if plan category parent_path is a prefix of product category parent_path. opw-5461732
This update resolves potential tour instability caused by synchronous assertions that failed when triggers weren't immediately available in the browser. By switching to asynchronous assertions, the tours now run more reliably and consistently across different environments. This improves the user experience and reduces unexpected tour interruptions.
Original PR description
How tours works ? ================= For each animationFrame, engine searchs the trigger in the DOM until it has been found, then the action (run) is direclty launched. Why it could be not work properly ? =================================== Most of time, assertions done in `run` are synchronous. And if the trigger was too generic or clearly present in the DOM (like body, .o_content,...) or was simply the trigger element is already in DOM, then the synchronous assertions can failed... because elements are not present in DOM yet. Then, either the trigger of this step must be more precise, either you use trigger and HOOT selector to make assertions. This can cause undeterministic errors. What we do ? ============ With this commit, we replace synchronous assertions in `run` step function by asynchronous assertions in the `trigger`.
This update enhances the user experience for managing sign requests within Odoo Enterprise. Key changes include a simplified list view, improved template naming logic, and a modernized 'Itsme' authentication dialog. These improvements streamline the signing process and provide a more intuitive interface for users.
Original PR description
- the user now can uncheck 'Sent By' column by in list view - Update template name logic: * Keep custom name if set * Automatically update based on first uploaded document otherwise - Localize signing date in kanban view - Show 'Download' as dropdown only if more than one document - Add 'Details' button to open form view - Improve itsme auth dialog ui task: 5429970
This update corrects a technical issue within the Odoo Enterprise payroll accounting module. The module was incorrectly referencing a dependency that caused test failures. By removing the outdated dependency, the module now functions correctly and ensures consistent payroll processing.
Original PR description
hr_payroll_account_iso20022 did not depend on hr_payroll_account but only on hr_payroll and account_iso20022. This was causing some errors in tests that were expecting hr_payroll_account to be installed. Runbot Error: 237797 Forward-Port-Of: odoo/enterprise#106165
This update fixes an issue where subscription invoices were being generated prematurely when a note or section was added to the subscription. The fix ensures that invoice dates align with the expected end-of-period billing, regardless of whether a note is present. This improves the accuracy of subscription billing and prevents unexpected invoice timing.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update resolves an issue preventing users from viewing Lazada order package status within Odoo. Previously, access was restricted to 'Administrator' sales users. The fix grants read access to the necessary `lazada.order.item` model for both sales and inventory users, ensuring accurate package tracking on Lazada.
Original PR description
Versions -------- - 19.0+ Steps ----- Two issues: 1. Create a new user with `Sales "User: Own Documents Only"` rights, and `Inventory "User"`. 2. Try to access any picking or sale order. Issue ----- ``` Failed to read field stock.move.lazada_order_item_ids You are not allowed to access 'Lazada Order Item' (lazada.order.item) records. This operation is allowed for the following groups: - Sales/Administrator Contact your administrator to request access if necessary. ``` Cause ----- Both the picking form view and the sale order form view need access to the `lazada.order.item` model to display the pacakge status on Lazada. However, all Lazada specific models are only accessible with Sales "Administrator" rights. Solution -------- Add read access to `lazada.order.item` for stock and sales users. Forward-Port-Of: odoo/enterprise#105889
This update resolves an issue where lengthy bank reconciliation names were being truncated and displayed as a long list of commas. The fix moves a key component, improving the clarity and readability of bank reconciliation statements for users. This ensures accurate and complete information is presented.
Original PR description
When we have a lot of reconciled names, it can happens that you just have a long list of comma. It's because the text truncate was misplaced. This commit will fix this by moving the text truncate no task id Forward-Port-Of: odoo/enterprise#106242 Forward-Port-Of: odoo/enterprise#105674
This update resolves an issue where a reordering rule would incorrectly attempt to update a manufacturing order that had been locked due to a quality check. The fix ensures that the system correctly handles locked MOs, preventing errors and maintaining data integrity. This improvement improves the reliability of the MRP process.
Original PR description
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an…
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by quantity - Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point) - Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1) - Click on Order - Open the created MO and the Shop Floor (Remove the filters to see the WO) - Complete the Quality Point - Modify the Reordering Rule (Min/Max: 2) - Click on Order - the error should be raised ### Cause: The MO to update is retrieved here: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153 In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created opw-5012588 Forward-Port-Of: odoo/enterprise#104158 Forward-Port-Of: odoo/enterprise#101313
This update fixes an issue where recurring prices on ecommerce product pages were displayed with incorrect grammar, specifically using singular forms for billing periods longer than one. The change ensures prices are presented in a user-friendly and grammatically correct manner, enhancing the customer experience.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937 Forward-Port-Of: odoo/enterprise#105127
This update resolves a bug that caused incorrect schedule calculations when using planning-based work entries, particularly with material-type resources. The fix restricts schedule computations to only include planning slots for the employee creating the attendance, ensuring accurate time tracking and preventing scheduling conflicts.
Original PR description
Steps to reproduce: - Set the work entry source to planning for an employee. - Create an attendance for that employee. Issue: - Errors occurred when planning slots linked to material-type resources were included in schedule computation. Fix: - Restrict planning slots used for schedule computation to records whose employee_id belongs to self.ids. task-5476771 Forward-Port-Of: odoo/enterprise#103951
This update corrects an issue where project forms, accessed through SmartButtons, were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing editing, ensuring users can now fully interact with project forms. The reason for this initial setting remains unclear.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#105225This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on a default setting related to partner countries. The fix ensures consistent pricelist ordering, resolving a potential issue with subscription pricing and improving test reliability.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736 Forward-Port-Of: odoo/enterprise#105606 Forward-Port-Of: odoo/enterprise#103116
This update fixes an issue where malformed PDFs caused errors during the signature process. The system now attempts a more lenient PDF parsing method when the initial attempt fails, ensuring that more PDFs can be processed correctly. This improves the reliability of the signature workflow.
Original PR description
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859 Forward-Port-Of: odoo/enterprise#106276
This update resolves a technical issue that prevented printing from IoT printers within the Point of Sale system. The fix addressed an 'undefined' error, ensuring reliable printing functionality for users. This improvement enhances the overall POS experience.
Original PR description
This PR fixed "error: undefined" when printing via websocket with iot printers in point of sale task-5496890 Forward-Port-Of: odoo/enterprise#106284
This update fixes a critical issue where payslip calculations continued even when errors were detected. Now, the system correctly raises an error, providing clear guidance on resolving problems like missing contracts. This ensures accurate payroll processing and prevents incorrect calculations.
Original PR description
Bug: When there is an issue on a payslip with an error level, and we try to compute the sheet, the sheet is computed. Instead of computing, it should raise and the message should specify what errors need to be resolved first. Cause: When computing the sheet, we were calling the self._get_error_message() without using the result, which is a string. Fix: Actually raise a ValidationError and use the result of self._get_error_message() for the error message. Introducing the raise brought other problems because some code supposed to fail was running seamlessly fine. But now, the raise is called and those needed to be solved as well. The issue raised multiple times is the "No contract in the payslip period". Task: 5153497 Forward-Port-Of: odoo/enterprise#105482 Forward-Port-Of: odoo/enterprise#104137
This update fixes an issue where annual returns incorrectly used a fiscal year filter when company fiscal years differed from the standard civil year. Now, annual returns always adhere to the company's civil year, ensuring accurate reporting and a better user experience. This improves the reliability of financial data presented in reports.
Original PR description
When a company fiscal year differs from the civil year, the annual return incorrectly falls back to the report’s FY-aligned year filter. The return should always follow the civil year, so the fallback is skipped and the return period filter is shown instead. task-5511074 Forward-Port-Of: odoo/enterprise#104726
This update resolves an issue preventing legal validation of the annual VAT report XML export for the Luxembourg (LU) localization. The fix adds missing required fields based on Luxembourg tax regulations, ensuring accurate report generation and compliance. This impacts users generating the annual VAT declaration.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
4 changes
Resolved issues and error corrections
This update fixes an issue where subscription invoices were being generated prematurely when a section or note was added to the subscription. The fix ensures that invoice dates align with the expected end of the subscription period, regardless of whether a section or note is included. This improves invoice accuracy and consistency for our subscription customers.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update resolves an issue where subscriptions with zero-sum quantities resulted in invoices being generated with the initial start date instead of the correct invoice date. The fix ensures accurate invoice date calculations by handling negative quantities correctly, preventing incorrect invoice generation.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#106364 Forward-Port-Of: odoo/enterprise#103705
This update corrects an issue where project forms, accessed through SmartButtons, were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing editing, ensuring users can now fully interact with project forms. The reason for this initial setting remains unclear.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#105225This update resolves an issue where toggling the Studio feature in Odoo Enterprise would sometimes disrupt the layout of form stat buttons. Now, the stat button layout remains consistent regardless of whether Studio is active, ensuring a better user experience when designing and editing forms.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309
16 changes
Resolved issues and error corrections
This update fixes an error in the calculation of VAT payable or refundable on Welsh tax returns. The formula has been corrected to accurately reflect the difference between output and input VAT, ensuring accurate reporting for businesses using the `l10n_cy` module. This ensures compliance with Welsh tax regulations.
Original PR description
**Steps to produce:** - Install the l10n_cy and accountant modules - Switch to `CY Company`. - Go to accounting > reports > Tax return. **Issue:** - The formula for VAT payable or refundable (difference between box 4 and 3) is incorrect. - box 3 refers to `Total output VAT` and box 4 refers to `Input VAT`. - Current formula: `cy_4.balance - cy_3.balance` **Fix:** - Formula for VAT payable or refundable should be output VAT - input VAT. - Update the formula to: `cy_3.balance - cy_4.balance` <img width="769" height="86" alt="image" src="https://github.com/user-attachments/assets/923a92f9-fc57-465a-9592-771730ee6870" /> opw-5751369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246273
This update fixes an issue where purchase order line descriptions weren't correctly reflecting the vendor's name or code, particularly when using dropshipping. The change synchronizes how descriptions are generated during PO creation and modification, ensuring accurate vendor information is displayed. This improves the clarity and accuracy of purchase order details.
Original PR description
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name…
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name - Put Dropship as the route for the product to create a PO on a SO confirmation - Create a SO with that product - Confirm the SO and go to the PO - Change the vendor in the SO The problem : The Vendor Code and/or Vendor Name does not change correctly in the product description Why : The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user. The problem was that the generation of the description for the creation of the PO and for the modification of the PO were different. The later did not take into account the attributes with free text values. This, in turn, made it so the current description was never in the collection of default descriptions and so the description was never changed. The change: This commit aims to resynchronize the generation of the description on the creation and on the modification. Both now uses the product_description_variants field. Note: The function that generates the description on PO creation is "_prepare_purchase_order_line_from_procurement" in purchase_order_line.py in purchase_stock Note 2: The purchased_product_matrix module partly fixed this issue by adding attributes with Variant Creation set to "never" to the description. I have removed this logic as the above fix also includes these attributes. opw-5888233 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 ensures popover animations in our tests run consistently, preventing rare timing issues that could cause unexpected behavior. By adjusting the animation timing, we've stabilized the testing process and reduced the risk of test failures. This improves the reliability of our software development.
Original PR description
Because the popover had his animation enabled in tests, it could in very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where loyalty coupon discounts weren't consistently applied during PoS settlement, particularly when using quotations. The fix ensures that discounts are accurately calculated and applied to all items, preventing double-counting of discounts and maintaining accurate pricing. This improves the reliability of PoS transactions.
Original PR description
**Steps to reproduce:** - Make a loyalty coupon program, like 10% on all products - Make a quotation in Sales, enter the coupon code - Go to PoS and click on settle this quotation - Add another product - The coupon discount is not applied on the new product - Enter the coupon code in the PoS - The coupon discount is applied on everthing including the already discounted items we are settling **Why the fix:** When settling a quotation, we should not count what has already been included in the discount in the Sales app. Instead we now update the discount line instead of importing the one from the quotation, then making a new one. This way, the discounts stay on one single line per program. opw-5171060
This update ensures that invoice currency rates are consistently rounded to the same decimal places, improving the accuracy of financial reporting. Previously, rounding behavior was inconsistent, which could lead to discrepancies in currency calculations. This change enhances the reliability of our accounting data.
Original PR description
task-5231229
This update fixes an issue where removing the last image from a paragraph in the HTML editor would leave the paragraph unusable. The fix ensures the paragraph remains editable by filling the parent block after the image is removed, improving the user experience.
Original PR description
Problem: When removing an image that is the only element inside a base paragraph, the paragraph remains empty and it becomes difficult to place the cursor inside it. Solution: This issue is already fixed in later versions. The fix consists in filling the parent block when its last remaining element (the image) is removed, so the paragraph stays editable. Steps to reproduce: - Add an image inside a paragraph. - Remove the image. - Observe that the HTML field collapses and the cursor is hard to place. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where task titles and descriptions generated from sales orders were incorrectly formatted. Now, task titles accurately reflect the sales order line description, and descriptions include all relevant details, regardless of whether the sales order line had a single-line or multi-line description. This ensures consistent and accurate task information within the system.
Original PR description
Steps to reproduce: - - Create a sales order with a service product that generates a task. - Add a multi-line description to the sales order line. - Confirm the order to generate the task. - View the generated task’s title, description. Issue: - - Task titles were generated in the format sales order name + first line of the product description, and the description contained only the remaining lines. Fix: - - If the sales order line has a single-line description, it is used as the task title. - If the sales order line has a multi-line description or no description, the product name is used as the task title, and the sales order line description is used as the task’s description. Commits 588c3be420a542d8594b26ecc200ca68e35d15fc, c3877b2acd74f1f798d0046b168418300f9e27ca, and 18edce4d859935bd1425144e4c835acabc5f68f4 previously attempted to fix this issue. task-4903208
This update corrects and enhances the tax descriptions and names used in the Belgian localization for Odoo. The changes include accurate translations, German translations, and a fix to ensure the 21% S.INC tax is correctly applied as an included tax. This ensures accurate financial reporting and compliance for Belgian users.
Original PR description
In this commit[^1] the tax descriptions and names for the Belgian localization were added/updated. However, some names or descriptions were either not fully correct, poorly translated, or not translated at all. In this commit, we revised them all and added German translations for everything as well. [^1]: https://github.com/odoo/odoo/commit/c7b39c5ad4afba7e61265773b87f500469ace91b
This update corrects a visual issue where datetime fields continued to display time even after the 'Show time' option was disabled in Studio. The fix ensures that the 'Show time' setting accurately controls the display of time in datetime fields, improving the user experience.
Original PR description
How to reproduce : - Pick any field in any model with the datetime type (Creating a new one in studio also works) - The field must not be set to readonly - Go to the form view - Go into Studio - Uncheck the checkbox for "Show time" - Close Studio The problem : The time is still shown Why: The service that manages the formatting for the datetime input does not take the "Show time" attribute into account. This commit (https://github.com/odoo/odoo/commit/08934cd399e95459234cb569a80876ca1fbc69e8) mentions the fact that to correctly handle the showTime option, the formatDate and formatDateTime must be imported from "@web/views/fields/formatters". 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 resolves a bug where users were unexpectedly logged out in Firefox due to a strict interpretation of redirect rules by the browser. The fix disables automatic session saving when requesting images, preventing Odoo from creating a new session and sending a misleading cookie. This ensures consistent session management across browsers.
Original PR description
## Problem A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this…
## Problem
A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this flow:
- A user (Person A) opens an Odoo record. The chatter contains an image previously sent by a correspondent (Person B) whose email client or mail server rewrote the image URL to point to a security proxy.
- Firefox tries to load the image. The URL points to `cisco.com/...`. (for example)
- The proxy scans the link and redirects the browser back to the original Odoo URL: `odoo.com/web/image/...`.
- Firefox follows the strict (now deprecated) `rfc6265bis` rule: it looks at the whole redirect chain.
Since it sees a cross-site hop (cisco.com), it flags the final request as cross-site.
-> Because Odoo's session_id is `SameSite=Lax`, Firefox refuses to send
the cookie on this "false" redirect
- Odoo receives the request at `/web/image` without a session_id.
- Odoo creates a new, empty session to process the request.
- At the end of the request, because save_session is True by default, Odoo sends a `Set-Cookie: session_id=NEW_EMPTY_ID` header in the response.
- The browser receives this `Set-Cookie` header, and this time *applies a different policy*: it considers the header as same-origin, allowing it to overwrite the previously valid session cookie with this new one that corresponds to a fresh, unauthenticated session.
- The user is instantly logged out of their current Odoo tab.
## Context on Web Compatibility
This "redirect chain consideration" was a controversial part of the `RFC6265bis` draft.
Chrome and Safari never fully implemented it because telemetry showed it broke ~1% of the web. In March 2024, the HTTP Working Group (HTTPWG) officially decided to remove this requirement from the spec (reverting to a more permissive model) because it was deemed not web-compatible. Firefox, however, still enforces this strict behavior in many versions.
## How to we fix this
We set `routing={'save_session': False}` on the `/web/image controller`.
- This prevents Odoo from sending the `Set-Cookie` header if the session is dirty or new.
- Even if Firefox sends the request without a cookie, Odoo won't "reply" with a new session ID.
- The user's legitimate session cookie remains untouched in the browser.
## Sources
- HTTPWG Decision (March 2024): https://github.com/httpwg/http-extensions/issues/2104
- Reverting RFC6265bis: https://github.com/httpwg/http-extensions/pull/2750
opw-5184217
opw-4698750
opw-5166151
Forward-Port-Of: odoo/odoo#242061This update corrects a bug where a duplicate skill was incorrectly added to an employee's resume after a validation error occurred during the skill selection process. The fix ensures that changes made to the virtual record are properly discarded when a validation error is detected, preventing unintended skill additions.
Original PR description
Steps to reproduce: --------------------------------- 1. Install `hr_skills` module 2. Open the Employees app and open any employee record 3. Go to the Resume tab 4. In the Skills section, click Add…
Steps to reproduce: --------------------------------- 1. Install `hr_skills` module 2. Open the Employees app and open any employee record 3. Go to the Resume tab 4. In the Skills section, click Add for any skill type 5. Select a skill that is already added to the resume 6. Click Save & Close in the Select Skills wizard 7. A validation error is displayed, click Close 8. Close the Select Skills wizard. Observation: --------------------------------- After closing the wizard, another default skill is added to the resume even though a validation error was raised. Issue: --------------------------------- In the following code: https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/hr_skills/static/src/fields/skills_one2many/skills_one2many.js#L79-L82 During record save, the validation error scenario was not handled properly. When a validation error occurred, changes made to the virtual record were not discarded, causing the initial (invalid) changes to be incorrectly retained instead of being rolled back Solution: --------------------------------- When a validation error occurs while adding a skill, discard all changes made to the virtual record before throwing the error. This ensures that no unintended skill is added. opw-5423196 Forward-Port-Of: odoo/odoo#240697
This update resolves a problem in the HTML editor within Odoo's collaboration feature, specifically when using Safari. The issue occurred due to incorrect document selections, often triggered by Chrome users' undo history. The fix ensures the HTML editor correctly handles selections from Safari, preventing errors and improving the user experience.
Original PR description
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with…
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text 2. In one of the middle lines, delete one character --> undo --> add a new character 3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field 4. TraceBack: IndexSizeError: The index is not in the allowed range. After this commit: we use the range of the DOM selection to set the offsets of activeSelection. If the DOM selection is too wrong to be corrected, e.g. the selection's anchor node isn't the same with range's start container (or end container if direction is right to left), we do not set new activeSelection but just return the previous activeSelection task-5428788 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices created in one company could incorrectly use accounts from a different company. The change adds a validation check to ensure invoice line accounts always belong to the invoice's company, preventing data inconsistencies and ensuring accurate financial reporting. This improves data integrity and reduces potential errors.
Original PR description
### Issue: When an invoice is created for a company and then its company and journal are changed to another company valid combination, the accounts on the invoice lines are not updated automatically This leads to inconsistencies where move lines use accounts that do not belong to the move’s company ### Cause: A validation check ensuring that move line accounts belong to `move.company_id` or parents was missing in `_post()` for account moves ### Steps to reproduce: - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A - Change the invoice company to Company B and set a journal belonging to Company B - Save and confirm the invoice opw-5167958
This update enhances the account_edi_ubl_cii module by incorporating commodity codes from standard systems like Intrastat, UNSPSC, and CPV. These codes are now included in export invoices, improving data accuracy and compliance for international trade reporting. This ensures Odoo can properly handle and process export transactions.
Original PR description
task-5890887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the process of exporting the general ledger as an Excel file. By batching the export, the system avoids running into memory issues, leading to a more reliable and efficient experience for users generating these reports. This enhancement ensures faster and more stable report generation.
Original PR description
Batch the xlsx export of the general ledger to avoid memory errors task-5476982 Forward-Port-Of: odoo/enterprise#103329
This update resolves a technical error that prevented the correct display names from being set for spreadsheet cell threads. The change ensures that only one display name is retrieved, preventing a system crash and improving spreadsheet functionality. This resolves a minor internal issue.
Original PR description
**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947
4 changes
Resolved issues and error corrections
This update fixes a bug that caused invoices sent to Peppol to be incorrectly marked as ‘skipped’ upon repeated resends. The change prevents users from resending invoices already in a ‘processing’ or ‘skipped’ state, ensuring accurate Peppol integration and avoiding potential delays in invoice delivery. This improves the reliability of our Peppol transactions.
Original PR description
This fix addresses two issues related to resending invoices via Peppol. It prevents users from accidentally resending an invoice and having its status incorrectly set to “skipped”. It also prevents from resending an invoice via Peppol when it is already in a “processing”, then "skipped" state. Steps to reproduce: - Create and send a customer invoice to Peppol - Try to send it again, Odoo sets the status to “skipped” - Try to send it again, Odoo resends the invoice via Peppol This fix is a light adaptation of the `_is_applicable_to_move` method introduced in version 18. After the fix: Trying to resend to Peppol an invoice already in "processing" or "done" state is prevented. opw-5491341
This update fixes an issue where the Stock Forecasted report incorrectly displayed stock quantities after a repair order was deleted. The fix ensures that related stock moves are properly cancelled when a draft repair order is removed, providing accurate stock reporting for repair operations. This improves the reliability of inventory tracking within the repair process.
Original PR description
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in…
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in *draft* state (do not confirm). * In the **Parts** tab, add the storable product with the operation type set to *Add*. * Open the **Stock Forecasted** report for the added product. Note the quantity shown under *Outgoing Draft Transfer*. * Delete the **Repair Order**. * Open the **Stock Forecasted** report for the same product again. **Observed behavior:** * The quantity still appears in the **Stock Forecasted** report under *Outgoing Draft Transfer* even after the repair order is deleted. **Cause:** * Deleting a draft repair order triggers `_unlink_except_confirmed`. * This method prevents related stock moves from changing their state to cancel when the repair order is deleted. * The *Outgoing Draft Transfer* value is calculated as the sum of quantities of stock moves in draft state at draft state. https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49 https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90 * As a result, deleting a draft repair order leaves related stock moves in draft state, causing them to appear under *Outgoing Draft Transfer* https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335 **Fix:** * Ensure that related stock moves are properly cancelled when a draft repair order is deleted. --- opw-5449323
This update replaces a real tax ID placeholder in the Odoo Base VAT module for Turkey. This change prevents users from accidentally using the placeholder for actual transactions, ensuring data integrity and compliance. It’s a minor update focused on security and accuracy.
Original PR description
The previous placeholder used a real tax ID. Replacing it with a dummy prevents users from using it to submit transactions. task-5441218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242189
This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when records were updated. The change ensures that the correct URL is transmitted upon record saving, improving data synchronization between the system and the IoT devices. This addresses a technical bug impacting device functionality.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927