Daily updates from Odoo
Navigate
Branch
Saturday, March 28, 2026
94 changes
14 changes
New functionality added to Odoo
This update adds a necessary report handler for TDS-TCS (IT Act 25) reports within the Odoo Enterprise system. This ensures businesses can now generate the required reports, complying with Indian tax regulations. It's a key improvement for businesses operating in India.
Original PR description
With this commit, the report handler will be added to TDS-TCS (IT Act 25) reports. task-6035844 Forward-Port-Of: odoo/enterprise#112418 Forward-Port-Of: odoo/enterprise#112417
This update incorporates changes to India's tax regulations as outlined in the Income Tax Bill 2025, specifically regarding TDS and TCS. It adds new tax sections and groups to ensure compliance with the updated IT Act, improving the system's accuracy for Indian businesses.
Original PR description
The Income Tax Bill 2025 introduces TDS and TCS provisions in a more structured way compared to the existing Income-tax Act 1961, with the addition of new sections and taxes. This commit adds new sections and corresponding taxes for sections 392, 393, and 394, along with their respective reports. It also introduces new TDS and TCS tax groups for these taxes to differentiate them from the existing ones. The old taxes are deactivated as they are no longer applicable. task-6035844 Forward-Port-Of: odoo/odoo#256521 Forward-Port-Of: odoo/odoo#256102
Enhancements to existing features
This update simplifies the process for planning managers to finalize shifts. Now, marking a shift as 'completed' directly triggers the generation of related documents like timesheets and sales orders, without requiring manual steps. A warning is displayed to confirm the action, ensuring accuracy and efficiency.
Original PR description
Use case: The day is finished and I want to record all the shifts that I worked on that day. But without going through the entire flow by using the buttons (signing-in, marking the shift as completed, etc). Instead, we allow the user (planning manager) to directly mark the shift as in draft, progress, scheduled or completed by using the status bar of the shift state. When changing the state to any other states as completed, we only change the state but do nothing else. When changing the state to completed, we proceed with the generation of the timesheets, the sale rrder, stock moves, etc, except that we don't change the end date of the shift or redirect the user to the portal after editing the state. Also, we warn the user before changing the state to completed, to make sure he wants to perform that change and trigger the related actions. task-5966615 version-19.2
Resolved issues and error corrections
This update resolves an issue where excessively long product names in the Master Production Schedule would cause other schedule columns to disappear from view. The fix wraps long product names within the HTML tag to prevent this visual disruption and ensure the entire schedule remains visible.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088 Forward-Port-Of: odoo/enterprise#111896
This update resolves problems with exporting the trial balance and working files in Odoo Enterprise. Specifically, incorrect dates in the working file exports and issues with the custom template were addressed, ensuring accurate reporting.
Original PR description
Steps to reproduce: - Export the PDF of the trial balance OR - Export a working file Both use the custom template of the trial balance. The date of the working file was also incorrect.
This update resolves an issue where the system incorrectly identified direct deposit accounts due to changes in Wise's API response format. The fix ensures the system consistently handles both 'swift_code' and 'SwiftCode' variations, preventing errors and ensuring accurate processing of direct deposit payments. This improves the reliability of the direct deposit feature.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033 Forward-Port-Of: odoo/enterprise#112075
This update enhances the Project Budget reporting experience by clarifying key metrics, adding a progress graph, and streamlining the user interface. It also resolves an issue where billable types were incorrectly classified when installing the sale_timesheet module, ensuring accurate tracking of project costs.
Original PR description
This task provides corrections and follow‑up work related to PR IMP #104599. ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose clearer.…
This task provides corrections and follow‑up work related to PR IMP #104599. ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose clearer. 2. Corrected breadcrumb generation when accessing the Project form view from the top menu. 3. Adjusted the project update form view to remove excessive padding. 4. Added a graph to the project update view to visualize project progress over time. 5. Updated filters in the margin search view. 6. Improved billable type labels for better user clarity. 7. Ensured billable types are updated correctly when sale_timesheet is installed. 8. Added navigation from analytic lines to their parent record in the margin list view. 9. Added three colors (gray, green, red) to the Milestone stat button. 10. Improved the kanban view of projected margins. ## Additions ### Point 2 — Breadcrumb Fix When navigating from the top menu to the Project Overview, breadcrumbs were not generated correctly. To resolve this, a multi‑step flow was implemented: - Clicking the "Overview" button triggers the action `project_embedded_action_project_overview`. - This action calls the Python method `action_open_project_form`, which then triggers the client action `project_top_menu_overview`. - The client action uses the `doAction` service to open the Project form view. This approach is required because: - Breadcrumbs are generated correctly only when `doAction` is executed inside a client action. - The "Overview" button cannot directly trigger a client action, making the Python intermediary necessary. ### Point 7 — Billable Type Synchronization The `sale_project` module defines the `billable_type` field on `account_analytic_line`, including the generic types *Other Revenues* and *Other Costs*. The `hr_timesheet` module adds additional, more specific billable types. A problem occurs when: - `sale_project` is installed first, causing analytic lines that should belong to `hr_timesheet` billable types to be incorrectly classified under *Other Revenues* or *Other Costs*. - When `hr_timesheet` is installed afterward, these analytic lines are not automatically updated. This fix ensures that potentially misclassified analytic lines are corrected when both `hr_timesheet` and `sale_project` are installed. ## Task : task-[5955934](https://www.odoo.com/odoo/project/4105/tasks/5955934)
This update resolves a technical issue that was causing instability in Odoo's VoIP testing. The fix removes unnecessary event listeners that were previously leaking memory, ensuring the test suite runs reliably. This improves the overall quality and stability of Odoo's VoIP features.
Original PR description
Forward-Port-Of: odoo/odoo#256376
This update fixes an issue where Odoo's translation caching wasn't working correctly when related fields were updated. Specifically, when a translated field changes, dependent calculations using that field's translation in another language were incorrectly dropping the cached translation. This change ensures that existing translations are retained in the cache, improving performance and data consistency.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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#256324 Forward-Port-Of: odoo/odoo#256111
This update resolves a technical issue preventing a key test from running correctly within the sale order management module. The test has been moved to the related module, ensuring proper functionality and stability. This change improves the reliability of our sales order processing system.
Original PR description
Issue: --- `is_optional` does not exist in `sale` module, leading to runbot issue. The test needs to be moved to `sale_management`. runbot-242127 Forward-Port-Of: odoo/odoo#256099
This update corrects an issue in Odoo invoices' PDF reports where section formatting caused column misalignment, specifically when 'Hide Composition' was enabled. The fix ensures consistent alignment of subtotal information, improving invoice presentation and readability. This improves the professional appearance of invoices.
Original PR description
**Problem:** In invoice PDF reports, when a section has Hide Composition enabled having a product inside, the description cell reserves too many columns (that are not available like quantity, unit…
**Problem:** In invoice PDF reports, when a section has Hide Composition enabled having a product inside, the description cell reserves too many columns (that are not available like quantity, unit price) while the quantity is still rendered as (1.00 Units), and unit price/discount/tax cells are conditionally omitted for section/subsection display types. This adds the extra table cells (quantity "1.00 units", total amount) after the first few reserved columns, this shifts the quantity/amount column a few positions to the right resulting in inconsistency mapping between the values and the name of the column. Before: <img width="1622" height="867" alt="2026-03-25_10-56" src="https://github.com/user-attachments/assets/57d6857a-7763-48d3-8131-fdc4e37a6704" /> After: <img width="1628" height="771" alt="2026-03-25_13-55" src="https://github.com/user-attachments/assets/d9df6cbe-3c23-4874-b50f-6797ef644c03" /> **Steps to reproduce:** 1- Create a customer invoice 2- Add a section. 3- Add products under the section with quantity and price 4- Enable hide composition on the section 5- Confirm and print the invoice PDF 6- Observe the section subtotal rows shifted by one column **Cause:** In grouped rendering, line_colspan for non-product rows still reserves Quantity,Unit Price columns, while hide_details also renders a dedicated quantity cell (1.00 Units). This makes the row consume extra columns and breaks alignment. **Solution:** For grouped rows in hide_details mode, We need to render the description cell with a minimal colspan (1) and explicitly keep the remaining column slots stable: keep Quantity cell (1.00 units), Unit Price, Discount, taxes as an empty placeholder cells if not available. --- opw-6030372 Forward-Port-Of: odoo/odoo#256233 Forward-Port-Of: odoo/odoo#255334
A technical problem with how Odoo processed spreadsheet data was causing errors. This update removes a formatting issue (a trailing line break) from JSON files before they're used, ensuring the spreadsheet data can be correctly processed and used. This prevents errors when sharing and opening the Sales Commission spreadsheet.
Original PR description
Steps to reproduce: - Share the Sales Commission spreadsheet - Open the shared link ⮕ traceback This was caused by the trailing line break in the json, so the last character was not a `}`. Task: 6064328 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#256475 Forward-Port-Of: odoo/odoo#255523
This update corrects a timezone discrepancy in the generation of EDI export files for sales orders. Previously, the date used in the EDI file didn't align with the order's creation time, leading to potential errors. This fix ensures the EDI date matches the order's UTC timestamp, improving data accuracy and consistency.
Original PR description
The Issue: Before this commit, the generated EDI XML used `sale_order.create_date.date()` to populate the IssueDate node, while the test used `datetime.today().date()` to build the expected value. Since `create_date` is a UTC timestamp set by the database and `datetime.today()` returns the local system time, these diverge when the server timezone is ahead of UTC and the test runs shortly after local midnight (e.g., runbot at 01:00 CET produces UTC date Jan 11 vs local date Jan 12). The Fix: Align the test to derive its expected date from `so.create_date.date()` instead of `datetime.today().date()`, ensuring both sides use the same timezone-consistent source of truth. runbot-237841 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256065
This update enhances the Project Budget module by clarifying navigation, adding a progress graph, and resolving issues with billable type synchronization when the sale_timesheet module is installed. It ensures accurate reporting and a better user experience for managing project finances.
Original PR description
This task provides corrections and follow‑up work related to PR : IMP #236971 . ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose…
This task provides corrections and follow‑up work related to PR : IMP #236971 . ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose clearer. 2. Corrected breadcrumb generation when accessing the Project form view from the top menu. 3. Adjusted the project update form view to remove excessive padding. 4. Added a graph to the project update view to visualize project progress over time. 5. Updated filters in the margin search view. 6. Improved billable type labels for better user clarity. 7. Ensured billable types are updated correctly when sale_timesheet is installed. 8. Added navigation from analytic lines to their parent record in the margin list view. 9. Added three colors (gray, green, red) to the Milestone stat button. 10. Improved the kanban view of projected margins. ## Additions ### Point 2 — Breadcrumb Fix When navigating from the top menu to the Project Overview, breadcrumbs were not generated correctly. To resolve this, a multi‑step flow was implemented: - Clicking the "Overview" button triggers the action `project_embedded_action_project_overview`. - This action calls the Python method `action_open_project_form`, which then triggers the client action `project_top_menu_overview`. - The client action uses the `doAction` service to open the Project form view. This approach is required because: - Breadcrumbs are generated correctly only when `doAction` is executed inside a client action. - The "Overview" button cannot directly trigger a client action, making the Python intermediary necessary. ### Point 7 — Billable Type Synchronization The `sale_project` module defines the `billable_type` field on `account_analytic_line`, including the generic types *Other Revenues* and *Other Costs*. The `hr_timesheet` module adds additional, more specific billable types. A problem occurs when: - `sale_project` is installed first, causing analytic lines that should belong to `hr_timesheet` billable types to be incorrectly classified under *Other Revenues* or *Other Costs*. - When `hr_timesheet` is installed afterward, these analytic lines are not automatically updated. This fix ensures that potentially misclassified analytic lines are corrected when both `hr_timesheet` and `sale_project` are installed. ## Task task-[5955934](https://www.odoo.com/odoo/project/4105/tasks/5955934) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
New functionality added to Odoo
This update adds a necessary report handler to the TDS-TCS (IT Act 25) reports within the Odoo Enterprise system. This ensures compliance with Indian tax regulations by providing the required reporting functionality for users in India. It's a key step in supporting our Indian customers' reporting needs.
Original PR description
With this commit, the report handler will be added to TDS-TCS (IT Act 25) reports. task-6035844 Forward-Port-Of: odoo/enterprise#112417
Enhancements to existing features
This update incorporates changes to India's tax regulations as outlined in the Income Tax Bill 2025, specifically regarding TDS and TCS. It adds new tax sections and groups to ensure compliance with the updated legislation, aligning Odoo with the latest tax requirements for Indian businesses.
Original PR description
The Income Tax Bill 2025 introduces TDS and TCS provisions in a more structured way compared to the existing Income-tax Act 1961, with the addition of new sections and taxes. This commit adds new sections and corresponding taxes for sections 392, 393, and 394, along with their respective reports. It also introduces new TDS and TCS tax groups for these taxes to differentiate them from the existing ones. The old taxes are deactivated as they are no longer applicable. task-6035844 Forward-Port-Of: odoo/odoo#256514 Forward-Port-Of: odoo/odoo#256102
Resolved issues and error corrections
This update fixes an issue where quarterly VAT returns in the Italian module didn't automatically generate the required XML export files. The fix correctly uses the 'date_to' field for quarter detection, ensuring accurate XML generation. This allows users to properly file their quarterly tax returns.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#111370 Forward-Port-Of: odoo/enterprise#108548
This update resolves an issue where the system incorrectly identified direct deposit accounts due to changes in Wise's API. The fix ensures the system consistently handles both 'swift_code' and 'SwiftCode' formats, preventing errors and ensuring accurate processing of direct deposit payments. This improves reliability and avoids potential payment failures.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033 Forward-Port-Of: odoo/enterprise#112075
This update fixes a test failure related to optional discount line editing within the sale_management module. The test was incorrectly placed in the sale module, causing a runbot issue. Moving the test to the correct location ensures proper functionality and stability of the discount editing process.
Original PR description
Issue: --- `is_optional` does not exist in `sale` module, leading to runbot issue. The test needs to be moved to `sale_management`. runbot-242127 Forward-Port-Of: odoo/odoo#256099
This update resolves a technical issue that was causing instability in Odoo's VoIP testing. The fix ensures that event listeners are properly removed after tests, preventing memory leaks and improving the reliability of the test suite. This ultimately contributes to a more stable and dependable Odoo platform.
Original PR description
Forward-Port-Of: odoo/odoo#256376
This update fixes a performance issue related to Odoo's translation caching. Previously, when a translated field was updated, it could trigger unnecessary recalculations of other dependent fields, even if those fields used a different language value. Now, Odoo will retain existing translation caches, improving speed and efficiency when updating related fields.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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#256324 Forward-Port-Of: odoo/odoo#256111
A technical issue with how Odoo processed spreadsheet data was causing errors. This update corrects a problem where a trailing character in the spreadsheet's JSON format was preventing it from being correctly read and used. This ensures the spreadsheet data is processed reliably.
Original PR description
Steps to reproduce: - Share the Sales Commission spreadsheet - Open the shared link ⮕ traceback This was caused by the trailing line break in the json, so the last character was not a `}`. Task: 6064328 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#256475 Forward-Port-Of: odoo/odoo#255523
This update corrects a problem where the date format in EDI export files was inconsistent due to timezone differences between the database and test environments. The fix ensures that all dates are generated using the correct UTC timestamp, improving the accuracy and reliability of the EDI data. This impacts sales order generation and reporting.
Original PR description
The Issue: Before this commit, the generated EDI XML used `sale_order.create_date.date()` to populate the IssueDate node, while the test used `datetime.today().date()` to build the expected value. Since `create_date` is a UTC timestamp set by the database and `datetime.today()` returns the local system time, these diverge when the server timezone is ahead of UTC and the test runs shortly after local midnight (e.g., runbot at 01:00 CET produces UTC date Jan 11 vs local date Jan 12). The Fix: Align the test to derive its expected date from `so.create_date.date()` instead of `datetime.today().date()`, ensuring both sides use the same timezone-consistent source of truth. runbot-237841 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256065
3 changes
Resolved issues and error corrections
This update fixes a potential inconsistency issue in the Point of Sale (POS) system. Previously, users could modify tax settings while a POS session was open, leading to discrepancies between receipts and invoices. The change now prevents these modifications, ensuring accurate financial reporting.
Original PR description
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in…
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py. After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open. This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start. For example, changing this setting mid-session may differences between POS receipts and backend invoices. By adding `price_include_override` to the forbidden fields, the UserError can properly be raised. Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this. Related ticket: opw-6042367 Forward-Port-Of: odoo/odoo#254487
This update resolves a technical issue that was causing instability in Odoo's VoIP testing. The fix ensures that event listeners are properly removed after tests, preventing memory leaks and improving the reliability of the test suite. This enhances the overall stability of the VoIP features.
Original PR description
Forward-Port-Of: odoo/odoo#256376
This update resolves a problem where creating payments for expenses linked to a 'Branch' company would trigger an error. The fix ensures the payment journal entries correctly link to the expense's company, preventing these errors and improving the accuracy of financial reporting for multi-company setups.
Original PR description
**Steps to reproduce:** - Install Accounting and Expenses - Create a Branch company (e.g. Branch) - In company selector, select both Branch (as main) and its parent - In Bank journal settings, make…
**Steps to reproduce:** - Install Accounting and Expenses - Create a Branch company (e.g. Branch) - In company selector, select both Branch (as main) and its parent - In Bank journal settings, make sure that there is an outstanding payment account for "Manual Payment" - Create an employee in Branch - Create an expense: * Category: [any] (e.g. [EXP_GEN] Expenses) * Total: [anything] (e.g. 100.00) * Employee: [the created employee] * Paid By: company * Company: Branch - Create Report - Submit to Manager - Approve **Issue:** A UserError is raised because it tries to create a payment in Branch linked to a journal entry in the parent company. **Cause:** The payment is initialized with the company of the expense but not the related journal entry. **(A similar issue happens with an expense paid by the employee when generating the bill upon approval of the expense sheet)** opw-6007859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256172 Forward-Port-Of: odoo/odoo#254434
66 changes
New functionality added to Odoo
This update introduces a new report, 2033-C, required for French tax compliance (the 'liasse fiscale'). The report details fixed asset depreciation, capital gains, and capital losses. This addition ensures Odoo Enterprise meets French accounting regulations.
Original PR description
In order to create the liasse fiscale we need to create the report 2033-C Fixed Assets – Depreciation – Capital Gains – Capital Losses task-5417359
This update adds a new report, the 2033-G subsidiaries report, to Odoo's French accounting tools. This report is required for French tax compliance (liasse fiscale) and provides detailed financial information for subsidiary reporting.
Original PR description
This commit implements the 2033-G subsidiaries report. This is part of the "liasse fiscale" bundle of reports. Task ID: 5417363
Enhancements to existing features
This update simplifies how users edit external values within accounting reports. Now, users can directly modify values in place and changes are automatically saved, eliminating the need for separate editing and validation steps. Additionally, the system now supports editing dates and datetimes, enhancing report flexibility.
Original PR description
The aim of this commit is improving the design of external value in accounting reports. Before this commit, user has to click on the pencil/edit icon to open a popover to allow him to edit the value.…
The aim of this commit is improving the design of external value in accounting reports. Before this commit, user has to click on the pencil/edit icon to open a popover to allow him to edit the value. Once the value edited, the user still has to "Post" the value by validating it via a button. Now, the user can edit the value in place (no more popover) and the value is automatically saved when we leave the focus on the field. This commit also introduces an easier way to edit the boolean figure_type for external value. Before this commit, still in the popover, the user has to choose between 2 radio buttons (Yes / No). Now, it's easily editable by clicking on the value or on the pencil / edit icon. Finally, this commit introduces the possibility to have editable date or datetime figure_type. To do that, we are using the hook useDateTimePicker which allows us to custom the behavior of the DateTimePicker. To achieve this transformation, we decided to separate the logic in 4 different components. - AccountReportLineCellEditable: which is the component you have to call when you want to allow an external value editable. This is the conductor of how things should work. - AccountReportLineCellEditableBoolean: To easily handle boolean figure_type. - AccountReportLineCellEditableDateTime: To easily handle date and datetime figure_type. - AccountReportLineCellEditableLiteral: To easily handle integer, string, float and monetary figure_type. NB: This component doesn't have the best name for it, but it's to avoid one component per figure_type. no task id
This update simplifies the MRP barcode workflow by removing confusing settings and correcting errors in by-product lot management. Specifically, it ensures accurate lot assignments and streamlines the process of generating and scanning lot numbers, leading to faster and more reliable manufacturing operations.
Original PR description
*: stock_barcode, stock_barcode_picking_batch - Currently, in the `Barcode App` tab under `Manufacturing operation` type, certain settings such as `Destination location`, `Force destination for all…
*: stock_barcode, stock_barcode_picking_batch - Currently, in the `Barcode App` tab under `Manufacturing operation` type, certain settings such as `Destination location`, `Force destination for all products`, `Group batch lines` and `Move Entire Packages` have no impact in MO and can be made invisible, as their lack of effect may confuse users about their usage. - `Source location` and `lot/serial` scan validations were incorrectly applied to `by-products`, which are produced at `Production location` and don't require such scanning. This made by-product lines non-editable in the barcode, reducing usability for byproduct processing. Barcode interface for by-products lacked automatic lot generation, requiring users to manually create the next available lot, resulting in a slower and less efficient process. - Also, if a line has a reserved lot from the backend and another existing lot is scanned, it is applied correctly. However, when a `new lot/serial` is scanned even with `use_create_components_lots` enabled, the system falls back to the originally reserved lot from the backend, which leads to incorrect behavior. With this change, scanning a new lot clears the existing reserved lot and applies the scanned value instead. This ensures accurate lot assignment, improving traceability and reliability during barcode operations. These changes hides irrelevant settings for MRP operations, refines the field label `(Product → Component)` specifically for mrp operations, prevents incorrect `source location` and `lot/serial scan` validations from affecting `by-product lines`, and adds direct `lot generation` for by-products in the barcode screen , and ensure that generated or scanned lot names are visible in the MRP form view, as the previous compute logic was always hiding the lot name even when it was set. These updates reduce confusion and make the mrp barcode workflow smoother and more efficient, especially for by-products. TaskID-4655907
This update upgrades the Odoo codebase to M3.1, focusing on performance enhancements and stability improvements. Specifically, changes to field rendering have optimized computations, and the UI has been refined to maintain a consistent 'desktop' experience. Future updates will address remaining legacy M3 components.
Original PR description
This update transitions the codebase to M3.1 with a focus on performance and stability. By optimizing field rendering, we've eliminated unnecessary computations during patches. To achieve this, we now apply borders to cells within inner groups instead of applying them directly to inputs. As a result, adjacent inputs may no longer display these borders. To ensure a seamless transition, we have prioritized maintaining the "desktop" form integrity to prevent UI regressions. Consequently, some specific M3 specs were intentionally modified to provide a superior UI/UX experience. Note: Remaining legacy M3 artifacts will be cleaned up in upcoming commits. task-6054024
This update introduces a new 'groupby' field within reports, allowing users to customize grouping criteria. It provides a warning if the grouping differs from the standard, and enables users to adjust it. This improves report flexibility and data analysis capabilities.
Original PR description
Add user_groupby field on the report view and add warning if it's different than standard groupby with ability to set it again. The _get_groupby uses the one defined on the report line then uses the one on the report if not set. For existing reports, use groupby field on the reports. task-4801889
This update enables users to efficiently manage database tags by allowing them to add or modify tags for multiple databases simultaneously. Previously, users had to update tags individually for each database. This change streamlines the process and improves database organization.
Original PR description
The aim of this commit is to allow users to mass edit the list of database to add one or several tag on several dbs at once. task-id: 6046088 Forward-Port-Of: odoo/enterprise#112024
This update enables Peruvian Point of Sale (POS) systems to directly print electronic invoices and receipts on thermal printers, aligning with local regulations and industry standards. Previously, customers had to download invoices from an online portal. This change improves the customer experience by providing immediate, legally-recognized receipts.
Original PR description
Before: - In Peru, Point of Sale (POS) systems are allowed to generate E-invoices and E-receipts that comply with SUNAT’s requirements. - In the POS, Odoo prints a ticket that only includes a QR code linking to the customer portal, where the A4 invoice can be downloaded. - However, according to SUNAT and common practice in Peruvian retail environments, the printed POS ticket itself should serve as the legal representation of the electronic document After: - We allow Peruvian POS users to print electronic invoices and receipts directly on thermal printers (58 mm / 80 mm) using the same electronic document flow and data as the accounting module, ensuring full compliance with SUNAT’s representation requirements. Impact: - Improve customer experience by avoiding portal-only invoice download task-5193544 Forward-Port-Of: odoo/enterprise#101876
This update adapts the French financial reporting process to changes in how data is exported from Odoo. Instead of downloading entire files, data is now streamed to the user, improving efficiency and reducing download times. This ensures accurate and timely reporting for French businesses using the Odoo Enterprise system.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#111416 Forward-Port-Of: odoo/enterprise#102783
Resolved issues and error corrections
This update resolves a technical issue that caused Odoo to crash when viewing signed PDF documents. The fix ensures PDFs are processed correctly as binary data, generating the necessary image URIs and allowing users to view signed documents without errors. This improves the reliability of the signature feature.
Original PR description
Before this commit, viewing a signed PDF caused an AttributeError because the code incorrectly attempted to access a .content attribute on a bytes object. After this commit, the signature frame is processed directly as binary data, ensuring the image URI is generated correctly. taskid-3054211
This update resolves an issue causing inconsistent tours within the sign flow process. By refining the triggers used in the tours, the system now behaves more predictably and reliably. This enhancement improves the user experience and reduces potential disruptions during signature creation.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps. Fixed unit tests tags : .test_template_edition,.test_sign_flow
This update corrects a bug where an unnecessary empty picking was created alongside returns during purchase order confirmation. Now, only the correct picking (either an OUT picking for returns or an IN picking for standard orders) is generated, ensuring accurate stock management. This improves the efficiency and reliability of the purchase order process.
Original PR description
This commit fixes a test after changes in PR: https://github.com/odoo/odoo/pull/232855 Before the community PR: When creating a PO for a vendor with a negative quantity for a product, it creates an…
This commit fixes a test after changes in PR: https://github.com/odoo/odoo/pull/232855 Before the community PR: When creating a PO for a vendor with a negative quantity for a product, it creates an OUT picking with that same quantity to the vendor as a return which is correct. However, it also creates an empty IN picking which is not needed. After the community PR: Only the OUT picking is created for the order lines with negative quantity as a return and if there are order lines with positive quantity, it creates a normal IN picking as expected. Why this fix: Before the changes, when confirming a PO, a picking was created and then moves were created an assigned to the picking, that led to having `move.partner_id` to be None when it should be the same as `picking.partner_id` (in case of not dropshipping). This is because `move._compute_partner_id()` is not triggered as the moves is created after the picking. But after the changes, moves are created first and then a picking is created, this triggers `move._compute_partner_id()` properly and sets `move.partner_id` to be equal to `picking.partner_id`, so this test was changed accordingly to not expect None for the `move.partner_id` Community PR: https://github.com/odoo/odoo/pull/232855 Task-5074899
This update simplifies the Customer Statement report by removing a redundant column – ‘No Follow-Up’ – which was causing potential confusion. This change ensures the report focuses on relevant financial information, improving its usability for users.
Original PR description
Currently, the `Customer Statement report` includes the `No Follow-Up` column. **Steps to reproduce:** - Install the `account_reports` module. - Go to Invoicing> Customers > Customers and open any company partner. (e.g., Azure Interior) - Click the `Payable` smart button. - Select `Report: Customer Statement`. **Observation:** The `No Follow-Up` column appears in the `Customer Statement report`. However, this column is only relevant for the `Open Items`. In the Customer Statement report it has no functional purpose and may create `confusion`. **Fix:** This commit removes the `No Follow-Up` column from the `Customer Statement report`. Upgrade PR: https://github.com/odoo/upgrade/pull/9733 opw-5743390
This update corrects a potential issue in the Peru financial reports by ensuring the use of standard Odoo data definitions (ir.default) within the report queries. This ensures that reports accurately reflect the latest financial data and avoids discrepancies, leading to more reliable financial insights for users.
This update resolves a bug where users could incorrectly create 'Requested Documents' instead of folders when syncing Peppol documents. To avoid a complex workaround and a functional issue with folder placement, the ability to create or edit these documents through the settings has been disabled. This ensures accurate Peppol document synchronization.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111884 Forward-Port-Of: odoo/enterprise#111761
This update ensures all XML documents related to invoices (e.g., from e-invoices or EDI) are now correctly synced to the Documents app, regardless of how the invoice was created. This resolves previous issues where some XML files were missed, leading to incomplete record-keeping. It improves the accuracy and completeness of financial data.
Original PR description
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files…
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol). This caused several specific issues: 1. When creating an invoice via the Accounting upload interface, only the generated PDF was synced to the correct Documents folder, leaving the original XML file unsynced. 2. When creating an invoice from an existing file in the Documents app (via server action), the system correctly synced the generated PDF, but failed to move or sync the original XML source file to the target folder. 3. When receiving vendor bills via Peppol or other EDI networks, the proxy attaches the fetched XML to the `account.move` via an `ir.attachment` write. Because this bypassed the existing sync filters, the Peppol XMLs were never pushed to the Documents app. This commit updates the `ir.attachment` logic in both `create` and `write`. It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`) is attached to an `account.move`—regardless of the move type or whether it was uploaded manually or fetched via EDI—the document synchronization logic is triggered, properly linking and filing the XML alongside the PDF. Task-5909245 Task-5917535 Forward-Port-Of: odoo/enterprise#111961 Forward-Port-Of: odoo/enterprise#106574
This update corrects a validation error in the Romanian SAFT reports generated by Odoo. The team restored a key data element and used a sanitized bank account number, ensuring compliance with Romanian tax regulations and preventing report rejection by the validator.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, without this node, the SAFT is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277 Forward-Port-Of: odoo/enterprise#111852 Forward-Port-Of: odoo/enterprise#111664
This update resolves an issue where invoices for foreign customers (e.g., from Colombia) generated by Peruvian companies resulted in errors due to missing identification type information. The change ensures a default '0' schemeID is used, preventing invalid UBL/QR files and ensuring compliance with SUNAT regulations.
Original PR description
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an…
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types. In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like: ``` 2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value). ``` Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia): https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4 This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in: - PartyIdentification/ID/@schemeID - AccountingCustomerParty/AdditionalAccountID - the QR payload identification type field This prevents generating invalid UBL/QR content for foreign customers in multi-country setups. Forward-Port-Of: odoo/enterprise#111448 Forward-Port-Of: odoo/enterprise#105115
This update ensures that all future appraisals, associated appraisal roles, and personal goals are automatically removed when an employee leaves the company. This prevents outdated appraisal data from remaining active and simplifies the process for new employee onboarding.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived - only active (non-archived) appraisals are counted in the employee’s smart button task: 6036427 Forward-Port-Of: odoo/enterprise#111611
This update fixes an issue where OCR was incorrectly applied to expenses created from Stripe payments, and ensures chatter messages use the user's preferred language instead of the employee's. It also streamlines the OCR process for Stripe expenses, preventing data overwrites.
Original PR description
Problem: For expense created from stripe payment, OCR overwrites the data fetched from stripe. Solution: Skip OCR for expense created from stripe payment and put a log note explaining the same. ***…
Problem: For expense created from stripe payment, OCR overwrites the data fetched from stripe. Solution: Skip OCR for expense created from stripe payment and put a log note explaining the same. *** Purpose: One language may have been set on employee, but that employee may be using any other language in his environment, in that case user should see chatter messages in language from his environment. Before this commit: expense refusal message in chatter used employee's language. After this commit: expense refusal message in chatter uses language of user related to employee. *** Problem: Expense Digitalization (OCR) setting is not properly applied. Steps to reproduce:- - Create a new database with demo data and install `hr_expense_extract`. - Switch to `My US Company` and create an employee for that company. - In expense settings set Expense Digitalization (OCR) to Digitize on demand only. - Create an expense for above created employee and attach receipt. - Expense is digitized automatically. Cause: Here https://github.com/odoo/enterprise/blob/d8acbf22fec266ff7d5dcc9499543e6bea3c1325/hr_expense_extract/models/hr_expense.py#L43 `self.env.company` gives that user's default company instead of currently active company in company selector. Solution: Use `company_id` set on expense to determine Expense Digitalization setting. *** task-5712223 Forward-Port-Of: odoo/enterprise#106261
This update prevents data merge operations from failing silently when they take too long. Instead, a warning is displayed, suggesting users merge smaller groups of records and reloading the model upon successful completion. This enhances the reliability of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the main company partner, creating inconsistencies. A new test has been added to guarantee this improved functionality and reduce manual data updates.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#111861 Forward-Port-Of: odoo/enterprise#108339
This update restores the display of a proxy token for users in Egypt, addressing a previous removal that hid this functionality. The token is now stored directly in the database instead of requiring a modal, streamlining the process for Egyptian users. This change ensures consistent functionality for this specific region.
Original PR description
Proxy token generation was removed to avoid showing a modal with a token nobody cares about except Egypt. We reintroduce token generation, but display it to the database instead of showing a modal. see odoo/odoo#255121 Forward-Port-Of: odoo/enterprise#111608 Forward-Port-Of: odoo/enterprise#111496
This update fixes a usability issue on mobile devices where a key button was hidden within a dropdown, making it difficult to complete the loan creation process. The change ensures the compute button is always accessible on mobile, streamlining the user experience and preventing the widget from being destroyed.
Original PR description
Forward-Port-Of: odoo/enterprise#110931 Forward-Port-Of: odoo/enterprise#110120
This update resolves a technical issue preventing users from printing ESG reports. The fix removes an unnecessary check in the report generation process, which was causing an error when searching for account movements. This ensures that ESG reports can now be successfully printed, improving reporting accuracy and user experience.
Original PR description
Steps to reproduce:
1. From Accounting, create a Vendor bill with today's date, and containing a line
2. Confirm (post) it
3. Make the Payment ('Pay' stat button)
4. Create a VSME or CSRD report from the ESG App, for the current year
5. Try to print it
=> A traceback occurs (in _get_payment_terms_data()) as we are trying to search on the 'active' field of account.move, which does not exist. => Solution: remove this uneeded check
version-19.0
Forward-Port-Of: odoo/enterprise#111816This update resolves an error that occurred when starting a new pay run in the Hong Kong payroll module. The issue was caused by attempting to format a date field that was left blank. The fix ensures that required fields are validated before the system processes data, preventing the error and allowing users to correctly initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338 Forward-Port-Of: odoo/enterprise#108885
This update fixes a minor issue where many search dialogs within the Web Studio module lacked clear titles. Now, most of these dialogs display meaningful titles, improving usability and clarity for users creating and editing actions. This ensures a more intuitive experience when working with the Web Studio interface.
Original PR description
Before this commit, a lot of search More dialogs did not have a meaningful title because one parameter was usually not set. After this, most or all the selectCreateDialog have a meaningful title task-5932652 Forward-Port-Of: odoo/enterprise#111948
This update fixes a persistent error that occurred when attempting to activate payments through Odoo. The issue stemmed from discrepancies in payment activation status between Odoo and the payment provider, leading to a misleading error message. This change ensures payments are correctly activated within Odoo, preventing future disruptions.
Original PR description
It may be possible that payments are activated on provider side / odoofin side and not on Odoo side, in that case when we want to activate the payments it leads to an userError but the value is never changed on the db so the error will continue to happen indefinitelly. task-5490817 Forward-Port-Of: odoo/enterprise#107696
This update resolves a bug where custom snippets created in the website builder didn't display their dynamic content in the preview. The fix ensures that dynamic snippets, including those saved as custom snippets, correctly populate the preview iframe, improving the user experience when customizing website content. This change was necessary following a recent website builder refactor.
Original PR description
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are…
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet. This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview. Steps to reproduce: - Open website builder - Add a dynamic snippet (for example "Events") - Save the snippet as a custom snippet - Click on "Custom" snippet category - Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5427353 Forward-Port-Of: odoo/enterprise#110872 Forward-Port-Of: odoo/enterprise#108912
This update fixes an issue where fields weren't being populated correctly when new records were created in certain Odoo modules. The change ensures that all required fields are accurately set during record creation, improving data integrity and preventing potential errors. This primarily impacts the HR and Web Studio modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#111898 Forward-Port-Of: odoo/enterprise#109725
This update fixes an issue where document creation times were displayed incorrectly across different views in Odoo. The fix ensures that document timestamps are shown in the user's local timezone, providing a more accurate and consistent experience. This improves usability and data clarity for users managing documents.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update corrects a technical issue where certain invoice PDFs generated by the l10n_gt_edi module were missing legally required 'complementos' data. These complementos, present in the XML invoices, are now included in the PDF format, ensuring compliance with tax regulations. This change addresses a critical requirement for accurate invoicing.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update resolves several issues impacting the field service planning feature, specifically around shift generation, data management, and user interface display. The changes ensure accurate state handling during shift duplication, improve data consistency, and enhance the overall usability of the planning tools.
Original PR description
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field…
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field service app. In detail, this commit will: - better handle SOL generation - fix buttons visibility, display name, multi-company issues - fix mix up demo and data - auto install when sale timesheet and field service - display the first slot for today in the stat button - handle multi-company issue in slot conflicts Make partner phone readonly if no Contact access. Hide the Serial/Lot products from the shift catalog if the user has no inventory access - display view itinerary label in mobile - set role in field service product - fix the domain of SO stat buttons related to shifts - fix the default groups of "Planning By ..."" actions. - use a custom search view for 'resource_ids' in kanban of shifts - ask to switch in employee portal - hide by default some fields in list view of shift - avoid recomputing when a worksheet property changed - display message to design worksheet in desktop only - display plan intervention in ticket - recompute allocated hours when break time changed - rename Publish & send button into Publish in form view of planning.slot model - display full form in my planning only ## [FIX] planning: manage state in copy_data Before this commit, when the shift is duplicated, the state is not reset as expected. This commit sets copy=False on state field of planning.slot model, to handle that in copy_data when the shift is splitted because in that case we want to keep the state instead of resetting it. ## [FIX] planning: display notification error when save as template a template Before this commit, since the Save as template button is in the cog menu, it is still displayed even if shift has already generated a shift template. This commit will display a notification in the action of that button when there is already a template linked to that shift. ## [FIX] planning: display planned dates in display_name when empty Before this commit, the display_name of a shift could be empty and displays "Unamed" in the breadcrumb due to project, task, customer and role can be unset on the shift. This commit will display the planned dates of shift when the other fields used in the compute of display name are unset. However, the planned dates are not displayed in the display name if the view is gantt or calendar because the planned dates are already displayed and would be redundant. ## [FIX] worksheet: hide section when separator is folded Before this commit, when the definition of a worksheet defines 2 sections folded by default with some properties inside of each one and the worksheet template is used for a shift, if the user just unfolds one section to fill in just this one and lets the other section unfolded, then the properties in the both sections are displayed in the portal of the shift even if the second section is folded. The reason is because the value of the second separator is not in the properties of the shift because it is untouched. This commit checks if the separator is by default folded if its value is not in the properties of the shift. task-6020304 Co-Authored: Xavier Bol (xbo) <xbo@odoo.com> Forward-Port-Of: odoo/enterprise#110804
This update corrects a technical issue where the system was incorrectly limiting VAT number lengths when communicating with FedEx. The change ensures that VAT numbers, including those from countries like Switzerland with longer formats, are properly transmitted to FedEx, preventing delivery errors. This resolves a compatibility problem and maintains accurate shipping data.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#111864 Forward-Port-Of: odoo/enterprise#109999
This update addresses a privacy concern by hiding the total due amount from minimal cashiers when viewing partner lists. Previously, this exposed sensitive financial information to cashiers, which is now corrected to protect customer data. This change enhances security and aligns with best practices for cashier operations.
Original PR description
Before this commit, the total due amount was visible for minimal cashier in the partner list. This could leak sensitive information to the cashier, which is not desirable. opw-6039529 Forward-Port-Of: odoo/enterprise#111103
This update resolves a minor issue where the helpdesk tour occasionally failed due to the tour attempting to click a button before the kanban view was fully loaded. By ensuring the kanban view is fully rendered before the tour attempts to interact with it, this fix improves the overall stability and reliability of the tour experience.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update corrects a minor error in the demo data for the l10n_ch_hr_payroll module. Specifically, an incorrect reference to insurance information was removed, ensuring the demo data accurately reflects the module's functionality. This ensures consistent and reliable demo data for testing and training.
Original PR description
This commit removes an unnecessary record and fix wrong reference to the insurance line of the insurance group in the demo data of the l10n_ch_hr_payroll module. task-6070942 Forward-Port-Of: odoo/enterprise#112121
This update optimizes the testing process for our VoIP system by pre-generating a key demo bundle. Previously, this bundle was rebuilt repeatedly during tests, causing significant delays. This change dramatically improves test execution speed and efficiency.
Original PR description
This commit sets the `voip.assets_sip_demo` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +800 times with a db "all"). Forward-Port-Of: odoo/enterprise#112140
This update significantly speeds up the bank reconciliation process, particularly when dealing with large volumes of financial data. The previous freezing issue, caused by redundant calculations, has been resolved, resulting in a much faster and more responsive user experience. This enhancement improves efficiency and reduces frustration for users.
Original PR description
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to…
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to open a line would sometimes result in a timeout. **Root cause:** The `reconciledLineName` getter was called multiple times per render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL re-evaluates the template on every reactive state change, this created an O(n×m) computation loop (n renders × m statement lines) that overwhelmed the browser. **Fix:** Cache the result in OWL reactive state via a dedicated `_computeReconciledLineName()` method, called once on setup and reactively via `useEffect` when `line_ids.records` changes. The template is updated to store `Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding the array on every iteration. | Metric | Before | After | |---|---|---| | Longest blocking task | 15 091 ms | 5 118 ms | | Total blocking time | 74 147 ms | 22 481 ms | | Avg. click response | 2 163 ms | 28 ms | | Max click response | 14 305 ms | 222 ms | | Total microtasks executed | 9 917 | 32 484 | opw-5879798 Forward-Port-Of: odoo/enterprise#111059 Forward-Port-Of: odoo/enterprise#107135
This update ensures the KMD INF report only includes partners with a total turnover of at least 1,000 EUR. Previously, all partners were listed, regardless of turnover. Now, the report accurately filters based on invoice and credit note totals, improving report accuracy and data efficiency.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#112123 Forward-Port-Of: odoo/enterprise#101333
This update resolves an issue where the Customer Ratings form in the Helpdesk module displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures a cleaner and more intuitive interface for rating feedback.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
A test was failing intermittently because the system wasn't loading all necessary partner data due to a limit on the number of users loaded. This change increases the loading limit to ensure the correct partner information is always available, preventing test failures and improving reliability.
Original PR description
In the test, test_pos_settle_due_with_rounding, the partner that we want to check was sometimes not loaded in the frontend due to the default limit of 100 users loaded. Those users are loaded by priority of number of orders and then name. In the test, no order has been made before so we only check the alphabetical order of the names and the partner we want to check is not always in the first 100. In the fix, we change the limits to a very big number to be sure that the partner is loaded. runbot-error: 241039 Forward-Port-Of: odoo/enterprise#110130
This update prevents the entire reports cron job from stopping if an error occurs during report generation. Previously, a single error would halt the entire process. Now, the cron will continue to attempt sending other reports, improving reliability and ensuring timely report delivery.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111732 Forward-Port-Of: odoo/enterprise#105191
This update resolves an issue where discounts weren't being correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed during order processing, preventing errors and ensuring accurate pricing calculations. This improves the reliability of the self-order system.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update resolves an issue where reports related to employee termination holidays were not generating correctly when certain property settings were missing. The fix ensures that the report generates accurately regardless of the presence of these settings, improving the reliability of this important HR reporting process. This change ensures consistent and accurate reporting for employee termination holidays.
Original PR description
Forward-Port-Of: odoo/enterprise#112200
This update fixes an issue where audit reports in the Denmark localization module were incorrectly displaying global account reports instead of the specific reports tailored to the Denmark company. The change ensures that embedded account reports, like the Balance Sheet, now correctly reflect the Denmark company settings, providing accurate financial reporting.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886 Forward-Port-Of: odoo/enterprise#101377
This update fixes an issue with the layout of tax return check cards in the Odoo interface. The changes create a cleaner, more organized design, improving readability and reducing visual clutter. This ensures a more professional and intuitive user experience.
Original PR description
Description of the issue this commit addresses: The UI of the tax return check cards has too many white spaces and misaligned items causing counterintuitive reading. --- Desired behavior after this commit is merged: The cards have a cleaner spacing within them so the UI looks cleaner. --- task-6003121 Forward-Port-Of: odoo/enterprise#110136
This update fixes a problem where users with limited access (Invoicing Users) couldn't validate bills when audit reports were present. The fix ensures validation works correctly without requiring additional user permissions, improving the invoicing process for all users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259 Forward-Port-Of: odoo/enterprise#111782
This update resolves a potential error where the 'signRequestToken' value wasn't consistently being sent to the signing controller. The fix ensures that this critical information is always correctly transmitted, improving the reliability of the signing process. This prevents potential disruptions to users completing the signing workflow.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181
Forward-Port-Of: odoo/enterprise#111786This update ensures that all internal users receive booking notifications, regardless of whether their calendar is synced. Previously, notifications were limited to those directly connected via Google or Outlook, leading to some users (like organizers and followers) missing important updates. This change improves communication and ensures everyone involved is informed about appointments.
Original PR description
In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar. However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account. Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant. As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once. task-5152917 [1]: https://github.com/odoo/enterprise/pull/60913 Forward-Port-Of: odoo/enterprise#112101 Forward-Port-Of: odoo/enterprise#96638
This update removes a confusing purple pill that appeared on mobile devices when using Web Studio's approval features. This change simplifies the user experience for mobile users, preventing accidental clicks on the pill and ensuring a smoother workflow. It addresses a usability issue reported by users.
Original PR description
Steps: - Install `web_studio` - Add an approval rule to any action in any form view (example preview button) - Open this form view - You will have a purple info pill in every action button in the form view This can be confusing for people wanting to click on the button on mobile but instead, they click on the purple pill + we don't even want this opw-5911667 Forward-Port-Of: odoo/enterprise#111770
This update resolves an error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all-time' when no interval is specified, preventing a KeyError and ensuring the expense card functionality continues to work correctly. This improves stability and user experience.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287 Forward-Port-Of: odoo/enterprise#110639
This update fixes a bug that prevented users from adding reactions to messages within the ‘mail_group’ module in Discuss. The fix ensures that the ‘add reaction’ button isn’t displayed for message types that don’t inherit from the standard message format, improving stability and usability.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050 Forward-Port-Of: odoo/enterprise#112158 Forward-Port-Of: odoo/enterprise#111271
This update adds a new wage type in the Swiss payroll module (l10n_ch_hr_payroll) to accurately reflect 200% overtime rates. This change ensures compliance with Swiss labor regulations and provides more precise payroll calculations for employees working overtime.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes a problem preventing db_users from successfully connecting to their databases. Previously, connection attempts were blocked due to access rights issues. Now, users are correctly directed to the database website for login or connection, ensuring seamless access.
Original PR description
The aim of this commit is to allow a db_user to be able to connect to a database in which he should be able to connect. Before this commit: Clicking on connect would stumble upon access rights issues on system.parameter and on `database_api_key_to_use`. After this commit: User are correctly redirected on the db website, either already connected or on the login page. task-id: 6046086 Forward-Port-Of: odoo/enterprise#112081 Forward-Port-Of: odoo/enterprise#111965
This update corrects a failing tour within the HR Referral module. The issue stemmed from unexpected access rights, which has now been resolved by changing the company referenced in the tour. This ensures the tour functions correctly and prevents disruptions for users.
Original PR description
Before this commit, the tour `hr_referral_utm_campaign_tour` was failing because of some weird access rights issues. The issue did not seem to be reproducible in local with similar condition. This commit changes the company used in that tour runbot issue 239152 Forward-Port-Of: odoo/enterprise#111805
This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data consistency and reduces potential errors.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#112063 Forward-Port-Of: odoo/enterprise#111340
This update resolves a problem where Web Studio exports were incorrectly formatting property data. The fix converts the data to the correct XML format before exporting, ensuring accurate and reliable exports of Web Studio configurations. This improves the consistency and reliability of exported settings.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update fixes an issue in our tax reporting calculations related to trimester periods. Previously, the system incorrectly identified date ranges, leading to inaccurate report values. This change ensures correct period boundaries are used, providing reliable tax reporting data.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111721 Forward-Port-Of: odoo/enterprise#110504
This update fixes an issue where XML invoices to the public were not correctly marked as such during import. Previously, the system incorrectly defaulted to not recognizing invoices as public. This change ensures that invoices generated as 'public' CFDI are properly identified during import, improving invoice processing accuracy.
Original PR description
**PROBLEM** When importing a XML to create an invoice, even if the XML is an invoice to public, l10n_mx_edi_cfdi_to_public is False. **STEP TO REPRODUCE** 1. Create an invoice to public, and generate the xml (send with CFDI). 2. Use this xml to upload an new invoice and notice the cfdi to public checkbox is unticked. **NOTE** Previously, there was a [bug](https://www.odoo.com/odoo/my-support-tasks/5911542) where it would always be ticked. opw-5934626 Forward-Port-Of: odoo/enterprise#108287
This update resolves a bug where report date filters weren't correctly applied, particularly when using custom date ranges. Users could experience reports defaulting to previous periods. The fix simplifies date selection by removing the requirement for a 'custom' period type.
Original PR description
original pr: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 The The original pr forgot to change some values in the options of reports concerning the filter date. This is an issue for example when the report opens by default on previous period. Another way to reproduce is for example to create a working file with very custom dates, for example 1st February to 14 March, then exporting it. Then the date of the options won't be correct. To simplify the process, we don't require the key 'period_type': 'custom' when specifying dates on the options. Forward-Port-Of: odoo/enterprise#112201
This update resolves an issue with how payslips are calculated, specifically related to date and version information. The change prevents a technical error that could have impacted payroll accuracy. This ensures consistent and reliable payroll processing.
Original PR description
In this commit, the computes of payslip for the date_to and version_id fields were merged, in order to avoid a circular dependency between them. The date_to field is now computed in the same compute as the version_id, and it is computed based on the date_from and the older schedule of the payslip. (this older schedule is a compromise in order to avoid the circular dependency, as the schedule is needed to compute the date_to, but the schedule itself depends on the version_id). Task-6022151 Forward-Port-Of: odoo/enterprise#110340
This update corrects a technical issue impacting the accuracy of timesheet suggestions. The team fixed a bug where the system was incorrectly using a description field instead of the intended template field for calculating event frequencies. This ensures timesheet suggestions are more reliable and aligned with the intended functionality.
Original PR description
This PR fixes two bugs related to the timesheets assistant, and its recently introduced feature that allows counting event project matching frequency separately from their label. - When saving timesheets from suggestions, we were taking its "Description" field for frequency calculations instead of the "Template" field, which was introduced in this purpose. - The "Template" field was added in the wrong place in the code, causing it to be sent to the back end as a field value when creating timesheets and causing a traceback. Forward-Port-Of: odoo/enterprise#112342
This update enhances the Project Budget interface by fixing breadcrumb navigation and adding a progress graph. Crucially, it also ensures that billable types are correctly assigned when both the sale and timesheet modules are used, resolving a potential data classification issue.
Original PR description
This task provides corrections and follow‑up work related to PR IMP #104599. ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose clearer.…
This task provides corrections and follow‑up work related to PR IMP #104599. ## Expected Behavior After This Commit 1. Renamed the stat buttons in the Project form view to make their purpose clearer. 2. Corrected breadcrumb generation when accessing the Project form view from the top menu. 3. Adjusted the project update form view to remove excessive padding. 4. Added a graph to the project update view to visualize project progress over time. 5. Updated filters in the margin search view. 6. Improved billable type labels for better user clarity. 7. Ensured billable types are updated correctly when sale_timesheet is installed. 8. Added navigation from analytic lines to their parent record in the margin list view. 9. Added three colors (gray, green, red) to the Milestone stat button. 10. Improved the kanban view of projected margins. ## Additions ### Point 2 — Breadcrumb Fix When navigating from the top menu to the Project Overview, breadcrumbs were not generated correctly. To resolve this, a multi‑step flow was implemented: - Clicking the "Overview" button triggers the action `project_embedded_action_project_overview`. - This action calls the Python method `action_open_project_form`, which then triggers the client action `project_top_menu_overview`. - The client action uses the `doAction` service to open the Project form view. This approach is required because: - Breadcrumbs are generated correctly only when `doAction` is executed inside a client action. - The "Overview" button cannot directly trigger a client action, making the Python intermediary necessary. ### Point 7 — Billable Type Synchronization The `sale_project` module defines the `billable_type` field on `account_analytic_line`, including the generic types *Other Revenues* and *Other Costs*. The `hr_timesheet` module adds additional, more specific billable types. A problem occurs when: - `sale_project` is installed first, causing analytic lines that should belong to `hr_timesheet` billable types to be incorrectly classified under *Other Revenues* or *Other Costs*. - When `hr_timesheet` is installed afterward, these analytic lines are not automatically updated. This fix ensures that potentially misclassified analytic lines are corrected when both `hr_timesheet` and `sale_project` are installed. ## Task : task-[5955934](https://www.odoo.com/odoo/project/4105/tasks/5955934) Forward-Port-Of: odoo/enterprise#109492
This update streamlines the timesheet tour process after a recent change. The tour now automatically generates a user and displays empty lines in the timesheet grid when the view is empty, preventing errors and improving usability. This ensures a smoother experience for users adding timesheets.
Original PR description
In this commit: - Timesheet tour was adapted after the timer removal - To avoid blocking the tour: - An employee is automatically generated for the current user when trying to add a timesheet instead of displaying a validation error - My timesheets > few empty lines are displayed when the Grid view is empty task-5925597 Forward-Port-Of: odoo/enterprise#110520
Features or functions removed from Odoo
This update removes a redundant icon reference from the l10n_tw_reports module. This streamlining simplifies the module's configuration and improves its performance. The change ensures a cleaner and more efficient reporting process for Taiwanese users.
Original PR description
Remove the hardcoded icon path from the manifest. Task-6007589 CE PR: https://github.com/odoo/odoo/pull/254826 Forward-Port-Of: odoo/enterprise#112271 Forward-Port-Of: odoo/enterprise#111264
2 changes
New functionality added to Odoo
This update adds a necessary report handler to the TDS-TCS (IT Act 25) reports within Odoo Enterprise. This ensures that these reports, which are required for compliance with Indian tax regulations, can now be generated correctly. This change supports ongoing tax reporting requirements.
Original PR description
With this commit, the report handler will be added to TDS-TCS (IT Act 25) reports. task-6035844
Resolved issues and error corrections
This update ensures that all future appraisals, associated appraisal roles, and personal goals are automatically removed when an employee leaves the company. This prevents outdated data and simplifies the process for new hires and managers, improving data accuracy and streamlining HR workflows.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived task: 6036427 Forward-Port-Of: odoo/enterprise#111589