Daily updates from Odoo
Wednesday, February 4, 2026
143 changes
34 changes
Resolved issues and error corrections
This update resolves an issue where the carrier type selection would become disabled after validating a mobile barcode. The fix ensures the carrier number input remains editable whenever the carrier type is changed, allowing users to correctly select and input carrier information during the order process. This prevents data loss and improves the user experience.
Original PR description
carrier type After the user clicks on "Validate" button to validate the mobile barcode, the carrier type selection is disabled and the carrier type pass to the SO is None. This commit fixes the issue by instead of disabling the carrier type selection, we just set the input box of carrier number to readonly and set back the carrier number to not readonly when the user changes the carrier type to ensure the carrier number input is editable. task-5880421 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#246767 Forward-Port-Of: odoo/odoo#246053
This update resolves an issue where the cost of kit products was incorrectly reset to zero when a delivery was validated. The fix ensures the correct kit price is calculated by using the sale order line's product ID instead of the stock move record, leading to accurate cost calculations for delivered orders.
Original PR description
Currently when the user validates a sale order delivery which has a kit the cost gets reset to 0. <h2>Steps to produce:</h2> * Install sale_margin, sale_management, mrp * Create a product with an…
Currently when the user validates a sale order delivery which has a kit the cost gets reset to 0. <h2>Steps to produce:</h2> * Install sale_margin, sale_management, mrp * Create a product with an AVCO or FIFO product category * Create a BOM of type ‘Kit’ for that product. * Add components A and B to the BOM, each with an on-hand quantity and a cost of 10. * On the kit product compute the cost according to the BOM * Create and confirm SO for 1 unit of the kit product * Delivery > Validate the Delivery and go back to the Sale Order Replication video: [Link](https://drive.google.com/file/d/1PgAh1xwBZX7RsRQ5ZsQipqYjuxvex2CA/view?usp=sharing) <h2>Observed Behavior:</h2> The product cost on the sale order is set to 0, but it should be 20. <h2>Root cause:</h2> After commit [1], an override for `_get_price_unit` was added to correctly calculate kit prices for BOM products. The goal was to prevent the cost from being set to 0 after a delivery is validated. However, when this logic is triggered during delivery validation, it doesn’t behave as intended. After the delivery is validated, compute [2] runs and calls function [3]. However, `self` at [3] refers to a stock move record, so we get the components of the kit instead of the kit product itself. The function `_bom_find` expects the main kit product, not the components. Because of this, the kit’s unit price isn’t calculated, and the parent function [4] ends up setting the purchase price to 0. <h2>Solution:</h2> Use the kit product IDs from the sale order lines instead of the move lines, ensuring the main kit product (not its components) is used and the BOM is found properly. Return unit price for kit products instead of total value for the function `_get_kit_price_unit` Update the test case to account for delivered quantities: **Before:** The sales order used Units as the unit of measure while the product and stock moves use a pack of 10. Since only 3 units get delivered and one product equals 10 units, this was not counted as a full delivery. Therefore, the delivered quantity was treated as 0, which allowed the product cost to be set at [5] and pass the test case **After:** The test now covers the case where a full quantity is delivered by using a pack of 10 as the unit of measure on the sales order. This ensures the product cost is handled correctly when the delivered quantity is 1 or more. [1]: https://github.com/odoo/odoo/commit/5a44ae1ec71573c57a5d60903f9b81e842fc582b [2]- https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_stock_margin/models/sale_order_line.py#L11-L34 [3]- https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_mrp/models/stock_move.py#L9-L16 [4]- https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/stock_account/models/stock_move.py#L230-L233 [5]- https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_stock_margin/models/sale_order_line.py#L21-L22 opw-5479266 Forward-Port-Of: odoo/odoo#246030
This update resolves an error that occurred when users created reminders in the calendar module. The issue stemmed from a recent change in how selection fields are handled, specifically when clearing the 'Type' field. This fix ensures the system correctly processes this action, preventing the error and allowing users to successfully create reminders.
Original PR description
Currently, an error occurs when user creates a reminder. **Steps to Reproduce:** - Install the `calendar` module. - Go to `Calendar` > `Configuration` > `Reminders`. - Create a `new reminder` and…
Currently, an error occurs when user creates a reminder.
**Steps to Reproduce:**
- Install the `calendar` module.
- Go to `Calendar` > `Configuration` > `Reminders`.
- Create a `new reminder` and clear the `Type` field.
`KeyError: False`
**Cause**:
- Error started occurring in 19.0 due to a change in selection field behavior. Since change https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef, selection fields no longer display an “empty” value.
- To remove a value from a selection field, the user must clear the field, similar to a many2one field.
- When the Type field is cleared, its value becomes False, which raise the error here [1].
**Fix:**
- This commit ensures that when the alarm type is False, display_alarm_type is set to an empty value
similar to the display interval [2].
- Since both fields are required, once they are set again, the correct name is computed accordingly.
[1]: https://github.com/odoo/odoo/blob/2ee2f7678ed262036ee8cf8719ceafd3d69d4062/addons/calendar/models/calendar_alarm.py#L72-L74
[2]: https://github.com/odoo/odoo/blob/97e90f14ea40e4dc8645f845ef78eb579bb3e8dc/addons/calendar/models/calendar_alarm.py#L71
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243526This update fixes an issue where the loyalty program button was incorrectly highlighted when rewards weren't available. Now, the button will only appear if the user has valid rewards, providing a cleaner and more accurate representation of the loyalty program options for customers.
Original PR description
Before this commit: ========= - The more control button was being highlighted even if rewards were not available. After this commit: ========= - The more control button will be highlighted if only valid rewards are there. task-5438708 Forward-Port-Of: odoo/odoo#241976
This update fixes a visual inconsistency in video link previews, specifically for YouTube videos. Previously, thumbnails left blank spaces, resulting in a broken layout. Now, thumbnails consistently fill the container, ensuring a uniform and professional appearance for all video previews.
Original PR description
**Purpose of this PR:** Before this commit, video thumbnails from youtube left blank spaces in the container, creating inconsistent layouts across different video links. After this commit, thumbnails consistently fill the entire container, ensuring uniform appearance for all video link previews. **Before/After:** <img width="533" height="407" alt="image" src="https://github.com/user-attachments/assets/ce2ba872-27b7-4be5-9d85-fbbe6f272e14" /> <img width="481" height="386" alt="image" src="https://github.com/user-attachments/assets/523f5d16-2983-49c1-9dcc-01adb4284e56" /> task-5424534 Forward-Port-Of: odoo/odoo#246856 Forward-Port-Of: odoo/odoo#244176
This update resolves an issue where website editing was blocked while the global search modal was open. The change automatically closes the search modal when you enter edit mode, allowing users to seamlessly add and manage website snippets. This improves the overall website editing experience.
Original PR description
Steps to reproduce: 1. Go to the Website. 2. Click the search icon in the header. 3. When the search modal opens, click 'Edit' to enable website editing. 4. Attempt to add a snippet. Observed behavior: - Snippets cannot be added while the global search modal remains open. Expected behavior: - Snippets should be draggable and added normally in edit mode. This commit ensures that the global search modal is closed when entering edit mode, preventing it from blocking add snippet. task-5421051 Forward-Port-Of: odoo/odoo#241414
This fix addresses an issue where users could attempt to consolidate invoices for multiple orders within the Veri*Factu POS module. The system has been updated to prevent this consolidation, ensuring that invoices are created for each order individually. This change improves data accuracy and avoids potential errors related to combining multiple sales transactions.
Original PR description
Step to reproduce: - install `l10n_es_edi_verifactu_pos` and open POS - finalize 2 order with same customer (do not invoive it) - close session - go to pos orders, select both order and try to create…
Step to reproduce:
- install `l10n_es_edi_verifactu_pos` and open POS
- finalize 2 order with same customer (do not invoive it)
- close session
- go to pos orders, select both order and try to create consolidated invoice
Traceback:
```
File "/home/odoo/addons/l10n_es_edi_verifactu_pos/models/pos_order.py", line 293, in _prepare_invoice_vals
res['l10n_es_edi_verifactu_refund_reason'] = self.l10n_es_edi_verifactu_refund_reason
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/orm/fields.py", line 1365, in __get__
record.ensure_one()
```
Cause:
- `_prepare_invoice_vals` is written to accept only one order at time but it can contain multiple orders
Fix:
- we now do not allow invoice consolidation for Veri*Factu
- the consolidation flag has been made invisible so every order now has
to be invoiced individually.
opw-5379577
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239391This update resolves an issue where setting a receivable or payable account on the 'Expense Account' or 'Income Account' settings would trigger an error when creating a bill. The fix ensures the correct domain constraint is applied to related fields, preventing this user error and improving bill creation functionality.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Settings" - Edit "Expense Account" property **Issue:** It is possible to set a receivable or payable account for the property. If a payable account is set, a constraint will trigger a UserError when trying to create a bill with that account. The same issue happens for "Income Account". **Cause:** The field is a related field. On the original field, there is a domain to prevent selecting these types of account, but the domain is not applied to the related field. **Solution:** Checking the company will retrieve the domain set on the original field. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246798
This update corrects a random test failure related to how Odoo's datetime fields are rendered in editable list views. The fix ensures consistent rendering of the date picker, preventing unexpected UI behavior. This improves the stability and reliability of the web application.
Original PR description
This commit fixes two unit tests involving the datetime field which are randomly failing since [1]. In the first one, we add a record in an editable list view. The first field is automatically…
This commit fixes two unit tests involving the datetime field which are randomly failing since [1].
In the first one, we add a record in an editable list view. The first field is automatically focused (in `onMounted`). Before this commit, the first field was the datetime. When it is focused, the datetime field re-renders itself (from a `<button>` to an `<input>` with datepicker). The test failed when those two renderings were done within the same animationFrame, which was rare but possible. We fix the test by moving `foo` field before `date`, that way, the date field is never focused, and we can properly assert the default date value.
In the second one, again in an editable list, we select a date in the picker, and we then assert that the field is rendered with a `<button>` whose text is correct. The test sometimes failed because there was no button (the field was still displaying an `<input>`). When the value is selected, an update is done in the model, which triggers a re-rendering. At that moment, the picker still states that there's an `activeInput` ("date"), so the field is rendered with an input. The picker state is only updated afterwards, so there's another rendering, where `picker.activeInput` is "", which leads to the expected `<button>` being rendered. However, that rendering can happen in another animationFrame, thus triggering the issue. This commit fixes it by simply waiting for the button to be displayed.
[1] https://github.com/odoo/odoo/pull/218387
runbot error-238437 (1)
runbot error-238758 (2)
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#247026This update resolves an issue where enabling tracking on custom HTML fields within invoices caused update failures. The change hides the 'Enable Ordered Tracking' option for these fields, preventing the error and ensuring data updates work correctly. This improves stability and reliability for users modifying invoice data.
Original PR description
From https://github.com/odoo/odoo/pull/241367#issuecomment-3711040501 Nothing prevent tracking from being enabled on HTML fields, but if it is enabled, updates of the field systematically fail. This commit avoids this error by hiding the "Enable Ordered Tracking" for HTML fields. Steps to reproduce: - Install sale and web_studio - Activate debug mode - Add a custom HTML field inside the invoice form view - Open the "More..." of the field (or go to Settings/Technical/Field) and go to the new field - Set "Enable Ordered Tracking" to 1 - Save - Go to an invoice and modify the new field - Save => An error was displayed task-5236436 Forward-Port-Of: odoo/odoo#242183
This pull request addresses several bugs and improvements within the Hoot system, enhancing its reliability and test coverage. The fixes include correcting error messages, expanding the mocked API for more robust testing, and streamlining test assertions. These changes ensure Hoot functions correctly and provides a more stable experience.
Original PR description
### [FIX] Hoot fixes This PR contains several fixes for the Hoot system. See each commit description for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246402 Forward-Port-Of: odoo/odoo#244726
This update fixes a technical issue that prevented loyalty rewards from applying correctly when associated products were archived or invalid. The system now intelligently skips loading these rewards, ensuring a smoother and more reliable experience for users. This improves the overall stability of the POS loyalty program.
Original PR description
Steps: --------- - Install pos_loyalty. - Add a product to a loyalty reward’s reward product, or assign a product tag with no actual products as a reward product tag. - Archive/delete the reward product. - Open session. Issue: ---------- - A traceback appears when attempting to apply the affected reward, due to the archived/deleted or invalid reward product is being loaded in the POS. FIX: ----------- - Skip loading loyalty rewards whose reward product is archived/deleted or whose reward product tag contains no valid products. Task-5226654 Forward-Port-Of: odoo/odoo#242776 Forward-Port-Of: odoo/odoo#235081
This update resolves a slow loading issue for custom fonts on the Odoo website, particularly when users upload large images. The change optimizes a key process to reduce the time it takes to apply custom fonts, improving the user experience and preventing timeouts.
Original PR description
Steps: - Install `website` - Open website editor - Themes -> Font Family -> Add a Custom font - Choose a random font from the list - Uncheck "Serve font from Google servers" - Save and Reload - Timeout in case of *.odoo.com because it can take a very long time (more than two minutes) This commit improves `make_scss_customization`, because there is a regex that scans the file several times to find the user_values.scss hook in our case. This regex can easily be improved by checking only the beginning of lines after spaces instead of checking all characters. from ```py updatedFileContent = re.sub(r'( *)(.*hook.*)', r'\1%s\1\2' % replacement, updatedFileContent) ``` to ```py updatedFileContent = re.sub(r'^( *)(.*hook.*)', r'\1%s\1\2' % replacement, updatedFileContent, count=1, flags=re.MULTILINE) ``` opw-5178930 Forward-Port-Of: odoo/odoo#245907
This update adjusts the size of confirmation dialogs across Odoo to better align with frontend design standards and prevent interruptions. By allowing different sizes, the dialogs are now more appropriately sized for various scenarios, improving the user experience and reducing context-switching. This change ensures a smoother and more intuitive confirmation process.
Original PR description
### Context: A confirmation dialog must be small and minimal for several reasons: - Users are being interrupted mid-task. A wall of text forces them to context-switch and parse information when they…
### Context: A confirmation dialog must be small and minimal for several reasons: - Users are being interrupted mid-task. A wall of text forces them to context-switch and parse information when they just need to make a quick decision - The goal is a binary choice (confirm/discard). Too much content complicates what should be a simple yes/no moment - ... In the backend, our dialogs `SM` size is set to a **forgiving** `460px`. This value allows dialogs to be relatively small, while still providing enough tolerance to showcase more content if necessary. In the frontend, instead, the default value in use is BS default, thus `300px`. A website default font-size is also much bigger, `16px` against `13px` in the backend. As a result, the dialog may be too small when used in scenarios that are not "confirmation dialogs" strictly speaking. ### The issue: In some cases, enforcing SM size to any confirmation dialog gives bad results in the frontend. | backend | fronted | |--------|--------| | <img width="644" height="370" alt="image" src="https://github.com/user-attachments/assets/ab40312a-06df-4203-8b3d-3b2074341986" /> | <img width="667" height="416" alt="image" src="https://github.com/user-attachments/assets/c0770de4-e3c0-4a15-b2a5-6a498c94fb20" /> | Enforcing a higher `SM` value for the frontend (eg. `500px`) is not a solution because the default BS value is technically correct and users can customize it anyway by overriding this setting. ### The solution: Allow the ConfirmationDialog component to use sizes different from `SM`. This commit sets some portal dialogs to MD size. | saas-19.1 | this pr | |--------|--------| | <img width="667" height="416" alt="image" src="https://github.com/user-attachments/assets/c0770de4-e3c0-4a15-b2a5-6a498c94fb20" /> | <img width="953" height="605" alt="image" src="https://github.com/user-attachments/assets/07eab456-97c3-4e9d-8ce2-dd79ac5b82d4" /> | task-5906425 note: Several design improvements are necessary and will be handled in forward-port targeting master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a validation error preventing employees from requesting time off when using a 2-week calendar schedule. The issue stemmed from visual calendar lines used for formatting that were incorrectly impacting date calculations. This change ensures accurate PTO requests are processed for all calendar types.
Original PR description
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select…
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off. - Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025. - While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone. - From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025. - From the employee's profile > Time Off, try to take a Monday off. Issue: - The user gets a Validation error stating that the "start date" is later than the "end date". Fix: - In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off. - Add a check to remove lines from calendar that are just there for display purposes. opw-5387347 Forward-Port-Of: odoo/odoo#246565 Forward-Port-Of: odoo/odoo#246094
This update streamlines Odoo tests by disabling unnecessary device checks during testing. Previously, tests triggered frequent queries to detect device changes, slowing down the testing process. This fix improves test performance and efficiency without impacting the core functionality of Odoo.
Original PR description
In tests, when using `authenticate`, we create a session. When this session is retrieved (for example because we use `url_open`), we detect a new device and insert a log. The consequence is that a query is performed in many tests and that is not necessary. The fix consists of disabling the `res.device.log` feature by default in tests. task-5894825 Forward-Port-Of: odoo/odoo#246445
This update resolves an issue where the color filter applied to video backgrounds would disappear after saving the page. The fix ensures that the color filter is correctly re-applied when a video background block is selected and saved, maintaining the intended visual style. This improves the consistency and reliability of video background customizations.
Original PR description
The color filter applied to a video background would disappear after selecting the block and saving the page again. Steps to reproduce: =================== 1. Enter Edit mode on the website. 2. Drag…
The color filter applied to a video background would disappear after selecting the block and saving the page again. Steps to reproduce: =================== 1. Enter Edit mode on the website. 2. Drag and drop a snippet (e.g., "Intro"). 3. Set a video background for the block and apply a color filter. 4. Save the page. 5. Enter Edit mode again, click the block to select it, and Save. -> The color filter is removed from the video background. Cause: ====== Selecting the block triggers the `toggleBgImageClasses()` function. This function attempts to determine the background configuration. Since a video background is used, there is no standard image URL, so the code proceeds to call `setImageBackground` with an empty URL ([1]). This update process involves re-applying the color filter via the `selectFilterColor` action. However, the current background image style (the filter color) was not being passed to this function during this specific update flow. Consequently, the function assumed no filter existed and removed it ([2]). Solution: ========= Retrieve the current `filterColor` (which exists in background-image style) and pass it explicitly when calling the apply function. [1]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option.js#L18-L20 [2]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option_plugin.js#L170 opw-5448696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242236
This pull request restores previously disabled tests in the project and stock accounting modules. A recent change removed key code components needed for accurate accounting related to manufacturing orders, causing tests to fail. The fix reintroduces these components with updated names and necessary sudo permissions to ensure correct operation.
Original PR description
Bring back all tests temporarily disabled by [1]. Below are the explanations about the needed changes in the code. --- Change in `/project_mrp_account:MrpProduction.write` Tested by…
Bring back all tests temporarily disabled by [1]. Below are the explanations about the needed changes in the code. --- Change in `/project_mrp_account:MrpProduction.write` Tested by `/project_mrp_account.test_changing_mo_analytic_account` In the test, when changing the project of the MO: https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L211-L212 We reach the override in `project_mrp_account`. On Odoo 18.0, a line calls the method `_account_analytic_entry_move`: https://github.com/odoo/odoo/blob/706431510110a005618a2acaf6566f2bb61d5114/addons/project_mrp_account/models/mrp_production.py#L31 This line is in charge of creating AA/AAL related to the SM. However, the commit [1] has removed `account_analytic_entry_move` and all its calls. This is why the test fails in the first assert: https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L210 It doesn't find anything. However, the commit [2] brings the method back with a brand-new name: `_create_analytic_move`. We therefore need to connect it again where it is needed. --- Change in `/stock_account:StockMoveLine.write` Tested by `/project_mrp_account.test_update_components_qty_to_0` Quite the same as above. Commit [1] removes this while it's actually needed. One difference, a `sudo` call, because a stock user doesn't have any access to analytic world. --- Change in `/stock_account:StockMoveLine.unlink` Tested by `/project_mrp_account.test_mo_qty_analytics` Same as above, also with a new `sudo`. --- [1] https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229 [2] 35db55618fa70146afc89e662410aca95947e17b Forward-Port-Of: odoo/odoo#245864
This update resolves an issue where a specific filter in the Accounting app was failing due to an unsupported operator ('any') in how it searched for analytic distribution accounts. The change converts 'any' to 'in' and 'not any' to 'not in', aligning with standard relational field behavior and ensuring the filter works correctly. This prevents errors and allows users to accurately filter journal items based on their analytic distribution.
Original PR description
`distribution_analytic_account_ids` is a virtual relational field backed by the `JSON` field `analytic_distribution`. Its custom search method did not handle the `any` / `not any` operators, causing…
`distribution_analytic_account_ids` is a virtual relational field backed by the `JSON` field `analytic_distribution`. Its custom search method did not handle the `any` / `not any` operators, causing domains like:
```py
('distribution_analytic_account_ids', 'any', <analytic.account domain>)
```
to fail during domain optimization with errors such as:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```
This commit adds support for relational semantics in `_search_distribution_analytic_account_ids` by resolving the RHS domain on `account.analytic.account` into ids and converting:
- `any` → `in`
- `not any` → `not in`
This aligns the behavior with relational field expectations while keeping the logic at the field search level instead of modifying domain internals.
**Steps to reproduce:**
- Created a `v19` db and install Accounting app
- Navigate to `journal items` menu
- Add the custom filter: `[("distribution_analytic_account_ids.plan_id", "in", [2])]`
- In logs you will see:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```
- In UI it will pop up domain is invalid.
opw-5875337
upg-3855669
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246965This update corrects a technical issue where overtime calculations were imprecise due to storing minutes as 'minute and twelve seconds'. This change ensures more accurate overtime totals, particularly when processing large attendance records for reporting and balance calculations. It improves the reliability of our HR data.
Original PR description
### Current behavior: Overtime hours are stored with a two-decimal point precision. This means a minute is stored as a minute and twelve seconds in the worst case, which would amplify the overtime given or taken on a particular attendance. This is problematic when aggregating the records for large datasets to compute the balance or for reporting ### Expected behavior: A minute should be stored closer to its real decimal value to minimize the error in aggregations as a minute and 1.2 seconds opw-5422827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244962
This update resolves an issue where the website preview would briefly delay after a hover, causing a slight lag for users. The fix ensures previews revert instantly as text is typed, preventing data loss. This enhancement improves the overall user experience when customizing website elements.
Original PR description
With commit aa3a2a694930d077aab5ff55e72655cc453a64ff, the delay of one animation frame in the preview of `templatePreviewableWebsiteConfig` is not necessary anymore. This was the only preview with a delay that can be triggered by hovering a button (the others needs to open a dropdown or input in text field). With commit be032732d1f5d1f7b28da3fa7bf19bffbef4a46d, previews are reverted as soon as the user starts typing, to avoid loosing the typed text when the preview is reverted. But this does not handle completely previews that are async: they may revert just after the first character is typed, and thus loose that character. This commit eliminates async preview that can be triggered while keeping focus in the editor. task-5493193 Forward-Port-Of: odoo/odoo#243727
This update prevents a situation where users in different branches could create the same tax name. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee that tax names are unique, avoiding potential errors and data inconsistencies when managing taxes across multiple company locations.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243364 Forward-Port-Of: odoo/odoo#243185
This update fixes a bug where users weren't receiving notifications for sub-channels they were mentioned in, but weren't officially members of. The change automatically adds these users to the sub-channel, ensuring they receive pinned notifications and don't miss important updates.
Original PR description
Before this commit, when a user was mentioned in a sub-channel they were not member of, the sub-channel would not appear in their sidebar. This could lead to some missed pings. This commit fixes the issue by automatically adding mentioned users to the sub-channel, ensuring it is pinned to their sidebar. task-5233958 Forward-Port-Of: odoo/odoo#246822 Forward-Port-Of: odoo/odoo#237538
This update fixes an issue where the description field in the calendar popover wasn't wrapping text properly, causing long descriptions to overflow and be difficult to read. The change adds a 'text-wrap' class to the description field, ensuring that descriptions are displayed neatly and fully within the popover window. This improves the user experience when viewing calendar events with detailed notes.
Original PR description
Changes done: - [x] `calendar`: Add `class="text-wrap"` in the description field of the calendar view to use it in the popover - [x] `web`: Define the appropriate class in the calendar popover field **Before** <img width="548" height="428" alt="antes" src="https://github.com/user-attachments/assets/77060ee6-30a1-47ed-8ba4-d5c2baa33fe3" /> **After** <img width="559" height="627" alt="despues" src="https://github.com/user-attachments/assets/cc9dfb47-3f98-4b5b-80c2-c3e5c15df0b0" /> @Tecnativa TT60670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247111 Forward-Port-Of: odoo/odoo#246924
This update fixes a problem that was preventing new PEPPOL registrations from working correctly. The issue stemmed from a previous update causing conflicts with existing user accounts, leading to a failure for all new registrations. This ensures seamless registration processes for our PEPPOL users.
Original PR description
Fix regression of participant fetch cron introduced in forward port odoo/odoo#245038 Indeed self might be a record set in lots of different cases, which leads to users at least 1 existing edi proxy user in their company, all future registrations will fail
This update resolves a bug that caused invoice generation errors when dealing with multiple tax lines, particularly during Peppol integration. The fix ensures accurate tax calculations by grouping tax lines before aggregation, preventing division-by-zero errors. This improves invoice accuracy and reliability for Belgian localization.
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 decimal quantities were incorrectly rounded during packaging transfers when 'Reserve Only Full Packagings' was enabled. The change ensures accurate quantity calculations, preventing delays and errors in order fulfillment. It impacts products within specific packaging categories.
Original PR description
When a product is part of a group with Reserve Only Full Packagings enabled, another check occurs in _check_qty. This rounds with a precision of 1.0 the down rounding method. In the case that the…
When a product is part of a group with Reserve Only Full Packagings
enabled, another check occurs in _check_qty. This rounds with a precision
of 1.0 the down rounding method. In the case that the quantity was a
decimal, such as 22.4, this would be rounded to 22. In the next transfer
the quantity would then only be 22 instead of the expected 22.4. This
would also cause any packages to not be added as the quantity and demand
are not equal.
If the uom of the product and package are the same we dont need this
package check. Which also prevents the rounding issue.
This fix insures the _check_qty method does not round in cases it does
not need to. (self == uom_id)
How to reproduce:
In Settings:
Enable Units of Measure & Packagings
Enable Multi-Step Routes
In Warehouses
Set Outgoing Shipments to Pick then Deliver (2 steps)
In Inventory
Create a new product
Give the product a category
Set category Reserve Packagings to Reserve Only Full Packagings
Set on-hand amount
Workflow:
Create a sales order
Create a new Company
Add product with decimal quantity (1.3)
Confirm SO
Go to the sale order delivery
Validate
Go to the next transfer
Quantity will now be rounded (1.0)
opw-5486932
Forward-Port-Of: odoo/odoo#246208This update resolves a crash that occurred when users attempted to access report settings while a report was still loading. The issue stemmed from attempting to access data before it was fully available, leading to a system error. This change ensures reports load correctly and settings can be accessed without causing a crash.
Original PR description
When a report was loading if a reportAction was used and no report already was loaded before, it would crash. This happened because we tried to get the context from the data which were not yet loaded. To reproduce: - switch to debug mode (?debug=1) - add a 5s delay in _get_lines - when a report is opening, try to click on the settings cog that appear in debug mode Forward-Port-Of: odoo/enterprise#103636
A recent issue causing errors on the payment page when using Avatax with Point of Sale has been resolved. This was due to an outdated method that no longer existed, and the code has been updated to remove its usage. This ensures a smoother payment experience for users.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#106135 Forward-Port-Of: odoo/enterprise#102101
A client reported issues processing payments via Bankgiro accounts. This update corrects a typo and adjusts the order of data fields in the payment processing, ensuring Bankgiro payments now function correctly. This resolves a critical payment processing error.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
This update resolves an issue where the automatic signer selection during a tour could fail, leading to incorrect assignments. By directly selecting the signer with the exact name, the system now reliably assigns signers, ensuring accurate tour execution. This fix was triggered by a test failure and improves the overall tour experience.
Original PR description
The method of clicking on the first child in the autocomplete is correct but sometimes brings about problems. In particular, if the test is too fast the search doesn't keep up, so either nothing or the wrong result gets selected. By instead choosing the child with the exact Name that we want, we ensure the correct selection. This solves the following: Runbot Error: 237717
This update corrects a bug that prevented users from uploading new PDFs to sign when the 'signature' item type (ID 1) was deleted. The issue stemmed from a recent change that created a dummy item for role recognition, leading to an error if no item type was found. This fix ensures smooth sign upload functionality.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#106138This update resolves a problem where IoT reports generated from Point of Sale (PoS) were failing due to PoS using incorrect identifiers. The fix filters out reports that aren't meant to be rendered as PDFs, ensuring reliable report generation.
Original PR description
Rendering IoT reports from PoS is failing because of PoS using string uuids as `res_ids`. As they are not required to render pdf reports, we filter them out. Forward-Port-Of: odoo/enterprise#106277
This update fixes issues with how Odoo's website content is scraped, ensuring accurate data retrieval. Specifically, it addresses problems with robots.txt blocking and cleaning up unwanted website elements like popups, improving the overall quality of the website data.
Original PR description
## Fix Summary - Include the instance's base URL in internal domains to allow bypassing robots.txt checks for sites that have no domain. - Fix the scraper's cleaning logic to prevent content containers deletion edge cases on Odoo websites. - Refine noise removal for Odoo websites (popups, cookie bars, etc.). Forward-Port-Of: odoo/enterprise#106237
4 changes
Resolved issues and error corrections
A recent error message appearing during payment processing with Avatax has been resolved. This was caused by an outdated method that no longer exists in the system. The fix removes this unused method, ensuring smooth payment processing for users utilizing Avatax.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#106135 Forward-Port-Of: odoo/enterprise#102101
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments continue to link to employees, even after they've been archived, improving data accuracy and reporting.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
A client reported that bankgiro payments were failing. This pull request corrects a typo and adjusts the order of data fields in the payment processing, ensuring bankgiro payments now function correctly. This resolves a critical issue impacting payment processing.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
This update resolves an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a recent change that created a dummy item to track roles, leading to an error when no item type was found. This fix ensures a smoother sign upload process.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#10613817 changes
Resolved issues and error corrections
This update resolves an issue preventing single-tenant Odoo apps using Microsoft Calendar from properly renewing their access tokens. By using the correct, tenant-specific Microsoft token endpoint, the calendar sync now functions reliably for these applications, ensuring seamless calendar synchronization with Outlook.
Original PR description
Single-tenant Azure applications could synchronize calendar with Outlook, but refresh token renewal fail. Odoo was always using the default Microsoft token endpoint instead of the tenant-specific endpoint required for single-tenant apps. Steps to reproduce: - Create a single-tenant app in the Azure portal - Configure Odoo Microsoft Calendar with this app - Set `microsoft_account.auth_endpoint` and `microsoft_account.token_endpoint` system parameters with the specific endpoints using the tenant ID - Open the Calendar app and sync with Outlook - Wait for access token expiration - Refresh token request fails This commit fixes the issue by using the token endpoint stored in the microsoft_account.token_endpoint system parameter when requesting a refresh token. Forward-Port-Of: odoo/odoo#246829 Forward-Port-Of: odoo/odoo#244371
This update resolves an issue preventing users in Belgium (BE) from correctly saving their VAT numbers during address updates on the online shop. The system was incorrectly modifying the VAT number, causing a 'VAT Number cannot be changed' error. This fix ensures accurate VAT data is saved for EU customers.
Original PR description
### Issue: EU vat fix cause address submission to fail. #### Steps to reproduce: 1- `base_vat` should be installed. 2- In portal contact, set the country to BE and VAT to `0477472701`. 3- Create an…
### Issue: EU vat fix cause address submission to fail. #### Steps to reproduce: 1- `base_vat` should be installed. 2- In portal contact, set the country to BE and VAT to `0477472701`. 3- Create an invoice for portal user. 4- Navigate to shop and add a product to cart, then checkout. 5- Edit address. 6- After filling, click on save address. Even though the VAT is not modified in form, and it is not modifiable the address fails to save with error: `Changing VAT Number is not allowed.` ### Cause: After address submission The vat is fixed in here: https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1396-L1406 This converts given vat `0477472701` to `BE0477472701`. Which makes `address_values['vat'] != partner_sudo.vat`: https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1472-L1482 opw-5437586 Forward-Port-Of: odoo/odoo#246850 Forward-Port-Of: odoo/odoo#245940
This update addresses an issue where users could incorrectly consolidate invoices for multiple orders within the Veri*Factu POS module. The fix now prevents this consolidation, ensuring accurate invoice generation and compliance. This change improves the reliability of the POS invoicing process.
Original PR description
Step to reproduce: - install `l10n_es_edi_verifactu_pos` and open POS - finalize 2 order with same customer (do not invoive it) - close session - go to pos orders, select both order and try to create…
Step to reproduce:
- install `l10n_es_edi_verifactu_pos` and open POS
- finalize 2 order with same customer (do not invoive it)
- close session
- go to pos orders, select both order and try to create consolidated invoice
Traceback:
```
File "/home/odoo/addons/l10n_es_edi_verifactu_pos/models/pos_order.py", line 293, in _prepare_invoice_vals
res['l10n_es_edi_verifactu_refund_reason'] = self.l10n_es_edi_verifactu_refund_reason
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/orm/fields.py", line 1365, in __get__
record.ensure_one()
```
Cause:
- `_prepare_invoice_vals` is written to accept only one order at time but it can contain multiple orders
Fix:
- we now do not allow invoice consolidation for Veri*Factu
- the consolidation flag has been made invisible so every order now has
to be invoiced individually.
opw-5379577
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239391This update fixes an issue where the description field in the calendar popover wasn't wrapping text properly, leading to truncated information. The team added the 'text-wrap' class to the calendar view, ensuring descriptions are displayed cleanly and completely within the popover. This improves the user experience by providing full access to calendar event details.
Original PR description
Changes done: - [x] `calendar`: Add `class="text-wrap"` in the description field of the calendar view to use it in the popover - [x] `web`: Define the appropriate class in the calendar popover field **Before** <img width="548" height="428" alt="antes" src="https://github.com/user-attachments/assets/77060ee6-30a1-47ed-8ba4-d5c2baa33fe3" /> **After** <img width="559" height="627" alt="despues" src="https://github.com/user-attachments/assets/cc9dfb47-3f98-4b5b-80c2-c3e5c15df0b0" /> @Tecnativa TT60670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246924
This update addresses an issue where a previously implemented tour was causing instability in nightly builds. The fix replaced the original tour with a more reliable version, resolving a recent set of errors and improving the overall stability of the MRP module.
Original PR description
Issue ----- The tour added in commit 6927265 was failing in nightly. The attempted fix in 246bf1d resolved the first problem but raised some new non-deterministic issues. ----- Errors 237956, 238469 & 238470
This update resolves an issue where attendance overlaps weren't being correctly accounted for in hourly accrual plans. The change adjusts how attendances are calculated to ensure accurate accrual based on actual worked time, even when attendance spans multiple days. This improves the reliability of time-off calculations.
Original PR description
### Issue: Attendances overlapping on two days are ignored for hourly accrual plans based on attendances. ### Steps to reproduce: - Install 'hr_holidays_attendance' - In Time Off > Configuration >…
### Issue: Attendances overlapping on two days are ignored for hourly accrual plans based on attendances. ### Steps to reproduce: - Install 'hr_holidays_attendance' - In Time Off > Configuration > Accrual Plan, create a new plan - Based on worked time - Hourly rule - Attendances as Source - In Management > Allocations, create an allocation for an employee using the new accrual plan - Create an Attendance for this employee in the period of the Accrual Plan - Check-in at 22pm for example - Check-out at 7am - Run the cron "Accrual Time Off: Updates the number of time off" - The Allocation ignores the worked time from the attendance ### Cause: `_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days. https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83 ### Solution: To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight. First we get all attendances overlapping with the day by changing the domain in the search. Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value. opw-5172669 Forward-Port-Of: odoo/odoo#246598 Forward-Port-Of: odoo/odoo#246270
This update resolves an issue where enabling tracking on custom HTML fields within invoices caused update failures. The change hides the 'Enable Ordered Tracking' option for these fields, preventing the error and ensuring data updates function correctly. This improves data integrity and reliability for invoice modifications.
Original PR description
From https://github.com/odoo/odoo/pull/241367#issuecomment-3711040501 Nothing prevent tracking from being enabled on HTML fields, but if it is enabled, updates of the field systematically fail. This commit avoids this error by hiding the "Enable Ordered Tracking" for HTML fields. Steps to reproduce: - Install sale and web_studio - Activate debug mode - Add a custom HTML field inside the invoice form view - Open the "More..." of the field (or go to Settings/Technical/Field) and go to the new field - Set "Enable Ordered Tracking" to 1 - Save - Go to an invoice and modify the new field - Save => An error was displayed task-5236436 Forward-Port-Of: odoo/odoo#242183
This update resolves a bug where images added to email templates were unexpectedly deleted upon saving. The issue stemmed from a problem with how the email editor tracked changes, leading to incorrect history management. The fix ensures images are correctly saved and re-added without being removed.
Original PR description
**Steps to reproduce:** - Install Email Marketing app - Create a new campaign with Subject and Recipients - Set plain text mail body - Add one image using /img or /image command - Save the template -…
**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime
**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.
This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`
**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.
related PR: https://github.com/odoo/odoo/pull/205594
opw-5245367
Forward-Port-Of: odoo/odoo#244396This update streamlines Odoo tests by disabling unnecessary device checks during testing. Previously, tests triggered frequent queries to detect device information, slowing down the testing process. This change improves test execution speed and efficiency without impacting core functionality.
Original PR description
In tests, when using `authenticate`, we create a session. When this session is retrieved (for example because we use `url_open`), we detect a new device and insert a log. The consequence is that a query is performed in many tests and that is not necessary. The fix consists of disabling the `res.device.log` feature by default in tests. task-5894825 Forward-Port-Of: odoo/odoo#246445
This update ensures that users are always notified when they are mentioned in a sub-channel, regardless of their membership status. Previously, users wouldn't see sub-channels where they were mentioned but weren't members. This fix prevents missed notifications and improves communication within teams.
Original PR description
Before this commit, when a user was mentioned in a sub-channel they were not member of, the sub-channel would not appear in their sidebar. This could lead to some missed pings. This commit fixes the issue by automatically adding mentioned users to the sub-channel, ensuring it is pinned to their sidebar. task-5233958 Forward-Port-Of: odoo/odoo#246423 Forward-Port-Of: odoo/odoo#237538
This update resolves an issue preventing sales users from creating orders with products having custom value attributes. The fix corrects a previous access restriction, ensuring sale users can properly utilize these attributes when generating sales orders. This improves the functionality for sales teams and customers.
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, adn 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
A recent error message appearing during payment processing for Avatax-enabled Point of Sale (POS) orders has been resolved. This fix removed a now-deprecated method used in the Avatax integration, ensuring smoother and more reliable transactions. This update addresses a technical issue impacting payment functionality.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#106135 Forward-Port-Of: odoo/enterprise#102101
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments continue to link to employees, even after they've been archived, improving data accuracy and reporting.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where subscriptions with zero-quantity lines resulted in incorrect invoice date calculations. The fix ensures that the next invoice date is properly determined, even when subscriptions include both positive and negative quantities, preventing invoices from being set to the subscription start date.
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#106226 Forward-Port-Of: odoo/enterprise#103705
A client reported issues processing payments via Bankgiro. This update corrects a typo and adjusts the order of financial data fields, ensuring Bankgiro payments now function correctly within the Odoo Enterprise system. This resolves a reported payment failure.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
This update ensures that freight costs are now accurately included in the customs documents generated for international deliveries. Previously, the system was omitting this crucial information, which could lead to incorrect customs declarations. This change aligns with SendCloud's 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#105543
This update corrects a bug in the salary configurator where the fuel card benefit would incorrectly appear enabled if no company car was selected. The fix ensures the field is properly initialized on initial load, preventing inconsistent data and ensuring the correct benefit options are displayed.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#97119
1 change
Resolved issues and error corrections
A client reported issues processing payments via Bankgiro accounts. This update corrects a typo and adjusts the order of financial data fields, ensuring Bankgiro payments now function correctly within the Odoo Enterprise system. This resolves a critical payment processing error.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
9 changes
Resolved issues and error corrections
A client reported issues processing payments via Bankgiro (Swedish bank giro). This update corrects a typo and adjusts the order of data fields in payment processing, ensuring Bankgiro payments now function correctly. This resolves a reported payment failure.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
This update resolves an issue where opening reports would cause a crash if a report action was triggered before the report data was fully loaded. The fix ensures that report actions can be reliably used during the report loading process, improving user experience and preventing unexpected errors.
Original PR description
When a report was loading if a reportAction was used and no report already was loaded before, it would crash. This happened because we tried to get the context from the data which were not yet loaded. To reproduce: - switch to debug mode (?debug=1) - add a 5s delay in _get_lines - when a report is opening, try to click on the settings cog that appear in debug mode Forward-Port-Of: odoo/enterprise#103636
This update prevents documents from automatically opening in a form view when accessed through various channels like direct links or systray notifications. Previously, users were unexpectedly directed to the document's form view, which has now been corrected to provide a smoother and more intuitive experience. This change improves usability and aligns with user expectations.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466 Forward-Port-Of: odoo/enterprise#106214 Forward-Port-Of: odoo/enterprise#104622
This update corrects an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a recent change that created a dummy item for role recognition, leading to an error when no item type matched. This fix ensures smooth PDF uploads for signature creation.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#106138This update resolves an issue where IoT reports generated from Point of Sale (PoS) were failing due to PoS using incorrect identifiers. The fix filters out reports that don't use integer IDs, specifically those using string UUIDs, as these are not needed for PDF report generation. This ensures reliable report printing.
Original PR description
Rendering IoT reports from PoS is failing because of PoS using string uuids as `res_ids`. As they are not required to render pdf reports, we filter them out. Forward-Port-Of: odoo/enterprise#106277
This update resolves a bug preventing users from validating barcode operations on stock pickings. The previous fix incorrectly blocked validation, and this change reverts to a reliable method using the JS framework's mutex mechanism to ensure sequential processing and prevent duplicate validation attempts. This ensures accurate stock tracking and avoids potential errors.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on…
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on Validate > Invalid operation - Scan a Serial number #### > You can not click on validate anymore ### Cause of the issue: The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since orm call returns an error the the call the validate method is interupted at this orm call and the line https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133 ### Fix: We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 : https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135 we have the guarantee that the records will not be validated twice. opw-5388297 Forward-Port-Of: odoo/enterprise#105542 Forward-Port-Of: odoo/enterprise#103835
This update fixes issues with how Odoo websites extract content, specifically addressing problems with robots.txt checks and content cleaning. The changes ensure accurate data collection from Odoo websites by refining noise removal and preventing errors in content extraction logic.
Original PR description
## Fix Summary - Include the instance's base URL in internal domains to allow bypassing robots.txt checks for sites that have no domain. - Fix the scraper's cleaning logic to prevent content containers deletion edge cases on Odoo websites. - Refine noise removal for Odoo websites (popups, cookie bars, etc.). Forward-Port-Of: odoo/enterprise#106237
This update resolves an issue where overtime approvals weren't consistently linked to attendance records. Previously, only one attendance was associated with overtime, leading to data inconsistencies. This fix ensures accurate tracking of overtime hours against all relevant attendance records, improving reporting and payroll accuracy.
Original PR description
…dance and overtime
STEP TO REPRODUCE:
------------------
1- Create an overtime rule with this configuration :
quantity rule differs from hours defined in the contract
2- Create two attendances on the same day (should be a worked day and should not be today)
one from 1AM-2PM
second from 2PM-undefined
3- Approve the overtime of the first attendance
REASON:
------
The link between overtime to attendance is not correctly done Attendance -> overtime (only the first attendance have a link with overtime) overtime, attendance -> the two will be returned
Forward-Port-Of: odoo/enterprise#106083
Forward-Port-Of: odoo/enterprise#105988This update fixes an issue where canceled refunds were incorrectly included in global invoices generated from Point of Sale orders. The fix filters out canceled refund lines during invoice generation, ensuring accurate reporting. This improves the reliability of financial data for Mexican VAT reporting (l10n_mx_edi_pos).
Original PR description
When generating global invoices for orders in the PoS, refund of those orders are also included in the global invoice. However, if the refund has been canceled, it should not be included in the global invoice. Steps to reproduce: ------------------- * Create a PoS order and validate it. * Go to the backend and create a refund for that order. * Cancel the refund. * Go to the PoS order list and select the original order * Click on "Generate Global Invoice" > Observation: The canceled refund is included in the global invoice. Why the fix: ------------ We simply filter out the canceled orders when searching for refunded order lines. opw-5492576 Forward-Port-Of: odoo/enterprise#106243 Forward-Port-Of: odoo/enterprise#105868
9 changes
Resolved issues and error corrections
This update resolves an issue where invoices generated from subscriptions with sections and subsections were missing the section line. The fix adjusts how the system identifies pending invoice lines, ensuring all sections and subsections are accurately reflected on the invoice. This improves the accuracy of subscription billing.
Original PR description
### Issue: Due to this issue, creating invoice from a SO that has a section with a subsection in the following line, will not include section line. #### Steps to reproduce: 1- Create a SO 2- Add section 3- Add subsection 4- Add line with a product 5- Confirm the SO and create an invoice Expected invoice lines: section, subsection, product line Current invoice lines: subsection, product line ### Cause: This is due to only considering latest section as pending section in `_get_invoiceable_lines`: https://github.com/odoo/enterprise/blob/b748b5d7e1b74657ac4c69d6843821cf30505b99/sale_subscription/models/sale_order.py#L1285-L1308 opw-5450365
This update resolves a payment error that occurred when using Avatax with the Point of Sale (POS) module. The issue stemmed from an outdated method that was no longer supported. Removing this method ensures smoother payment processing and a better user experience.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#106135 Forward-Port-Of: odoo/enterprise#102101
This update resolves an issue where a reordering rule would incorrectly attempt to update a manufacturing order (MO) that had been locked due to a quality check. The fix ensures that new MOs are created when a reordering rule is triggered after a quality point is completed, preventing errors and maintaining accurate inventory tracking. This 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#104070 Forward-Port-Of: odoo/enterprise#101313
A client reported issues processing payments via Bankgiro (Swedish bank giro). This update corrects a typo and adjusts the order of financial data fields, ensuring Bankgiro payments now process successfully. This resolves a critical payment processing error.
Original PR description
After PR: https://github.com/odoo/enterprise/pull/104777 The client reported that payment with bankgiro account doesn't works. Here are the problems found: - Typo : Should be `RfrdDocAmt` instead of `RfdDocAmt` - RfrdDocAmt should be inserted before CdtrRefInf - CdtNoteAmt should be before RmtdAmt opw-5427505 Forward-Port-Of: odoo/enterprise#106272
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments accurately reflect the current employee status, preventing data inconsistencies and improving reporting accuracy. This change maintains data integrity for payroll records.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a previous change that created a dummy item to identify roles, leading to an error when no item type was found. This fix ensures a smooth sign upload process.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#106138This update resolves a problem preventing users from viewing the package status for Lazada orders within picking and sale orders. The fix grants necessary access to the `lazada.order.item` model, which was previously restricted to 'Sales Administrator' users. This ensures all users can see the correct Lazada order information.
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.
This update fixes an error in the calculation of secondary contract payslips for Kenyan companies. The issue stemmed from a missing variable, which has now been corrected to ensure accurate tax and deduction calculations for employees on secondary contracts. This ensures payroll compliance for our Kenyan clients.
Original PR description
Steps to reproduce: With a Kenyan company, create an employee. Check the "Secondary Contract" on the employee form view. Create a payslip and compute. There is an error in the payslip computation. Cause: There is an undefined variable "remaining_gross". Fix: Replace it by the total taxable gross. Task: 5462310 Forward-Port-Of: odoo/enterprise#106055 Forward-Port-Of: odoo/enterprise#103229
This update resolves an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas. The fix involves repositioning a text truncation element, resulting in a cleaner and more readable statement line display for users. This improves the overall user experience.
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#105674
16 changes
Resolved issues and error corrections
This update prevents users from creating duplicate attendance records when network connections are unstable. The fix introduces a timeout for location tracking and a system to avoid multiple check-in/out clicks, ensuring accurate attendance data and a smoother user experience. It addresses a previous issue where prolonged network interruptions led to incorrect record creation.
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#244477
This update fixes a problem where automated tests relied on specific demo data, causing inconsistent results. The change ensures tests always use a consistent partner for searching, improving the reliability of our automated testing process. This enhances the overall stability and predictability of our website sales functionality.
Original PR description
As part of the forward part for [1] the shop mail tour was updated because the new demo partner was earlier alphabetically than the partner generated for the test, and tests run with demo data for CI in this version. The test should create a partner that will appear first in the m2o selection regardless of whether demo data is installed. [1]: 549708965924b17403ef7c8e6a6d5bc43af460c3 runbot-238406 Forward-Port-Of: odoo/odoo#245753
This update resolves a test failure in the restaurant POS booking process. The fix replaces a method used for general loading with one specifically designed to wait for RPC requests, ensuring the tour accurately reflects the system's behavior when booking and releasing tables. This improves the reliability of the test and the overall booking experience.
Original PR description
Fix failing tour `test_book_and_release_table` by replacing `waitForLoading`, which is intended for POS loading, with `waitRequest` to properly wait for RPC requests. Error-227652 Task-5897383
This update resolves an issue where users could select product variants with excluded options in the Point of Sale system. The fix ensures that selected attributes are properly considered when determining if a variant is allowed, preventing incorrect product selections. This improves the accuracy and reliability of the POS experience.
Original PR description
Step to reproduce: - for a product A, have 3 attributes, legs , color and extra options (type: multi) - for a color attribure values (eg red) exclude one option of 'extra options' - open pos and select this product - select "red" and excluded option Observation: - you are able to select this variant but shouldn't as it is excluded Fix: - previously, we do not considered selected attributes for `multi` attributes in `getVariantAttributeValueIds` - we now compute 'exclusion' for all product once and then use it at runtime, to qualify if variant is allowed or not. opw-5220427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where enabling tracking on custom HTML fields within invoices caused update failures. The change hides the 'Enable Ordered Tracking' option for these fields, preventing the error and ensuring data updates function correctly. This improves data integrity and reliability for invoice modifications.
Original PR description
From https://github.com/odoo/odoo/pull/241367#issuecomment-3711040501 Nothing prevent tracking from being enabled on HTML fields, but if it is enabled, updates of the field systematically fail. This commit avoids this error by hiding the "Enable Ordered Tracking" for HTML fields. Steps to reproduce: - Install sale and web_studio - Activate debug mode - Add a custom HTML field inside the invoice form view - Open the "More..." of the field (or go to Settings/Technical/Field) and go to the new field - Set "Enable Ordered Tracking" to 1 - Save - Go to an invoice and modify the new field - Save => An error was displayed task-5236436 Forward-Port-Of: odoo/odoo#242183
This update resolves a bug where the timer stopped appearing for survey participants after submitting their answers in live sessions. The fix ensures the timer correctly displays for the duration of the live session, regardless of whether the participant finishes or the session ends, improving the participant experience.
Original PR description
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a…
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a Survey with two questions of any type. Set some Question Time Limit on both. Create Live Session for that Survey. Access Live Session as a participant. Start Survey as the host. The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question. Bug: timer for the second question does not appear to the participant. Desired behavior after PR is merged: Fix: The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function. Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function. This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress` and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'` Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241086
This update fixes an issue where the toolbar remained visible on mobile devices when the side menu or a popover was open, obstructing the user's view. Now, the toolbar automatically hides when a popover or sidebar is active, providing a cleaner and more intuitive mobile experience. This enhancement improves usability and accessibility.
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
This update fixes an issue where vendor bill labels on payable lines were not correctly populated when the Payment Reference was empty. Now, the payable line label automatically displays the Bill Reference when no Payment Reference is provided, and updates accordingly when the Payment Reference is changed. This ensures accurate labeling of vendor bills for better reporting and reconciliation.
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
This update fixes an issue where user information (name, email, etc.) entered as global questions during event registration wasn't being saved to the registration record. Now, this data is correctly captured and stored, improving the accuracy of event registration data. This ensures better reporting and management of event attendees.
Original PR description
Before this commit: =================== - When an event uses a user's fields (name, email, phone, company_name) as a global questions (once per order), these values were not saved on the event registration record. After this commit: ================== - User fields defined as global questions are now correctly populated on the event registration record. Task: 5462923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update replaces the SFU (Server-Side File Upload) bundle with version 1.3.3, addressing a technical update to improve the performance and stability of file uploads within Odoo. This change ensures continued optimal functionality for users uploading and managing files.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#244971
This update allows users to reset Vendor Bills (e-invoices) received from ANAF to a draft state, even if they are currently in an 'EDI' processing stage. This change is necessary due to a recent update consolidating the e-invoice functionality into the broader 'l10n_ro_edi' module, ensuring proper processing of e-invoices. It improves the flexibility for users to manage their invoices.
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#246697
This update resolves an issue in the account_edi_ubl_cii module related to how the 'LineExtensionAmount' is calculated. The change introduces a new value to account for global tax rounding differences, ensuring accurate untaxed and total amounts in generated invoices. This prevents potential discrepancies and maintains data consistency.
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
This update resolves an issue preventing legal validation of the annual VAT report for Luxembourg companies. The fix adds missing required fields to the XML export, ensuring compliance with tax reporting regulations. This ensures accurate and legally compliant VAT reports are generated.
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 ### 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 ### Note: This PR is related to the 17.0 PR: https://github.com/odoo/enterprise/pull/105143 opw-5119920
This update resolves an issue where the POS ID wasn't being correctly transmitted to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, improving the reliability of the fiscal data reporting process. Additionally, a security enhancement restricts blackbox device selection to the Fiscal Data Module in POS configuration settings.
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
This update resolves an issue where tickets in 'folded' (closed) stages were incorrectly displayed in the helpdesk email plugin. The fix ensures that closed tickets are filtered out, preventing them from appearing in the plugin's results and improving the user experience. This ensures users only see active tickets.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477
This update resolves a problem with Indian GST reports where test cases were failing due to a recent change in how payable lines are labeled. The test cases have been updated to now correctly account for the new label format that includes the bill reference, 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
10 changes
Resolved issues and error corrections
This update fixes a tax code error for 0% EU S transactions in Italy. The code was incorrectly assigned based on whether the transaction was for goods or services. This change ensures accurate tax calculations for intra-community supplies, aligning with Italian tax regulations.
Original PR description
In Italy, the code depends strictly on whether the transaction is for Goods or Services. N3.2 is for Intra-community supply of GOODS (Cessioni Intracomunitarie di beni) N2.1 is for Intra-community supply of SERVICES (Prestazioni di Servizi) This commit fixes the exoneration code on the 0% EU S tax from N3.2 to N2.1. task-5870894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where closing a Point of Sale (POS) session would fail due to incorrect SEPA payment processing. The fix prevents the POS from attempting to process SEPA direct debit payments when a customer's partner and bank account information isn't provided, ensuring smoother session closures.
Original PR description
SEPA expects a partner and a bank account. But the POS allows the user to sell to generic customers without a partner id or bank account. When SEPA direct debit is selected as the first incoming/outgoint payment method for the journal, closing the POS session will try to pos a SEPA payment which will fail when no partner is selected for the payment. We've identified this before and excluded SEPA credit transfer from point of sales for issues with closing sessions, but the issue is still happening with SEPA direct debit. This fix will exclude the SEPA DD from the list of payment methods the POS is trying to use to post the transactions. Task-[5358590](https://www.odoo.com/odoo/project/1737/tasks/5358590) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a duplicate skill was incorrectly added to an employee's resume after a validation error occurred during skill selection. The fix ensures that changes to the virtual record are discarded when a validation error is triggered, preventing unintended skill additions and maintaining data integrity.
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
This update resolves an issue preventing portal users from downloading slides documents when using a CDN. Previously, a login requirement on the CDN blocked access. The fix adds a new route to ensure slides can be accessed via CDN, aligning with documented CDN configurations and expected public content availability.
Original PR description
Currently if you have a cdn configured to the route '/web/content' and you try to download files in a e-learning course as a portal user, you won't be able to. You get a not found error instead since you are not logged in in the cdn server, so no access to the resource. Given that configuring a cdn to this route is in our documentation and that other contents on that route are expected to be public (so available trough cdn) this is unexpected behaviour. This adds a route to slides that calls the same method as the old one, so that you can cdn that route and this will still work opw-4918546
This update fixes an error in the calculation of VAT payable or refundable when generating Welsh tax returns. The previous formula was incorrect, leading to inaccurate reporting. The change updates the formula to accurately reflect the difference between output and input VAT, ensuring 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
This update resolves a problem where credit notes with early payment discounts triggered schematron errors during Peppol validation. The fix corrects a calculation error within the system that was incorrectly increasing taxable amounts instead of decreasing them, aligning with Peppol rules. This ensures credit notes with discounts are correctly validated and submitted.
Original PR description
Submitting a credit note with an early payment discount fails with schematron errors `BR-CO-17` and `BR-S-09`. The issue occurs because `_get_early_payment_discount_grouped_by_tax_rate` returns negative values for credit notes, which is not accepted by the Peppol validation rules since we will increase the `TaxableAmount` instead of decreasing them. Steps to reproduce: - Create a payment term with a 2% discount (always) - Create a credit note using this payment term - Submit the document to Peppol - Observe the schematron validation error opw-5357180 opw-5499252
This update fixes an issue where text in the checkout card was difficult to read on mobile devices when a dark website background was used. The change adjusts color contrast for muted text, ensuring all amounts (Subtotal, Taxes, Total) are clearly visible regardless of the background color. This improves the user experience and prevents potential confusion during the checkout process.
Original PR description
Prior to this commit, when a dark background color was defined, some text elements in the checkout card were not readable on mobile. Steps to reproduce: - Switch the website background to a dark color. - Add a product to the cart. - Go to the cart checkout page. - Switch to mobile view. - Observe the text next to the amounts (Subtotal, Taxes, Total) inside the cart summary card. This commit adjusts the colors of muted text inside the checkout card to ensure sufficient contrast, regardless of the background color. task-5881568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when deleting documents linked to sign request templates. The fix prevents the deletion of these documents, ensuring the sign template functionality continues to operate smoothly and avoids data inconsistencies. This improves stability and prevents potential disruptions to the sign process.
Original PR description
Currently an error was generated when autovalume _gc_clear_bin tries to delete documents from trash. Stack Trace: ``` ForeignKeyViolation: update or delete on table "sign_template" violates foreign…
Currently an error was generated when autovalume _gc_clear_bin tries to delete documents from trash.
Stack Trace:
```
ForeignKeyViolation: update or delete on table "sign_template" violates foreign key constraint "sign_request_template_id_fkey" on table "sign_request"
DETAIL: Key (id)=(13) is still referenced from table "sign_request".
File "odoo/addons/base/models/ir_autovacuum.py", line 38, in _run_vacuum_cleaner
func(model)
File "home/odoo/src/enterprise/saas-17.2/documents/models/documents_document.py", line 739, in _gc_clear_bin
], limit=1000).unlink()
File "home/odoo/src/enterprise/saas-17.2/documents/models/documents_document.py", line 727, in unlink
removable_attachments.unlink()
File "odoo/addons/base/models/ir_attachment.py", line 612, in unlink
res = super(IrAttachment, self).unlink()
File "odoo/models.py", line 4286, in unlink
cr.execute(SQL(
File "odoo/sql_db.py", line 346, in execute
res = self._obj.execute(query, params)
```
This is because '_gc_clear_bin' tries to delete attachments that are related to the sign request template and it generates a foreign key violation error.
This commit fixed the above issue by preventing the deletion of the documents that are related to the templates.
sentry-5565143437This update resolves an issue preventing the legal validation of the annual VAT report for Luxembourg companies. 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
This update fixes an issue in the French Profit & Loss report where accounts 65 were incorrectly categorized. They have now been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of financial data for French users.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018