Daily updates from Odoo
Wednesday, April 23, 2025
42 changes · 18.0
Resolved issues and error corrections
The POS product configurator now shows the correct on-hand quantity when staff switch between product variants, including products with attributes that do not create separate variants. This helps cashiers see accurate availability and avoid selling based on the wrong stock level.
Original PR description
Prior to this fix, the product configurator did not display the on-hand quantities of product variants as shown on the product page, when an attribute’s variant creation was set to 'never'. Steps to reproduce: 1. Create a product with variants. 2. Add multiple attributes and values. 3. Set the variant creation to 'never' for one attribute. 4. Add stock for the product and make it available in POS. 5. Open POS, select the product, and switch between variants. The quantity displayed was only for one variant. This commit ensures that the correct on-hand quantity is shown for each selected variant in POS. opw-4685882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer records now correctly show lot and serial numbers for products delivered through dropshipping. This gives sales and support teams a more complete view of what tracked products each customer received, regardless of delivery route.
Original PR description
**Current behavior:** In the *Contacts* application, with a partner record open, you can view the lots associated with that customer (used in orders for that partner(?)). Lots that were delivered to that partner via dropship transfers do not appear here. **Expected behavior:** Dropship lots are there. **Steps to reproduce:** 1. Create a dropship product (route, vendor, ..) tracked by lot 2. Sell 1 of that product to some partner, confirm the ensuing purchase & dropship transfer 3. Go to *Contact* -> open the customer -> `Lot/Serial Numbers` smart button -> lot is not there **Cause of the issue:** `StockLotReport` only looks for `outgoing` (delivery) picking type pickings. **Fix:** Override the join on `PickingType` and `ResPartner` such that dropship pickings can also be collected here. opw-4559129
This fixes an issue where a point of sale session could trap users if no admin employees were configured. Users can now continue managing or closing the session instead of being blocked, reducing operational disruption at checkout.
Original PR description
Before this commit, when opening a pos without admin employees set, the user was blocked into its open session without being able to close it. task-id: 4730841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where non-manager cashiers were blocked from changing product prices even when the business had not enabled price restrictions. It also makes cashier role handling consistent whether the employee POS module is installed or not, reducing unexpected checkout behavior.
Original PR description
Before this commit, non-manager cashiers were unable to modify product prices even when price control was not enabled, which was not the intended behavior. Additionally, when `pos_hr` was not installed, the `get_cashier` method returned the user object with a `role` attribute. However, when `pos_hr` was installed, the returned cashier used `_role`, leading to inconsistencies and broken functionality depending on the module's presence. opw-4726098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where using the Backend button on a second device after a shared POS session was already closed could show a missing record error. This makes multi-device POS session closing smoother and avoids confusing errors for store staff.
Original PR description
Before this commit, if a POS session was open on two devices and closed on one, a new session would be automatically created and both devices would switch to it. However, if the "Backend" button was clicked on one device—removing the session—then clicking "Backend" on the second device would trigger a missing record error, since the session was already deleted. opw-4709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Tags filter in the website shop sidebar now behaves like the other filters, allowing shoppers to collapse or expand it. Its spacing was also adjusted for a more consistent and polished shopping page layout.
Original PR description
<b>Steps to reproduce:</b> 1. Go to website > Shop > Scroll to tags filter (If tags aren't visible in the sidebar, go to Sales > Configuration > Product Tags > create tags) 2. Notice that Tags filter cannot be collapsed unlike other filters 3. Observe that margins and spacing don't match other filter components <b>Issue:</b> The "Tags" filter on the website shop sidebar lacked a collapsible header, unlike other filters such as "Price Range". This caused UI inconsistency. Additionally, the margin and spacing did not align visually with other filter components. <b>Solution:</b> Applied Bootstrap collapse classes to the Tags filter to enable accordion-style toggling. Adjusted margin and structure to match the layout of other sidebar filters for visual consistency. opw-4702463
This update adjusts an internal web test so it remains reliable with newer Chrome versions. It does not change the user experience, but helps keep automated quality checks stable and trustworthy.
Original PR description
Since Chrome 135, the "Keep scrollTop when loading records with load more" unit test fails with a scrolling value way higher than expected. In practice, the scroll in the test goes down to the "Load more" button after it has been clicked instead of keeping scroll to the same value as before the loading of the "more" items. Weirdly, it doesn't look to be an actual issue when performed by the user, but only in the test suite. This commit works around that issue by using `element.click()` followed by waiting for an animation frame instead of using `contains().click()`, because... well, the two helpers behave slightly differently. 🤷
This fix improves how website mega menus appear when using vertical navigation layouts such as sidebars or hamburger menus. It prevents menu items from overlapping, making navigation cleaner and easier for visitors to use.
Original PR description
Steps to Reproduce : 1. Add a Mega Menu through Menu Editor 2. Switch the header template to Sidebar 3. Once done --> Open the mega menu; it will overlap with one another. Issue: Vertically aligned navbars like the sidebar and hamburger navbar, have styling issues with the mega menu. The mega menu is designed according to the full width of the screen, which leads to not look good mega menu when opened in a limited-spaced navbar. Fix: This commit adds the style particularly to vertical navbars, such that the styling of the mega menu is proper even in these navbars. Task: 4684074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that prevented users from creating a product from a sales quotation when the Units of Measure setting was not enabled. The system now falls back to the normal unit setup instead of using an empty hidden value, so product creation works as expected.
Original PR description
Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure"…
Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure" option in the settings. - Create a new quotation. - In the sale order line, enable the Product Variant field. - Try to create a new “product.product” **Problem:** A validation Error is triggered: ``` The operation cannot be completed - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Product (product.template) Field: Unit of Measure (uom_id) ``` **Explanation:** This happens because a default value for the UoM is passed through the context. As a result, we skip the computation of “uom_id”: https://github.com/odoo/odoo/blob/2b38c1f446441e04f8d85125a9ec6562d13b7ce8/addons/product/models/product_template.py#L27 However, this default is derived from the field “product_uom” that is present in the view but restricted to users in the "uom.group_uom" group. If the current user doesn't belong to this group (if you don't enable the param in the settings), the field is hidden and its value is empty, causing the default to be set to False. https://github.com/odoo/odoo/blob/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4/addons/sale/views/sale_order_views.xml#L537 **Solution:** Force the computation of “uom_id” by removing “default_uom_id” from the context when its value is “False”. opw-4717913
Fixed an issue where validating a Point of Sale order could fail when the order came from a different PoS setup and the selected payment method was unavailable there. This helps cashiers complete affected orders without being blocked by a configuration mismatch.
Original PR description
Before this commit, validating an order that belonged to a different PoS configuration could result in an error if the selected payment method was not available in the current configuration. This prevented the order from being successfully validated. opw-4687658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering point of sale flow now handles combo products that include items with multiple selectable options. This prevents customers from hitting an error while completing an order, reducing checkout disruption.
Original PR description
Before this commit, if a combo product contains a product with multi options attribute, you will have an error when proceeding the order. opw-4637372 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now treats employees with flexible working hours consistently by applying the standard calendar before scheduling calculations. This prevents meeting creation from failing when attendees include both flexible-schedule employees and employees using the standard 40-hour calendar.
Original PR description
## Issue When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a…
## Issue
When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a `KeyError`:
```python
File "/home/odoo/src/odoo/18.0/addons/hr_calendar/models/res_partner.py", line 78, in _get_schedule
calendar_interval = interval_by_calendar[calendar][employee.resource_id.id]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: <number>
```
## Root Cause
Odoo uses the Standard 40 hours/week calendar (resource.resource_calendar_std) as a fallback for flexible (unset) calendars. However, when grouping resources by their calendars, resources without a calendar are included in a separate group.
Later, when Odoo computes work intervals per calendar, it assigns the default calendar to resource.resource(). If another user already uses the same calendar, the group duplication results in one being overwritten during iteration—causing the KeyError.
## Fix
Before grouping resources by calendar, explicitly assign the default calendar (resource.resource_calendar_std) to any resource that lacks a calendar. This ensures all resources are grouped correctly, avoiding duplication and key errors.
## Impacted versions:
18.0 and later
## Steps to Reproduce
### Pre-requisites:
- Install `hr_contract`, `calendar` apps.
### Steps:
1. Create **Employee 1**:
- Set **Working hours** to **Flexible** (unset)
- Create a **Contract**:
- Set **Working hours** to **Flexible** (unset)
2. Create **Employee 2**:
- Set **Working hours** to **Standard 40 hours/week**
- Create a **Contract**:
- Set **Working hours** to **Standard 40 hours/week**
- Ensure the XML ID is `resource.resource_calendar_std`
3. Open the **Calendar** app.
4. Create a **new Event**.
5. Add both employees as **attendees**.
## Current Behavior
The system raises a `KeyError` and does not allow the event to be saved.
## Expected Behavior
The event is saved successfully with both attendees.
### Task
OPW-[4699028](https://www.odoo.com/odoo/my-tasks/4699028)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update speeds up a point of sale upgrade step that could take a long time for businesses with large sales histories. It reduces upgrade delays by replacing many repeated database operations with a more efficient batched approach.
Original PR description
The original script is slow on large tables (more than 100000 records) because of multiple sql queries. We reworked it so it's now one query exploded on chunks which speeds it up a lot. | | **Chunk…
The original script is slow on large tables (more than 100000 records) because of multiple sql queries. We reworked it so it's now one query exploded on chunks which speeds it up a lot. | | **Chunk size** | **Table** | **Records** | **Total time (hh:mm:ss.)** | **Time/1000 records** | |------------------|----------------|----------------|-------------|----------------------------|-----------------------| | Multiple Queries | 100000 | pos_order | 354881 | 0:41:47.438305 | 0:00:06.269000 | | Multiple Queries | 2000 | pos_order | 354881 | 0:02:11.708014 | 0:00:00.371000 | | Single Query | 100000 | pos_order | 354881 | 0:00:14.724486 | 0:00:00.041000 | | Exploded Query | 100000 | pos_order | 354881 | 0:00:07.937863 | 0:00:00.022367 | | Multiple Queries | 2000 | pos_order_line | 819189 | 0:07:39.805373 | 0:00:00.561000 | | Single Query | 100000 | pos_order_line | 819189 | 0:00:29.666529 | 0:00:00.036000 | | Exploded Query | 100000 | pos_order_line | 819189 | 0:00:12.124260 | 0:00:00.014800 | | Multiple Queries | 2000 | pos_payment | 365725 | 0:01:52.806145 | 0:00:00.308000 | | Single Query | 100000 | pos_payment | 365725 | 0:00:10.894065 | 0:00:00.030000 | | Exploded Query | 100000 | pos_payment | 365725 | 0:00:04.670350 | 0:00:00.012770 | 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
Messages sent from eLearning courses or slides will no longer automatically include all attendees as recipients. This prevents large unintended email blasts and gives the sender full control over who is notified.
Original PR description
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses. This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed. To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields linked to customers. In the case of the above models, we don't want to send a message to all the attendees (they were stored in partner_ids which is the default field read). Thus by returning an empty list we block the computation of suggested_recipients and default_recipients. Letting full control to the user sending the email which people to notify. task-4736015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
The unrealized currency gains and losses report now creates adjustment entries with the correct debit and credit amounts when the selected expense account has a default tax. This prevents zero-value accounting entries and helps keep foreign currency revaluations accurate.
Original PR description
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration /…
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add a default tax to "Expenses" account - Create an invoice: * Customer: [any] * Currency: [EUR] (i.e. the foreign currency) * Invoice Date: [a date in the past where the currency rate is different than today] * Invoice Lines: [any] - Confirm the invoice - Go to "Accounting / Reporting / Management / Unrealized Currency Gains/Losses" - Set date filter to "Today" - If there is no adjustement to do, check if the following message is displayed: "You are using custom exchange rates. => Reset to Odoo’s Rate" If it's the case, reset to Odoo's rate (i.e. Today's rate) - Click on "Adjustement Entry" button: * Journal: Miscellaneous Operations * Expense Account: Expenses * Income Account: [any] - Create Entry **Issue:** The values (debit/credit) of the created entry are 0, which is not the case when there is no default tax on the expense account. **Cause:** "_sync_dynamic_lines" is executed on the created entry. If a default tax is set on the expense account, "_sync_tax_lines" is also executed. As only debit and credit values are set on the invoice lines of the entry (neither balance nor amount_currency), the sync method messes up with the value of debit and credit, resetting them to 0 (via multiple recompute). **Solution:** Skip invoice sync. The values computed in "Multicurrency Revaluation Wizard" should be the ones that are used. opw-4664255
This fixes an intermittent automated test failure by adding wait steps before interacting with the PDF signing area. The change helps keep Belgian payroll contract tests reliable without changing the user-facing payroll workflow.
Original PR description
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the
setTimeout(() => this.initializeIframe(), 1);
interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.
I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...
https://runbot.odoo.com/odoo/error/181583Updating pivot settings in spreadsheets no longer removes the sorting users applied to pivot values. This preserves the expected spreadsheet view after changes such as adjusting filters or domains, reducing repeated manual work.
Original PR description
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934
The sales journal dashboard now shows the remaining amount due for partially paid invoices when 3-way matching is installed, instead of showing the original full invoice total. This helps users rely on the Unpaid and Late dashboard figures for accurate cash collection follow-up.
Original PR description
Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed. Steps to reproduce: - Install account_3way_match - Create and partially pay an invoice - Go to the dashboard - The displayed amount should reflect the residual, but it shows the full amount This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute `amount_total` and `amount_total_company`. opw-4731478
The Luxembourg payroll module no longer tries to load missing setup files during its scheduled payroll data update. This prevents an error when administrators run the update action, improving reliability without changing payroll behavior.
Original PR description
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action.
**Steps to produce:**
- Install `l10n_lu_hr_payroll` module.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.
`ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'`
Here, `_get_data_files_to_update` method at [1] attempts to load the `hr_salary_rule_data.xml` and `hr_gratification_rule_data.xml` files, which are not present in the codebase.
[1] - https://github.com/odoo/enterprise/blob/809fda39b439edf6259ade445e396e722c1bb53a/l10n_lu_hr_payroll/models/hr_payslip.py#L219-L220
This commit ensures the removal of invalid file references to prevent errors when executing the scheduled action.
Sentry - 6316151728The Belgian payroll DMFA export now correctly accepts ONSS numbers that include formatting such as dots or dashes. This prevents report generation errors and allows companies to produce the required XML payroll report without manually removing special characters.
Original PR description
steps to reproduce: - set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes) - go to Payroll / Reporting / DMFA - create a new DMFA and generate an XML report - it should throw error saying expected `int` (since ONSS is a Char field) fix: - while performing the export, filtered the digits only from these fields task-4502689
This update adjusts a Helpdesk portal test so it waits for the final expected result instead of ending while background page content may still be loading. This reduces false test failures and helps keep Helpdesk releases more stable without changing customer-facing functionality.
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748
Miscellaneous changes
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for
Original PR description
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for searching by Name. Task - 4574162 Forward-Port-Of: odoo/odoo#198461
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties
Original PR description
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties values again. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3#diff-89ec9296feb48614f91829b8b732dca614359831967fa65a2126d6fe68c84450 Forward-Port-Of: odoo/odoo#206975 Forward-Port-Of: odoo/odoo#206824
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and r
Original PR description
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206841
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR
Original PR description
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204626 Forward-Port-Of: odoo/odoo#176765
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier
Original PR description
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier than expected. Reason: The check_in date was incorrect because it was using UTC instead of the employee's local time zone. Fix: Converted check_in to the employee's local time zone before extracting the date. issue:https://github.com/odoo/odoo/issues/169592 task-4320477 Forward-Port-Of: odoo/odoo#206713 Forward-Port-Of: odoo/odoo#192434
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#205940
Original PR description
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#205940
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206811
Original PR description
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206811
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206409
Original PR description
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206409 Forward-Port-Of: odoo/odoo#187233
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10 units of P1 - Confirm the MO - Split the MO into two: - This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002” - For the first MO (WH-MO-001): - Set Quantity Produced to 1. - Validate it and choose to create a backorder. Problem: - The b
Original PR description
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10…
Steps to reproduce the issue:
- Create a storable product “P1”
- Create a Bill of Materials:
- Finished product: 1 unit of P1
- Components:
- 1 unit of C1
- Create a manufacturing order to produce 10 units of P1
- Confirm the MO
- Split the MO into two:
- This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002”
- For the first MO (WH-MO-001):
- Set Quantity Produced to 1.
- Validate it and choose to create a backorder.
Problem:
- The backorder is incorrectly named “WH-MO-001-003” instead of the expected WH-MO-003.
- Additionally, the original MO is renamed “WH-MO-001-001”, which is unexpected.
- However, if you perform the same steps on the second MO (WH-MO-002), the backorder is correctly named “WH-MO-003”, and the original name remains unchanged.
Root cause:
- When the original MO is first split, each resulting MO receives a backorder sequence:
- First split MO (WH-MO-001): backorder_sequence = 1
- Second split MO (WH-MO-002): backorder_sequence = 2
- When creating a backorder from an MO with backorder_sequence = 1, the following logic is triggered:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1844
- Since the condition if backorder_sequence > 1 is false for WH-MO-001:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1782
- So the name + seq_back is added:
https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1784
opw-4686959
Forward-Port-Of: odoo/odoo#205760In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
Original PR description
In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
Original PR description
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
Original PR description
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Original PR description
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
Original PR description
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Original PR description
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Original PR description
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Original PR description
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
Original PR description
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr
Original PR description
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26 but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0 https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48 ### Fix: If we have a fsm_task we can fallback on its order_id if order_id is false. opw-4712922 Forward-Port-Of: odoo/enterprise#83396