Daily updates from Odoo
Saturday, April 18, 2026
52 changes
21 changes
Resolved issues and error corrections
This update corrects a discrepancy in the Belgian payroll templates by adding a 'Dimona' category. This ensures accurate reporting and compliance with local tax regulations for employees categorized as 'Dimona' within the Odoo Enterprise system. The change improves the accuracy of payroll calculations and reporting for this specific employee group.
A technical error prevented the correct display of worksheets in maintenance reports. This fix adds a required 'readonly' attribute to checkbox fields in the worksheet template, resolving a rendering issue and ensuring reports display correctly. This improves the user experience for maintenance report generation.
Original PR description
Step to reproduce - install maintenance app with demo - go to settings and enable custom worksheet - open default worksheet and add a the checkbox property field - open a maintenance request, add this worksheet in worksheet field - notice, worksheet is visible in notebook - print maintenance report Observation: - we get a traceback ``` odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the template: KeyError: 'readonly' Template: worksheet.worksheet_template_properties_display ``` Cause: - when rendering checkbox, xml props needs `readonly` key for template "worksheet_template_properties_display" but it is not provided by `format_props` of worksheet module or `_get_props_formatted` of `maintenance_worksheet` module. Fix: - we add readonly attribute (default = False) for all boolean prop opw-6079837
This update fixes a problem where users without attendance editing permissions couldn't access overtime records. The fix adds specific user groups to the 'Overtime Details' section, granting access to those users and preventing unauthorized access. This ensures all users can accurately record their attendance.
Original PR description
Steps to Reproduce: - Log in as user which has no access of attendance - Try to open attendance record with overtime Issue: - As users below Self Attendance edit and hr administrator does not have access to rule_ids Fix: - Added groups on 'Overtime Details' section as other user does not have access to read. task-5886324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where pressing a space in the HTML editor would unexpectedly open a list of emoji suggestions. The fix replaces spaces within keywords with underscores, preventing these triggers and improving the editor's responsiveness. This ensures a smoother and more reliable user experience.
Original PR description
### Purpose of this PR: - Keywords contained spaces (e.g. "grinning face") which caused the suggestion list to open when the user typed a space. Replacing spaces with underscores in keywords fixes this since a space will no longer match any keyword. Shortcodes never contain spaces so they are unaffected. Names are removed from the lookup as they are already covered by shortcodes or keywords. task-6123666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the order report incorrectly showed a zero amount in the "Down Payments" section header. The change ensures that this section header accurately displays as blank, improving the clarity and professionalism of the report for customers. This resolves a visual inconsistency and enhances the overall user experience.
Original PR description
When creating an order with a down payment, the printed order report incorrectly shows a zero amount on the “Down Payments” line. This line acts as a section header and should not display any amount. opw-5446875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242833
This update resolves a crash that occurred when confirming rental orders with kit products containing multiple components in different pack locations. The fix uses a safer method to handle multiple pick transfers, preventing the system from attempting to assign a single return ID to conflicting picks. This ensures rental orders with kits can be processed correctly.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#114020
Forward-Port-Of: odoo/enterprise#112543This update fixes a reporting issue on the Swiss Balance Sheet by changing the date range used for calculating 'Current Year Retained Earnings'. Previously, the report used a broad date range, which resulted in inaccurate figures. This change ensures the report reflects the correct retained earnings for the current fiscal year, aligning with Swiss accounting standards.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#113920
This update corrects a problem where electronic invoices generated with units of measure containing special characters (like m² or m³) failed validation. The fix ensures that these units are properly formatted before being included in the XML, guaranteeing compliance with Italian tax regulations and preventing invoice rejection.
Original PR description
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259076 Forward-Port-Of: odoo/odoo#257012
This update fixes an issue where stock quantities were incorrectly visible for one company in a multi-company environment. Previously, a purchase order would create a stock.quant record searchable for the wrong company, causing access errors. Now, stock quantities are correctly restricted by the product's assigned company, ensuring accurate reporting and data access.
Original PR description
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company…
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company environment. If a purchase order with product from company 1 is being confirmed, received, and validated when company 2 is being selected as the primary active company while company 1 is also checked. It will create a stock.quant that is searchable for company 2. However, it will raise an error when company 2 is trying to access it. **After this commit:** Even if the stock.quant is created when company 2 is the primary active company, it will not be searchable for company 2 since the product's company is company 1. **Steps to Reproduce on Runbot:** - Create a storable product exclusive to Company A - Create & validate a receipt for that product in Company A. - Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible. opw-6082330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259733 Forward-Port-Of: odoo/odoo#257211
This update fixes an issue where the delivered quantity for kit products with dropshipped components was incorrectly calculated. The fix ensures accurate delivery tracking by addressing a flaw in how the system determines delivered quantities based on dropshipping routes. This improves the accuracy of order fulfillment and reporting for kit products.
Original PR description
### Steps to reproduce: - In the settings Dropshipping - Put you warehouse in 2 steps delivery - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route -…
### Steps to reproduce: - In the settings Dropshipping - Put you warehouse in 2 steps delivery - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route - Create and confirm an SO for 1 unit of your kit - Validate the ship and pick for COMP1 - Confirm the PO for COMP2 and validate the associated dropship #### > The qty_delivered on the sol is still at 0 ### Cause of the issue: The `delivered_qty` is computed via the `_prepare_qty_delivered`: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale/models/sale_order_line.py#L887-L902 However, since at least on of the component is dropshipped, the qty_delivered is computed by this condition: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L54-L63 Which is 0 since the pick `location_dest_id.usage` is not `customer`. ### Additional issue: The delivered quantity of a Kit with at least one dropshipped component can only be 0 or the full demand. - In the settings enable Dropshipping - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route - Create and confirm an SO for 3 unit of your kit - Validate the delivery for COMP1 for 2 units and backorder - Confirm the PO for COMP2 and validate the associated dropship for 1 unit and do not backorder #### > The qty_delivered on the sol is 0 instead of 1 - Cancel the backorder for COMP1 ### > The qty_delivered on the sol is 3 instead of 1 ### Cause of the issue: This is caused by the exact same dropship computation: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L63-L66 ### Note: The behavior should be consistent if the components are fully dropshipped or MTO buy and as such they should not be considered to be in all or nothing shipping policy. opw-6040640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258739 Forward-Port-Of: odoo/odoo#257617
This update resolves an issue where dropdowns within knowledge articles weren't closing when clicking outside the embedded view. The fix adjusts the way the system detects clicks, ensuring dropdowns close as expected. This improves the user experience when working with knowledge articles.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
This update resolves an issue where negative accounting numbers were being split across lines in PDF reports, making them difficult to read. The fix ensures that negative numbers are consistently displayed on a single line, improving the clarity and accuracy of customer statements and other financial reports. This improves the user experience for financial reporting.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
This update addresses a potential issue where Odoo could create related fields that rely on non-searchable data, leading to errors in searching, reporting, and overall system stability. By adding validation, this fix ensures related fields always use stored data, improving data consistency and preventing unexpected behavior.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Sale). - Go to Settings → Technical → Database Structure → Fields. - Create a new field using Studio or manually. -…
**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.
**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.
- This leads to runtime issues such as:
- Cannot convert field to SQL because it is not stored
- Failures in search, domains, and reporting
- Inconsistent behavior depending on usage context
- Currently, no validation prevents users from configuring such invalid related fields.
**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.
- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.
This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.
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#259309This update resolves an issue where images on the website weren't displaying properly when accessed from deeper pages within the application. The fix adds missing forward slashes to image source URLs, ensuring the browser correctly interprets these links. This improves the overall user experience and visual consistency of the website.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#259589 Forward-Port-Of: odoo/odoo#258879
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's code, ensuring the button now functions as expected and allows users to add new payslips when needed. This improves the usability of the W2 report generation process.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#114058 Forward-Port-Of: odoo/enterprise#111735
This update fixes a bug that prevented users from selecting values in selection fields within list views using keyboard shortcuts like 'Tab' and 'Enter'. The fix ensures that these shortcuts function correctly, improving the user experience when editing data in list views.
Original PR description
Steps: - Open any editable list view (for example sub-list view in sales) - Either it has a selection field or you add it via studio - With two values (for example "true" and "false") - Add a record to your list view - Try to edit the selection field - Popover is opened - You can select any value with a mouse click - You can navigate through values with arrows - You can't select values with `Enter` and `Tab` So list cell in edit mode has a function for all theses hotkeys: - `tab` - `shift+tab` - `enter` - `escape` Because `ListRenderer.onCellKeydown` is called before `hotkeyService.onKeyDown`, if any hotkeys is handled in cell edit mode it will be prevented and the hotkeyService will not propagate it to `select_menu`. That's why arrows are working, because there are not listed in cell edit mode keys. opw-6025476 Forward-Port-Of: odoo/odoo#258743 Forward-Port-Of: odoo/odoo#255029
This update fixes an issue where the Invoice Journal field wouldn't display when a user changed the invoice's company and only one suitable journal was available. Now, users can correctly update the journal selection, preventing the 'Invoice belongs to company...' error and ensuring accurate financial record updates.
Original PR description
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases,…
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Description of the issue/feature this PR addresses: The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Current behavior before PR: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal. Desired behavior after PR is merged: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259573
This update ensures that portal users with edit access to projects receive task notifications that redirect them directly to the editable project sharing view, rather than the standard read-only portal page. This improves the user experience and allows editors to quickly access and modify project settings when notified via email.
Original PR description
Before this commit, the action link sent in task email notifications to portal users always redirected to the standard, read-only portal view, even if the user had edit rights to the project via Project Sharing. This commit ensures that: - If a portal user has access to the task and the project has Project Sharing enabled for them, the action URL redirects directly to the editable project sharing view instead of the static portal page. task-5221400 Forward-Port-Of: odoo/odoo#251439
This update fixes an issue where account searches on invoices were inconsistent – searching by name limited results, while searching by code showed all accounts. The fix ensures consistent account search behavior regardless of whether the search is performed by name or code, and now always displays 'Search more...' in the account suggestions.
Original PR description
Currently, on invoices, the account_id many2one field overrides `name_search` to limit search results based on account types, but that is applied only if the account is searched by name. If the account is searched by code, all the accounts appear in search results which is not intended. This commit fixes that issue. task-6075233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257850
This update fixes a bug where users could create serial numbers for components on the shopfloor, even when serial number creation was disabled in manufacturing settings. This prevented incorrect tracking of materials and ensured data integrity within the MRP system. The change ensures that the system correctly enforces the defined rules for serial number creation.
Original PR description
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to…
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to reproduce**: - Enable "Lots & Serial Numbers", on the global settings - Create two products, one tracked by unique serial number - Go to Inventory > Configuration > Warehouse Management > Operations Types - Select Manufacturing and disable "Create New Lots/Serial Numbers for Components" - Create and confirm a MO using the tracked product as component - Go to shopfloor - Click the "+" button next to the component, then "New" -> No error is raised when creating a serial number **Cause**: The `_check_create` constraint relies on `active_mo_id`: https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19 However, the shopfloor does not pass this, in context: https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199 As a result, the check is bypassed. opw-6041241 Forward-Port-Of: odoo/enterprise#111408
This update prevents Odoo from repeatedly reloading images when navigating between different views. Previously, every time a user switched to a related view, all images were re-downloaded, leading to slower performance. The fix now intelligently caches images, reducing unnecessary data transfers and improving the overall responsiveness of the application.
Original PR description
Steps to reproduce ================== - Login as Demo - Go to Employees - Open a record - Go back to the kanban view -> Every image is retrieved again Cause of the issue ================== When loading an image, we add a unique parameter with the write_date of the record. We cannot use that for images on another record. Since we have no way of knowing when the image was changed, we used the timestamp when instanciating the ImageField. The downside is that every time we navigate to a view, every image is reloaded Solution ======== When the image is on another model, we don't pass the unique parameter. This means the image will be cached. A page refresh will be needed if the image has been updated in the current browsing session. opw-6070176 Forward-Port-Of: odoo/odoo#258943
4 changes
Resolved issues and error corrections
This update resolves an issue that could cause incorrect behavior after uninstalling modules due to outdated cached data. By clearing all relevant caches during the uninstall process, the system now ensures a consistent state, preventing errors and improving the reliability of module removals. This enhances the overall stability of the Odoo platform.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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#259941 Forward-Port-Of: odoo/odoo#259820
This update ensures that portal users with edit access to projects receive direct links to the editable project sharing view, rather than the standard read-only portal page. Previously, these links always directed users to a limited view, even with project sharing permissions enabled. This change improves the user experience for editors.
Original PR description
Before this commit, the action link sent in task email notifications to portal users always redirected to the standard, read-only portal view, even if the user had edit rights to the project via Project Sharing. This commit ensures that: - If a portal user has access to the task and the project has Project Sharing enabled for them, the action URL redirects directly to the editable project sharing view instead of the static portal page. task-5221400 Forward-Port-Of: odoo/odoo#251439
This update resolves an issue where entering an invalid Taiwan VAT number (e.g., containing letters) would cause the invoicing system to crash. The fix adds validation to ensure the VAT number consists only of digits, providing a clear warning message to the user instead of an error.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259936 Forward-Port-Of: odoo/odoo#259847
Calendar synchronization was incorrectly sending invitation emails for past events, triggered by the system's default invitation logic. This fix prevents notifications from being sent for historical events, improving email efficiency. Further investigation is needed to understand the root cause.
Original PR description
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for…
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for meetings that occurred in the past. It is not yet clear why this is happening (needs more investigation), but we quick fix this by correctly checking that an attendee is not part of an event on an past date before triggering emails during the `write`. ## Steps to reproduce the bug: 1. Create an new event in the past and save 2. Add a new attendee (partner) to the event SHOULD NOT create a notification email (but it does) ## Remarks: - readapting existing unit test for `test_event_creation_mail`, but a proper new unit test might be needed in a proper refactor. As of now we were never testing if emails are triggered when adding new attendees on an event in past - giving this, this bug might be affecting previous versions. Might need to be backported and tested if needed - added time freeze to `test_event_creation_internal_user_invitation_ics` to account for the fact that implicitly the tested event was in the past - `freeze_time` for certain tests using the class event, which has hard coded dates OPW-6125052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259844
3 changes
Resolved issues and error corrections
This update fixes a limitation in Odoo Studio where activity filters (past, today, future) weren't consistently working when the 'use_mail' option was enabled. The change adds necessary filters to the Studio search view, ensuring users can accurately filter activities based on their timing, regardless of whether email notifications are set up. This improves Studio's usability for managing and analyzing records.
Original PR description
Steps to reproduce
==================
- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future
Cause of the issue
==================
https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77
For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present
Solution
========
We add them to the search view. They are all pretty much implemented the same way in every model.
opw-6069150
Forward-Port-Of: odoo/enterprise#113792
Forward-Port-Of: odoo/enterprise#113011This update fixes an issue where resource leave requests weren't correctly applied to all resources. Previously, leave requests without a linked resource were ignored. Now, all resource leave requests are applied as intended, ensuring accurate scheduling and resource allocation within the rental planning system.
Original PR description
Before this commit, any `Resource Calendar Leave` created with no `Resource` related to it was ignored, while it should have been applied to all `Resources`. This commit makes sure that any `Resource Calendar Leave` with no related `Resource` is applied to all `Resources` as intended. task-5798796
This update resolves an issue preventing non-stock users from duplicating Helpdesk tickets with associated sales. The fix sets the product ID to 'false' during duplication, allowing users without stock access to create copies of tickets and their linked sales records. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#113564 Forward-Port-Of: odoo/enterprise#101338
6 changes
Resolved issues and error corrections
This update resolves an issue where users without stock access couldn't duplicate Helpdesk tickets with associated sales. The fix sets the product ID to 'false' during duplication for non-stock users, allowing them to create copies of tickets and their linked sales information. This improves usability for all users.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#113323 Forward-Port-Of: odoo/enterprise#101338
This update prevents the system from creating refund payments when an uncaptured Stripe payment is voided. Previously, a refund was automatically generated, even though no payment had been collected. This change ensures accurate accounting and avoids unnecessary refund processing.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924 Forward-Port-Of: odoo/odoo#259230
This update resolves an issue where invoices could fail to update their Peppol status, leading to inaccurate reporting. The fix involved correcting a configuration error that was preventing the system from properly processing Peppol invoice requests. This ensures accurate tracking of invoice status within the Peppol network.
Original PR description
1. Send an invoice that will return an error when send to IAP 2. Send the invoice 3. Click "Fetch Peppol Invoice status" on the dashboard 4. There is a traceback (see the bottom of this message) To…
1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)
To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
edi_users._peppol_get_message_status()
File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
peppol_response = uuid_to_record[uuid]
^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```
task-None
Forward-Port-Of: odoo/odoo#259834This update fixes a potential issue that could cause incorrect behavior after uninstalling modules in Odoo. Previously, outdated references within the system's data structure lingered, leading to problems with how the system tracked relationships. Now, the system clears all relevant caches during uninstall, ensuring a cleaner and more reliable experience.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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#259820
This update fixes an issue where returning inter-company deliveries incorrectly credited the stock input account instead of reversing the original debit. By including transit locations as valid locations, the system now correctly handles returns, mirroring standard return behavior and ensuring accurate accounting for inter-company transactions. This ensures consistent and reliable financial reporting.
Original PR description
### Problem: When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to…
### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.
### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.
### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account
To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.
### Before
<table>
<th>Move type</th>
<th>Account</th>
<th>Debit</th>
<th>Credit</th>
<tr>
<td>Delivery</td>
<td>Stock output</td>
<td>100</td>
<td>0</td>
</tr>
<tr>
<td>Delivery Return</td>
<td style="{color: red}">Stock input</td>
<td>0</td>
<td>100</td>
</tr>
</table>
### After
(Or normal behavior without inter-company transfer)
<table>
<th>Move type</th>
<th>Account</th>
<th>Debit</th>
<th>Credit</th>
<tr>
<td>Delivery</td>
<td>Stock output</td>
<td>100</td>
<td>0</td>
</tr>
<tr>
<td>Delivery Return</td>
<td>Stock output</td>
<td>0</td>
<td>100</td>
</tr>
</table>
opw-5993147
Forward-Port-Of: odoo/odoo#255439This update resolves an issue where users attempting to save a customer record with an invalid Taiwan VAT number (e.g., containing letters) would experience a crash. The fix adds validation to ensure the VAT number consists only of digits, preventing the error and providing a clear warning message to the user.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259936 Forward-Port-Of: odoo/odoo#259847
1 change
Resolved issues and error corrections
A test case in the Helpdesk Stock module was corrected to remove a field that was no longer relevant. This change ensures the tests accurately reflect the current functionality of the module and avoids potential errors. The fix was automatically validated by automated testing.
Original PR description
Remove sale_line_id field from the test as it belongs to helpdesk_sale_timesheet and is not available in this module. runbot link - https://runbot.odoo.com/odoo/runbot.build.error/242470 Forward-Port-Of: odoo/enterprise#114162
12 changes
Resolved issues and error corrections
This update clarifies how payroll calculations are refreshed. Previously, separate 'Compute' and 'Reset' buttons caused confusion by handling different data. Now, the 'Compute' button automatically performs a complete refresh of both worked days and salary lines, streamlining the process for users.
Original PR description
The "Compute" button only recomputed salary lines while "Reset" also recomputed worked days lines, causing confusion Remove the separate "Reset" action and make "Compute" always perform a full refresh (worked days + salary lines) via action_refresh_from_work_entries. task-6075229
This update resolves an issue where timesheet suggestions were sometimes double-subtracting entries, leading to inaccurate time tracking. By tracking assistant-created timesheets, the system now correctly avoids proposing time that has already been manually entered, ensuring more accurate time reporting.
Original PR description
[IMP] timesheet_grid: handle manual entries conflict in assistant Manual timesheet entries should be subtracted from the assistant suggestions to avoid proposing time that has already been entered. Since manual entries can come from multiple sources (systray, grid, etc.), we now track assistant-created timesheets (those created via "Take" or by selecting suggestions) and exclude them from the manual subtraction pass. This avoids double-subtracting entries that are already handled via consumedEvents. task-6116579
This update allows users to start and stop timesheet timers directly from the systray, regardless of whether the `hr_attendance` app is installed. Previously, users needed this app to stop the timer when taking a break. Check-in and check-out data is stored locally in the browser for convenience, but is overwritten daily.
Original PR description
## Behavior Before the Commit When users interacted with the `timesheet`` systray, they were unable to stop the `timesheet` timer unless they had the `hr_attendance` app installed. This caused issues when a user went on break, as the timer continued running. ## Behavior After the Commit Users can now check in directly from the `timesheet` systray and later check out, which correctly stops the timesheet timer and doesn't require the `hr_attendance` module. ## Additional Information Daily check‑in and check‑out data is stored locally in the user’s browser. This ensures persistence across sessions without requiring database writes. Data from previous days is overwritten, meaning it can be lost if not recorded elsewhere. ---- task-[5969277](https://www.odoo.com/odoo/project/4105/tasks/5969277)
This update resolves a crash that occurred when users clicked on the Analytic Distribution field within the expense form. The issue stemmed from how the system handled JSON fields, specifically when determining the OCR box type. The fix adds optional chaining to ensure the system gracefully handles these fields without errors, improving the user experience.
Original PR description
**Problem:** Clicking on the Analytic Distribution field in the expense form triggers a traceback: "Cannot read properties of undefined (reading 'fields')". **Steps to reproduce:** 1. Enable Analytic…
**Problem:** Clicking on the Analytic Distribution field in the expense form triggers a traceback: "Cannot read properties of undefined (reading 'fields')". **Steps to reproduce:** 1. Enable Analytic Accounting in Settings > Accounting 2. Go to Expenses > New 3. Click on the Analytic Distribution field 4. Observe the JS error in the console **Current behavior:** TypeError: Cannot read properties of undefined (reading 'fields') in HrExpenseFormRenderer.getBoxType **Expected behavior:** Clicking the Analytic Distribution field should not cause any error. **Cause of the issue:** The `ExtractMixinFormRenderer` mixin listens to all `focusin` events and calls `getBoxType` to determine the OCR box type for the focused field. When a nested widget like `AnalyticDistribution` gains focus, `getFullFieldName` returns a dot-separated name (e.g. `analytic_distribution.x_plan_id`), causing the code to enter the dotted-name branch in `getBoxType`: `this.props.record.data[parentField]?._config.fields[fieldName]` The `analytic_distribution` data is a JSON object, not a relational record, so it has no `_config` property. Optional chaining on `data[parentField]` prevents a crash when the field is missing, but the missing `?.` on `_config` causes `undefined.fields` to throw. **Fix:** Adding optional chaining on `_config` is consistent with the existing defensive pattern already used on the same line for `data[parentField]?` and `[fieldName]?.type`. This makes `getBoxType` gracefully return no box type for non-relational nested fields, which is correct since OCR box overlay is not applicable to them. opw-6108576
This update fixes a previous issue where the 'upload bills/refunds' button was incorrectly applied to all bank statement lines. Now, the system accurately identifies whether a bank statement line is positive or negative and displays the appropriate upload button (bills or refunds) for better accuracy.
Original PR description
Fixed an issue where the default for positive and negative bank statement lines were upload bills, now it distinguishes between positive and negative bank statement lines and shows upload bills/refunds accordingly. task-6111047
This update strengthens the security and reliability of Odoo Sign requests linked to server actions. It now enforces required fields – like a specific partner for 'fixed' signers and a target field for 'linked_field' signers – preventing errors and ensuring signature requests are properly configured. This change enhances data integrity and reduces potential issues during signature creation.
Original PR description
Added a constraint to `sign.item.role` to ensure data integrity when configuring signature requests via Automated Actions. When a role is linked to a Server Action (`ir_actions_server_id` is set), the system now strictly verifies that: - Roles with a 'fixed' signer type have a specific partner assigned. - Roles with a 'linked_field' signer type have a target field selected. A `ValidationError` is raised if these conditions are not met. The constraint is specifically scoped to server actions to ensure standard Odoo Sign template creation remains completely unaffected. Added a Python test to guarantee this behavior is strictly enforced. Task: 6069253
This update fixes an issue where the gross salary percentage in the salary simulation preview was incorrectly displayed across multiple lines. The fix ensures the percentage value aligns properly within the preview, providing a cleaner and more accurate representation of the salary calculation. This improves the user experience for offer creation.
Original PR description
[FIX] hr_contract_salary_payroll: fix alignment of percentage field
**Bug production:**
It occurs only in master -> Recruitment app -> offers -> in the salary simulation preview the gross (100%) is appears in 3 lines, not proper.
**Bug cause:**
Due to grid structure of the parent and since there is nothing to keep them on the same line, it can easily pass to the below lines.
**Bug solution:**
Adding d-inline-flex to the inside span and adding text-nowrap to the parent div
task - 6044681This update simplifies the generation of sales order PDFs by removing unnecessary customer signatures and the associated tab from the Sales Order view. This change ensures a cleaner, more streamlined PDF experience for sales professionals, aligning with recent updates in the Odoo Community edition.
Original PR description
Right now, a signed order can be modified afterward while retaining the signature on the newly generated PDF. In https://github.com/odoo/odoo/pull/245198, we remove the customer's signature of all generated Quotation/SO's PDF except from the one they actually signed. We also remove the "Customer Signature" tab from the Sales order view. This tab was referenced to extend the template in the `sale_subscription` module. In this commit, we remove this reference and replace it for a reference to the tab before the removed one. task-5421716
This update fixes an issue where the Gantt view incorrectly displayed multiple time periods (e.g., 3 weeks) instead of the user's chosen one. The change ensures the Gantt view accurately reflects the selected time frame, improving usability and aligning with core planning functionality. This resolves a visual inconsistency.
Original PR description
Steps: - Go to the Project module. - Click on any project that has tasks. - Click on the Gantt view for this project. - Select a specific time period from the top menu (e.g., "Week"). Issue: - The Gantt view displays three periods (e.g., 3 weeks) instead of just the single period the user selected. Cause: - The default `getRangeFromDate` method was explicitly configured to calculate and return 3 time ranges centered around the focused date. [Link to Source Code](https://github.com/odoo/enterprise/blob/1cab53af040ca34f5c54843771a705b771ea41dd/web_gantt/static/src/gantt_model.js#L291-L296) Fix: - Override the `getRangeFromDate` method to calculate and return exactly one single time range based on the selected rangeId (week, month, year, etc.). This ensures the Gantt view only shows the selected time frame, aligning our module's behavior with the core planning.slot module. task-ID: 6049330
This update ensures Rental Orders consistently require both a start and end date when specifying rental periods. Previously, the system allowed open-ended dates, which wasn't aligned with the core functionality of rental orders. This change improves data accuracy and simplifies the rental process.
Original PR description
When clearing rental dates on a Rental Order, the daterange widget switches to an open-ended daterange input. However, Rental Orders require both a start and an end date. This commit ensures the input always requires a strict range. Follow-up of task-6003684
This update fixes a display issue in the account reports section. When a user selects the 'Local Gaap' ledger, the journal filter now correctly shows 'Local Gaap' instead of the company name. This ensures consistent and accurate reporting for users.
Original PR description
When a journal is archived, the name on the journal filter do not show 'Local Gaap' when the Local gaap ledger is checked. When the local gaap is selected, changed the display name of the journal filter. Before: Name of the companies whose all local gaap journals are selected After: 'Local Gaap' task-6111366 Forward-Port-Of: odoo/enterprise#113608
This fix resolves an issue where POS users with limited access rights encountered errors when closing their sessions, requiring administrator privileges to complete the process. The update simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users working with Fiskaly in Germany.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#114006 Forward-Port-Of: odoo/enterprise#112618
3 changes
Resolved issues and error corrections
This update resolves a bug where the 'Update Payment' button remained visible after a batch payment was created for invoices under the Mexican CFDI tax regime. The fix corrects a comparison error in the code that incorrectly included all invoices in a batch payment, leading to the button's persistent display. This ensures the button only appears for the intended invoice updates.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781
This update fixes a problem where selecting a company contact on the payment screen would cause an error. Now, the system checks for complete required fields before setting the order to invoice, ensuring smoother payment processing. This improves reliability and prevents data inconsistencies.
This update fixes a limitation in Odoo Studio where activity filters (past, today, future) weren't consistently available when email notifications (use_mail) were enabled. The change adds the necessary filters to the Studio search view, ensuring users can easily filter activities based on their timing, regardless of whether email notifications are active.
Original PR description
Steps to reproduce
==================
- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future
Cause of the issue
==================
https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77
For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present
Solution
========
We add them to the search view. They are all pretty much implemented the same way in every model.
opw-6069150
Forward-Port-Of: odoo/enterprise#113792
Forward-Port-Of: odoo/enterprise#1130112 changes
Resolved issues and error corrections
This update prevents Odoo from automatically creating refund payments when an uncaptured Stripe payment is voided. Previously, a refund was generated regardless of whether a payment had actually been collected. This change ensures accurate financial reporting and avoids unnecessary refund processing, improving financial control.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924 Forward-Port-Of: odoo/odoo#259230
This update streamlines the data sent from the POS self-order system to the user interface. A small adjustment was made to remove unnecessary fields, resulting in a more efficient and responsive user experience. This improves performance and reduces data transfer overhead.
Original PR description
Fix _generate_return_values to remove some fields that are not needed on the frontend