Daily updates from Odoo
Monday, December 1, 2025
42 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain service products. This change ensures that the allocated hours on tasks are accurately set to match the quantity of the corresponding sales order line, improving the accuracy of time tracking.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update resolves an issue that prevented users from creating bank statements when the chart of accounts wasn't properly configured. The fix ensures the system only attempts to create bank statements when related accounts are present, preventing a syntax error and improving stability.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053 Forward-Port-Of: odoo/enterprise#100459
This update resolves an issue where the DIOT tax report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting reliability. This change addresses a technical bug related to data processing within the DIOT reporting module.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100843 Forward-Port-Of: odoo/enterprise#96529
A test case in the account module was failing in the community version due to a difference in payment state handling between community and enterprise. This fix moved the test case to the enterprise environment to ensure it aligns with the expected behavior and resolves the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/odoo#237933 Forward-Port-Of: odoo/odoo#237881
A test case in the Odoo Enterprise module was failing due to differences in payment state handling between the community and enterprise versions. This change moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/enterprise#100865 Forward-Port-Of: odoo/enterprise#100834
This update corrects a bug where 'Cash on Delivery' was incorrectly offered for orders with 'In-Store' delivery. The fix ensures that 'Cash on Delivery' is only available when the delivery type is 'Pick Up In Store', streamlining the checkout process for customers and preventing confusion. This resolves an issue reported by our team.
Original PR description
### Issue: In this issue, `allow_cash_on_delivery` is allowed when delivery type is pick up in store. #### Steps to reproduce: 1. Create a `fixed_price` delivery method 2. Check `Cash on delivery` checkbox 3. Change the delivery type to `in_store` and configure it 4. Activate cash on delivery payment method 5. Choose a storable ptoduct on the /shop, checkout with a created dm and proceed to payment 6. Observe that you see the 'cash on delivery' pm for pickup in store. Currently, `allow_cash_on_delivery` is invisible when `delivery_type` is set to `in_store`. However, it's not set to `False`, once the type is changed to `in_store`. opw-5258535 Forward-Port-Of: odoo/odoo#235434
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and reduces potential errors.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
This update prevents a critical error that occurred when employees without a working schedule attempted to view their time off in the Gantt view. The fix ensures the system gracefully handles missing schedule data, improving the user experience and preventing data display issues. This resolves a technical issue impacting time off reporting.
Original PR description
Currently, an error occurs when an employee has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_gantt` with demo data. 2. Remove the **Working Hours**(Payroll section) of **Marc Demo**. 3. Navigate to: Time off > Overview. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/db049f42ad4c2c291b2d64a9e637cd2292c280e8/hr_holidays_gantt/models/hr_leave.py#L204 sentry-7017326141
This update fixes a previous issue where document fields weren't visible on the employee form. A new 'Documents' section has been added to the Personal tab, allowing HR staff to easily manage and view employee documents within the system. This improves data accessibility and streamlines HR workflows.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982
This update fixes a previous issue where important document fields for employees were missing from their profile views. A new 'Documents' section has been added to the employee form, providing a centralized location to manage and view employee-related documents. This improves data accessibility and streamlines HR processes.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982
This update resolves a regression issue in the Egyptian payroll tests. Previously, the tests were designed to project allocations for 2025 and failed when the system's date moved beyond that year. This fix ensures the tests remain reliable by adapting to future date ranges, preventing unexpected failures.
Original PR description
The Egyptian payroll regression tests built allocations for 2025 and relied on the runtime date, so they start failing once the global fake date advances beyond that year (e.g., 2026). task-5215779
This update fixes a bug preventing negative sales amounts (like credit notes) from appearing in the exported XBRL report for the Dutch EC Sales List. Previously, only positive amounts were included, leading to incomplete reporting. This change ensures all sales figures, including negative values, are accurately reflected in the report.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100669 Forward-Port-Of: odoo/enterprise#100009
This update fixes an issue where changes made within the Colibri interaction framework weren't being properly reset when the interaction ended. Previously, data wasn't fully restored to its original state. This ensures a more reliable and consistent user experience within Colibri.
Original PR description
When the Interaction framework was introduced in [1], fields that were modified by t-outs weren't restored to the initial values, although initial values were saved. This commit restores them on destroy. [1]: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b Forward-Port-Of: odoo/odoo#237912
This update fixes a bug that caused video streams with background blur to freeze when users switched between browser tabs during video calls. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring smooth and uninterrupted calls.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves a technical issue preventing correct event description editing within the website. The fix clarifies HTML tag specifications, ensuring the system accurately reflects changes made by users. This improves the overall event management experience.
Original PR description
The tour test testUI.test_website_event_tour was failling because the HTML tag specify to edit the event description was not precise enough and led to wrong modification. I specified the itemprop property of the specific tag to edit in order to erase the previous ambiguity. The proposed fix is inspired by the saas-18.4 version of the code. Runbot error: 226574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236549
This update resolves a build error caused by an incorrect reference to a field within the Odoo payroll module for Belgium. The fix involved adjusting the code to correctly utilize the field when it's installed, ensuring accurate payroll calculations and preventing the build error. This improves the stability of the Odoo Enterprise system.
Original PR description
…act_salary A runbot build error was reported for one of my tests: https://runbot.odoo.com/odoo/runbot.build.error/233591 The issue was because the field `hide_in_offer` was used in a module where it did not exist. I have overridden the function to make it call the field when it was installed, and moved the logic using it to that inheriting function. task-5350522
This update resolves a test failure in the website tour process, specifically related to the 'edit_menus' feature. The fix ensures the test consistently passes by correctly triggering the necessary menu expansion before interacting with the target element, addressing an issue dependent on screen resolution.
Original PR description
Before this commit, when tested locally, `test_17_website_edit_menus` could fail at step 49/117 because the link element marked as "Modnar" could be invisible. The element could be invisible because it could be hidden under the "Extra" menu that is created when too many links are added to the navbar. In order to make the element appear, the "Extra" menu should be opened first. In the test, the call to `clickOnExtraMenuItem` happens at the wrong moment. This commit fixes the problem by calling `clickOnExtraMenuItem` before actually trying to interact with the element. Note that this problem doesn't seem to happen on runbot, but systematically fails on local, probably because of its dependance on screen resolution (determining whether the "Extra" menu is created or not).
This update fixes a problem that prevented the generation of export files for the Acerata payroll system. The fix ensures the export process works correctly by using a reliable field (display_name) instead of one that could be empty. A new test suite has been added to guarantee the Acerata export functionality is working as expected.
Original PR description
When generating the export file, a traceback occurred because the name field was empty. The logic has been updated to use the display_name field instead, ensuring the export runs correctly, as it is always set to a value. However, the display_name sometimes is just a date, so I depended on a customizable new lable to show the employee to this version. Additionally, a comprehensive test suite was added to validate Acereta code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Acereta export flow (from work entry creation and validation to export file generation). task-5153727
This update resolves an issue where employee profile pictures were misaligned on mobile devices. The fix ensures that employee avatars display correctly, providing a consistent and professional user experience for mobile users. This improves the visual presentation of employee profiles.
Original PR description
The employee form view displayed misaligned avatar images on mobile screens. task-5241292
This update resolves an issue preventing proper access to key fields within the payroll module for Switzerland (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate data transmission related to Swiss payroll reporting, improving the reliability of financial reporting. This change impacts the HR and Payroll functionalities.
This update resolves an issue where the spreadsheet feature wasn't reliably displaying data errors, leading to a confusing user experience. The team removed a confusing 'clear' button and corrected a technical error that prevented data loading errors from being properly displayed. This ensures data is loaded correctly and errors are clearly communicated to the user.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236683 Forward-Port-Of: odoo/odoo#233739
This update resolves an issue where users creating filters in the spreadsheet edition would encounter errors when working with broken data sources. The fix extends a previous safeguard to all filter types, ensuring a smoother user experience and preventing crashes during filter creation, particularly after data source migrations.
Original PR description
Forward-Port-Of: odoo/enterprise#100027 Forward-Port-Of: odoo/enterprise#98448
A technical glitch was causing a traceback to appear after canceling orders with a specific default preset. This update redirects users to the correct screen and prevents a new order from being created, ensuring a smoother order cancellation process for restaurant staff. This improves the user experience and prevents data inconsistencies.
Original PR description
### step to reproduce: - Set default preset to "Takeout or Delivery" in restaurant config. - Open restaurant . - Open any table and add a product. - Cancel the order using the action button. ### issue: - A popup appears asking to select a partner/floating order name, followed by a traceback. ### cause: - Traceback occures as next screen is loaded after order deletion. ### fix: - Redirect to the default screen before deleting the order. - Ensure that no new order is created when the next screen is the floor screen. task: 5092951 Forward-Port-Of: odoo/odoo#237574 Forward-Port-Of: odoo/odoo#227925
A technical error in the Mail Group module on the Odoo portal was causing a system crash. This update corrects a problem where the system incorrectly combined domain objects, resulting in a `TypeError`. The fix ensures the portal's group functionality operates smoothly and reliably.
Original PR description
Steps to reprodude: ------------------------- 1. Install `mail_group` module. 2. Go to groups from the portal side 3. Click on any group 4. From Archives section, click on any month in By Date groupby Observation: ------------------------- Taceback occurs: ``` TypeError: unsupported operand type(s) for &: 'DomainCondition' and 'tuple' ``` Issue: ------------------------- In the following code: https://github.com/odoo/odoo/blob/0c19399518029b85650b6204279e1e20d8d2e85c/addons/mail_group/controllers/portal.py#L112-L113 Only one tuple is converted to Domain object and it was trying to combine a Domain object with a plain tuple using the `&` operator, which generates the `TypeError` Solution: ------------------------- Converted the other domain tuple to the Domain object.
A technical issue preventing users from accessing the date filter within mail groups has been fixed. This update corrects a coding error that caused a traceback, ensuring the date filter functionality is now consistently available for all users. This resolves a minor disruption to the website's mail group management.
Original PR description
Steps to reproduce =================== 1. Open any mail group on the website side. 2. Try to access the date filter. Here https://github.com/odoo/odoo/pull/206575/commits/99ece288df1bbb98fd538479b07da14f3abf0d03, we missed wrapping the tuple in the `Domain` class. Task-5369008
This update fixes a previous limitation by allowing portal users to be directly linked to employee records within the HR module. The system now displays all portal users in the employee selection field and defaults the search view to show internal users, improving data accuracy and streamlining workflows. This change simplifies employee management and reporting.
Original PR description
- Display all portal users in the user field. - Set the default filter in the search view to show internal users. - Change the placeholder text for the `user_id`. task-5176046
This update fixes a visual issue where a person's leave status was being hidden behind their work location icon in the employee presence widget. The fix prioritizes the leave icon when both the hr_holidays and hr_homeworking modules are active, ensuring accurate representation of employee status. A temporary bridge was created to manage this specific behavior.
Original PR description
Issue is that when a person is in leave and has a work location set, the work location icon in the presence widget takes presedence before the leave icon. The widget uses a get icon() function to return which icon to display. This function is then patched to add new icons. The plane icon for time off is in the hr_holidays module while the house and building icons in the hr_homeworking module. The issue is that hr_homeworking overrides the patch from hr_holidays giving it more priority. The fix is a "revert" where if the presence value is holiday the work location will not be set, making the label and icon not be set. task-5223178
This update fixes a synchronization issue between the website's highlight color picker and its overall theme colors. Previously, changes to theme colors weren't reflected in the picker, leading to inconsistencies. Now, the picker automatically updates with theme color changes, ensuring a consistent brand experience across the website.
Original PR description
Before this commit: 1. The colors in the _highlight_ color picker were not properly synchronized with the _theme_ colors. 2. The _theme_ colors were copied as raw values instead of using _CSS_ variables, which caused them to fall out of sync. After this commit: 1. The _solid_ tab theme colors of _highlight_ color picker now stay in sync with _theme_ colors, even when they are updated. 2. Used CSS variables `var(--o-color-x)` instead of copying _theme_ color values. task-5079081
A bug was preventing users from placing test orders when a product's tax was set to a 'Group of Taxes' without a defined tax rate. This update corrects a technical issue in the Urban Piper integration, ensuring test orders can now be successfully created under these circumstances. This resolves a potential disruption in the PoS testing process.
Original PR description
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module -…
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module - Configure Urban Piper integration for the PoS - Create a new tax without Definition > ``Tax Computation: Group of Taxes`` > Save - Create a new product > Set the above tax in sales taxes > Save - Open the session for PoS - Go to Settings > Urban Piper Location > Set Food Delivery Platforms > Save - Click Test Order > Select the product and Delivery Provider > Place Order Traceback: ```py IndexError: list index out of range ``` https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/pos_urban_piper/controllers/main.py#L319-L322 The issue happens because ``flatten_taxes_hierarchy()`` calls ``_flatten_taxes_and_sort_them()`` method at [1], which returns an empty record when the group tax has no children at [2]. As a result, ``tax_types`` becomes an empty list ([]), leading to an IndexError when trying to access ``tax_types[0]``. [1]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L2786 [2]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L795 sentry-6984648461 Forward-Port-Of: odoo/enterprise#98542
This update resolves an issue where the mobile preview's scrollbar appeared incorrectly during page transitions. The changes ensure the entire website document is copied to the fallback iframe, and then the iframe's content is removed when no longer needed, eliminating a slight visibility problem.
Original PR description
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's…
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's document. This did not copied the attributes on the `html` node, which somtimes impacted the appearance. With this commit, the whole document is copied to the fallback iframe. Steps to reproduce: - Activate "Mobile preview" when viewing the website - Go to a page that is long enough for a scrollbar to appear - Navigate to another page - Bug: During the transition, the fallback is shown, and its scrollbar is wider than the one of the page that was shown just before task-5212287 ### [FIX] website: remove content of fallback iframe after load Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback iframe is shown behind the website preview to avoid flicker on navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the preview for mobile has some transparency on its scrollbar. Thus the part of the fallback iframe behind the scrollbar when previewing mobile was slightly visible. This commit fixes it by removing the fallback iframe's content after the website has loaded (and the fallback is not needed anymore). Steps to reproduce: - On website, activate "Mobile preview" - Navigate to a page long enough to have a scrollbar - Navigate to another page long enough to have a scrollbar - Scroll a bit - Bug: The scrollbar of the fallback is slightly visible task-5212287 Forward-Port-Of: odoo/odoo#233373
This update resolves a crash that occurred when users attempted to validate signatures on employee contracts. The issue stemmed from a missing field in the system's configuration after the 'Sign, Employee Contracts, and Documents' app was uninstalled. The fix adds a safeguard to gracefully handle the absence of this field, ensuring a stable user experience.
Original PR description
The system will crash with an error when the user tries to validate the signature.
**Steps to produce:**
- Install `Sign, Employee Contracts, and Documents` apps with demo data.
- Go to Apps and uninstall the `hr_contract_sign`module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.
**Error:**
`KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])`
**Cause:**
- When `sign` route is called, then we try to search field `sign_request_ids` in `hr_employee`. but we can see the field `sign_request_ids` is defined in `hr_contract_sign` module.
- And user removed the `hr_contract_sign` module, so the field no longer exists. in the hr_employee model.
**Solution:**
- Added a graceful bypass when `sign_request_ids` is missing,
**sentry-6819182542**
Forward-Port-Of: odoo/enterprise#95449This update fixes an issue where the invoice date was incorrectly changing after a company partner's address was updated. The fix ensures that the invoice date remains consistent, regardless of address changes, preventing potential accounting discrepancies. This improves data accuracy and reliability for Czech invoices.
Original PR description
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any address field (street, zip, etc.) and save. 5.Return to the invoice → in the chatter, the `date` field has change unexpectedly > Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction. **Issue** - The confirmed invoice `date` changes when updating the company partner’s address. **Cause** https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24 - When creating an invoice, the `date` field is correctly set based on the `taxable_supply_date` while the invoice is in the draft state. After confirming (posting) the invoice, it moves to the `posted` state. - However, when updating the partner address, the `_compute_date` method is triggered again, which calls `super()` and recomputes the `date` field using the standard logic. Since the invoice is already in the `posted` state, the CZ-specific condition is not satisfied, and the `date` gets updated incorrectly. **Solution** - Update `_compute_date` to only call super() for invoices in draft state. - This prevents unwanted recomputation of the `date` on post invoices. opw - 5086961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238045 Forward-Port-Of: odoo/odoo#229513
This update ensures that a checkered background is consistently displayed in the color preset preview area, regardless of whether a gradient or custom color is selected. Previously, custom colors lacked this visual indicator of transparency, creating a confusing user experience. This change improves clarity and usability when customizing website themes.
Original PR description
Steps to reproduce: 1. Go to website and click edit. 2. Switch to the _Theme_ tab and click on _Color Presets_. 3. Click on first color preset, then open the background color picker. 4. Switch to…
Steps to reproduce: 1. Go to website and click edit. 2. Switch to the _Theme_ tab and click on _Color Presets_. 3. Click on first color preset, then open the background color picker. 4. Switch to gradient tab, select any gradient, and adjust the opacity. 5. Now, click on second color preset, open the background color picker. 6. Switch to the custom tab, select any color, and adjust its opacity. Issue: When a gradient is selected (first color preset), the color preset preview area correctly displays a checkered background to indicate transparency. However, when a plain custom color is selected (second color preset), the checkered transparency background is missing from the color preset preview area. Fix: Set the value of `--PreviewAlphaBg-background-size` variable as `32px`. Moreover, extended the `%o-preview-alpha-background` placeholder in the `color_picker.scss` file to ensure the checkered background is consistently applied for both gradient and custom color selections. | Before | After | |-----------------------------|---------------------------------| | <img width="363" height="308" alt="image" src="https://github.com/user-attachments/assets/dbb64116-70d6-4475-9d41-90c0b591efcd" /> | <img width="363" height="308" alt="image" src="https://github.com/user-attachments/assets/ea8caa90-3518-4219-a980-a2a22f2f427d" /> | task-5226064
This update prevents the website's product shop from showing an empty 'alternative products' section when no alternatives are available. Previously, editing the section through the Editor would cause it to remain visible. This change ensures a cleaner and more user-friendly experience for customers browsing products.
Original PR description
### Issue: In this issue, alternative products section will continue to be shown in website_sale, even if the product has no alternative products, due to editing alternative products using Editor. #### To reproduce: 1- Create a product with an at least one alternative product. 2- On product shop page, using Editor, edit the description of alternative products section. 3- Remove alternative products of the product. 4- As seen, the alternative products section is still shown, even though it is empty. #### Cause: This is caused due to 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 which commented out `display: none` for empty snippets. https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/snippets/s_dynamic_snippet/000.scss#L2-L5 opw-5253884
This update resolves an issue where users couldn't mention colleagues in different companies within the Chatter feature. The fix adds necessary permissions to access user records, preventing an AccessError. This ensures seamless communication across company boundaries.
Original PR description
Steps to reproduce: 1. Create a portal user in the current company 2. Create a new company and switch to it. 3. In the Chatter of any record, mention the portal user from the previous company. Issue: - An AccessError is raised when mentioning a user belonging to another company. Cause: - The missing forward port of this commit https://github.com/odoo/odoo/commit/b1133f6a1efaef1d62f32f7f0197f2d8eb0cb191 was not merged, which caused the user to access res.users records without sudo() from version saas-18.4. Since the mentioned user belongs to a different company, the current user lacks the necessary read permissions, triggering the error. https://github.com/odoo/odoo/blob/6c35edb9dabaf8ce0b276ca26459401ac43d10e4/addons/mail/models/res_partner.py#L267 Solution: - Add sudo() to access the user. opw-5105598
This update fixes a technical issue related to payroll processing in the Odoo Enterprise module for Switzerland (l10n_ch_hr_payroll). It adds missing input types required to accurately reflect Swiss tax and social security regulations, ensuring correct payroll calculations and compliance.
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211
This update fixes a bug in the shop floor component consumption process when tracking by lot. Previously, the system incorrectly consumed large quantities (e.g., 1000kg instead of 50g) due to an issue with how lot quantities were handled. This change ensures accurate component consumption based on lot quantities, improving inventory management.
Original PR description
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg). **STEP TO REPRODUCE** 1. create a product. 2. create a bom with: - a component tracked by lot, with kg as product uom, but g as the bom uom. - create a step, during which 50g of the component is consumed. 3. create two lots of the component, with 1kg each. 4. create a MO for the product with the bom. 5. in the shop floor, try consuming the component and select one of the lot as a source. 6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove). 7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g). **CAUSE** 1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant. 2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g. 3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter). opw-5136050 Forward-Port-Of: odoo/enterprise#97005
This update fixes a problem where the system was incorrectly creating multiple bank accounts from UBL invoices. The change filters out duplicate account numbers, ensuring accurate bank information is recorded. This prevents potential errors and improves data integrity within the accounting system.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#238009 Forward-Port-Of: odoo/odoo#236676
This update ensures that the selection options for payment methods in the Point of Sale module are properly translated. Previously, these options weren't being translated, leading to potential inconsistencies in different languages. This change improves the user experience by allowing for accurate translations of payment method choices.
Original PR description
The field `payment_method_type` got its selection values from a function that did not translate the labels. In order to make them translatable, we wrap them in a `env._()` call, so they are properly exported in the POT file and translated at runtime. Forward-Port-Of: odoo/odoo#237768
This update fixes a subtle issue where RPC failures were being handled in a way that resulted in unexpected results being returned. Specifically, when an RPC call fails and is cached, the system incorrectly resolves the promise instead of rejecting it, leading to `undefined` being returned. This ensures more reliable error handling and consistent behavior for RPC calls.
Original PR description
Let's say we trigger two times a RPC that fails.
The first time, the cache is empty and we make the RPC. The ram cache is filled with `prom`.
The second time, we get `prom` from the ram cache.
When the RPC actually finishes, we end up in
```js
.catch((error) => {
this.ramCache.delete(table, key);
def.reject(error);
});
```
=> the RPC failure is catched, which means `prom` itself is not rejected. Instead, it resolves with the result of `.catch(...)`, which is `undefined`
Here is a simplified toy example:
```js
const prom = Promise.resolve(
Promise.reject(new Error("fetch failed")).catch(() => {})
);
```
In this example, `prom` is successful and the result is `undefined`
"
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#237984This update fixes a technical issue that prevented the 'fuel_type' selection field in the HR contract model from being properly translated. By directly using the variable for options, this change ensures all available fuel types can be localized, improving the system's internationalization capabilities.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100748