Saturday, April 18, 2026
12 changes · master
New functionality added to Odoo
This update introduces basic financial reports specifically tailored for Uzbekistan businesses. It includes essential reports like the Balance Sheet and Profit & Loss Report, providing localized reporting capabilities for our customers in Uzbekistan.
Original PR description
This commit introduces basic report package for Uzbekistan and includes Balance Sheet and Profit & Loss Report. task-3927927 Community PR - https://github.com/odoo/odoo/pull/241811 Forward-Port-Of: odoo/enterprise#113802 Forward-Port-Of: odoo/enterprise#103136
Enhancements to existing features
This update introduces a system for setting closing dates for employee types within payroll. It now alerts administrators when payrun closing dates are not configured for specific employee types, ensuring accurate payroll processing. This enhancement improves payroll compliance and reporting.
Original PR description
In this commit, we added a payroll_closing_date for the employee type model. We added a warning to notify the user when the payrun closing date for that employee type. task-5922782
Resolved issues and error corrections
This update clarifies how payroll calculations are refreshed. Previously, separate 'Compute' and 'Reset' buttons caused confusion by handling different data. Now, the 'Compute' button automatically performs a complete refresh of both worked days and salary lines, streamlining the process for users.
Original PR description
The "Compute" button only recomputed salary lines while "Reset" also recomputed worked days lines, causing confusion Remove the separate "Reset" action and make "Compute" always perform a full refresh (worked days + salary lines) via action_refresh_from_work_entries. task-6075229
Features or functions removed from Odoo
This update removes a technical field used to manually track component consumption in MRP work orders. Now, component consumption is handled through standard processes like marking moves as picked or editing quantities directly. This simplifies the process and improves consistency in how components are tracked.
Original PR description
This PR removes the technical field `manual_consumption` logic from mrp. Before this PR: If a move is marked as `manual_consumption=True`, its consumed quantity is not automatically updated on the…
This PR removes the technical field `manual_consumption` logic from mrp. Before this PR: If a move is marked as `manual_consumption=True`, its consumed quantity is not automatically updated on the MO. `manual_consumption` logic basically depended on the move being linked to an operation on the bom_line_id. After this PR: No more `manual_consumption` field. A move's consumed quantity is not automatically updated if it's picked. How the move is being picked is the same which is by marking a move as consumed in the shopfloor app, marking a work order that has component moves as done or simply editing the consumed quantity on the MO form. Changes in behavior: - If the move is marked as picked => it's no longer automatically updated. - Using barcode for mrp: When updating the qty_producing on the finished product, exiting the barcode and entering again => the quantity on the move lines reflect the new changed qty_producing and no more unpicked split move lines are created. However, changing the quantity on the move Lines (instead of the qty_producing) causes the move lines to split as expected [this is not necessarily a limitation but it can be improved if needed]. Community PR: https://github.com/odoo/odoo/pull/253649 Upgrade PR: https://github.com/odoo/upgrade/pull/9794 Task: 5882264
This update resolves an issue where timesheet suggestions were sometimes double-subtracting entries, leading to inaccurate time tracking. By tracking assistant-created timesheets, the system now correctly avoids proposing time that has already been manually entered, ensuring more accurate time reporting.
Original PR description
[IMP] timesheet_grid: handle manual entries conflict in assistant Manual timesheet entries should be subtracted from the assistant suggestions to avoid proposing time that has already been entered. Since manual entries can come from multiple sources (systray, grid, etc.), we now track assistant-created timesheets (those created via "Take" or by selecting suggestions) and exclude them from the manual subtraction pass. This avoids double-subtracting entries that are already handled via consumedEvents. task-6116579
This update fixes a previous issue where the 'upload bills/refunds' button was incorrectly applied to all bank statement lines. Now, the system accurately identifies whether a bank statement line is positive or negative and displays the appropriate upload button (bills or refunds) for better accuracy.
Original PR description
Fixed an issue where the default for positive and negative bank statement lines were upload bills, now it distinguishes between positive and negative bank statement lines and shows upload bills/refunds accordingly. task-6111047
This update strengthens the security and reliability of Odoo Sign requests linked to server actions. It now enforces required fields – like a specific partner for 'fixed' signers and a target field for 'linked_field' signers – preventing errors and ensuring signature requests are properly configured. This change enhances data integrity and reduces potential issues during signature creation.
Original PR description
Added a constraint to `sign.item.role` to ensure data integrity when configuring signature requests via Automated Actions. When a role is linked to a Server Action (`ir_actions_server_id` is set), the system now strictly verifies that: - Roles with a 'fixed' signer type have a specific partner assigned. - Roles with a 'linked_field' signer type have a target field selected. A `ValidationError` is raised if these conditions are not met. The constraint is specifically scoped to server actions to ensure standard Odoo Sign template creation remains completely unaffected. Added a Python test to guarantee this behavior is strictly enforced. Task: 6069253
This update fixes an issue where the gross salary percentage in the salary simulation preview was incorrectly displayed across multiple lines. The fix ensures the percentage value aligns properly within the preview, providing a cleaner and more accurate representation of the salary calculation. This improves the user experience for offer creation.
Original PR description
[FIX] hr_contract_salary_payroll: fix alignment of percentage field
**Bug production:**
It occurs only in master -> Recruitment app -> offers -> in the salary simulation preview the gross (100%) is appears in 3 lines, not proper.
**Bug cause:**
Due to grid structure of the parent and since there is nothing to keep them on the same line, it can easily pass to the below lines.
**Bug solution:**
Adding d-inline-flex to the inside span and adding text-nowrap to the parent div
task - 6044681This update simplifies the generation of sales order PDFs by removing unnecessary customer signatures and the associated tab from the Sales Order view. This change ensures a cleaner, more streamlined PDF experience for sales professionals, aligning with recent updates in the Odoo Community edition.
Original PR description
Right now, a signed order can be modified afterward while retaining the signature on the newly generated PDF. In https://github.com/odoo/odoo/pull/245198, we remove the customer's signature of all generated Quotation/SO's PDF except from the one they actually signed. We also remove the "Customer Signature" tab from the Sales order view. This tab was referenced to extend the template in the `sale_subscription` module. In this commit, we remove this reference and replace it for a reference to the tab before the removed one. task-5421716
This update fixes an issue where the Gantt view incorrectly displayed multiple time periods (e.g., 3 weeks) instead of the user's chosen one. The change ensures the Gantt view accurately reflects the selected time frame, improving usability and aligning with core planning functionality. This resolves a visual inconsistency.
Original PR description
Steps: - Go to the Project module. - Click on any project that has tasks. - Click on the Gantt view for this project. - Select a specific time period from the top menu (e.g., "Week"). Issue: - The Gantt view displays three periods (e.g., 3 weeks) instead of just the single period the user selected. Cause: - The default `getRangeFromDate` method was explicitly configured to calculate and return 3 time ranges centered around the focused date. [Link to Source Code](https://github.com/odoo/enterprise/blob/1cab53af040ca34f5c54843771a705b771ea41dd/web_gantt/static/src/gantt_model.js#L291-L296) Fix: - Override the `getRangeFromDate` method to calculate and return exactly one single time range based on the selected rangeId (week, month, year, etc.). This ensures the Gantt view only shows the selected time frame, aligning our module's behavior with the core planning.slot module. task-ID: 6049330
This update fixes a display issue in the account reports section. When a user selects the 'Local Gaap' ledger, the journal filter now correctly shows 'Local Gaap' instead of the company name. This ensures consistent and accurate reporting for users.
Original PR description
When a journal is archived, the name on the journal filter do not show 'Local Gaap' when the Local gaap ledger is checked. When the local gaap is selected, changed the display name of the journal filter. Before: Name of the companies whose all local gaap journals are selected After: 'Local Gaap' task-6111366 Forward-Port-Of: odoo/enterprise#113608
This fix resolves an issue where POS users with limited access rights encountered errors when closing their sessions, requiring administrator privileges to complete the process. The update simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users working with Fiskaly in Germany.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#114006 Forward-Port-Of: odoo/enterprise#112618