Daily updates from Odoo
Monday, December 8, 2025
33 changes · master
Resolved issues and error corrections
This update resolves a bug where the 'lock document' action wasn't consistently updating in the document previewer's action menu. The fix ensures the action menu reflects the current document status, improving the user experience when managing document access.
Original PR description
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical =========== - The action menu, which we are using inside the file previewer, is passed explicitly inside the FileViewer component of the document. We were using the `record.load()`, which will not have any effect on the FileViewer component and that's why the action menu was not updating. After this commit ================== - Used the `this._notifyChange()` method, which closes the preview and loads the model to align with the same behaviour as other actions. Task-4988116 Forward-Port-Of: odoo/enterprise#100639 Forward-Port-Of: odoo/enterprise#91760
This update resolves an issue causing errors during payslip generation. The fix ensures the system handles missing data gracefully by using a safer method to access dictionary values, preventing a key error. This improves the reliability of payroll processing.
Original PR description
Bug: When generating payslips, there is a traceback with keyerror. Cause: We were getting info from a dict but keys could be not present. Fix: Use get instead, with a default value. Forward-Port-Of: odoo/enterprise#100709 Forward-Port-Of: odoo/enterprise#99245
This update resolves a technical issue where calculations for new electronic invoice documents in the l10n_uy_edi module were failing. The fix ensures that necessary data is correctly assigned when a new document record is created, preventing calculation errors. This improves the reliability of invoice processing.
Original PR description
The PR https://github.com/odoo/odoo/pull/209587 adds a check for onchange calls on a newly created record. Since in that case `move_id` is not set on `l10n_uy.document`, the compute method fails to assign values. This commit adds a pre-assigned fallback for this specific case. Runbot error: https://runbot.odoo.com/odoo/error/234425 Forward-Port-Of: odoo/enterprise#101060
This update resolves a technical issue that prevented the printed receipt tour from working correctly after installing the `l10n_se_pos` module. The fix corrects a programming error that caused a runtime error, ensuring the receipt tour functions as expected for users.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing or `l10n_se_pos`. runbot-233248 Forward-Port-Of: odoo/enterprise#101016 Forward-Port-Of: odoo/enterprise#97355
This update improves the accuracy of pay dates displayed on payslips. Now, the payslip will show the actual payment date if available, otherwise it defaults to the current date. This ensures employees and payroll teams have the most up-to-date information.
Original PR description
Change the pay date in the payslip to the payment date if available; otherwise, use the current date. task-5358370
This update fixes an issue where employees were incorrectly added as future drivers for multiple vehicles during contract signing. The system now automatically remembers the last selected vehicle and its associated costs, streamlining the process and ensuring accurate salary calculations. A new tutorial has also been added to demonstrate the improved functionality.
Original PR description
purpose: When, for the same offer, the employee/applicant sign several times and choose a different car each time, he's recorded as future driver for all the cars. It should only be the last one previous behavior: - the employee/applicant is assigned as a future driver to each car he selects with each sign which removes them from the salary configurator for other employees/applicants - the salary configurator doesn't autofill previously selected vehicle values for partially signed contracts current behavior: - reset the `future_driver_id` field of previously selected vehicles with each sign - made the vehicles autofill from previously partailly signed offers - made the configurator display the vehicle cost of the selected vehicle instead of 0 the first time you choose it (when checking the checkbox not selecting from the dropdown) - added a tour `hr_contract_salary_tour_sign_again` to check if the values are filled correctly from previous signs task-id : 4962961
A recent update resolved a crash that occurred when users clicked the 'Add from Documents' button within the Contacts or CRM apps. This fix addressed an error related to accessing data, ensuring the button now functions reliably. This improves the user experience for logging notes.
Original PR description
Steps to reproduce ================== - Go in the app Contacts or CRM - Open a record - Click on "Log note" - Click on the icon "Add from Documents" You get an error: TypeError: Cannot read properties of undefined (reading 'channel_type') Technical ========== The [Commit] changes the way of accessing the `channel_type` from thread. The patch of `SelectAddDocumentCreateDialog` missed the optional chaining in accessing the type. This commit adds the optional chaining to avoid crash on accessing `channel_type` when `channel` is undefined. [Commit]: https://github.com/odoo/enterprise/commit/8d1c75abfcb437962ce4314dd480f16398474532 Task-5343940
This update corrects a flaw in how payroll amounts are calculated for employees with fixed wages. Previously, the system assumed all work entries were present, leading to inaccuracies when pay schedules aren't monthly or when there are no work entries. Now, the calculation uses the actual working days to determine the daily rate, ensuring more accurate payroll amounts.
Original PR description
As of now, in payslips, the computation of the amount for the work entries is based on the assumption that the effect of all work entries required for the computation is present. So if I have a total of 10 days total days, then the rate per day is considered as: Wage / 10. But this would not work with the cases where the pay schedule is not exactly one month for non-attendance cases, or if there are days with no work entries in them, especially if the wage type is Fixed Wage. The suggestion for this task is to enhance the way the wage per day is computed when it is based on a Fixed Wage. which is to compute the number of days in the payslip period based on the working schedule, and have the rate per day being: Fixed Wage / Total days. Where Total days is based on the payslip period & the work schedule. task-5186744
This update simplifies the export of HR work entries by automatically hiding the company selection field when only one company is available for the user. Previously, users could only export from their current company. Now, the system intelligently adapts to allow selection of other accessible companies, improving usability and flexibility.
Original PR description
In the HR Work Entry Export mixin form view, the company_id field is now hidden when there is only one available company in the selection. A computed boolean field determines whether the field should be visible, based on the current user's allowed companies and any country restrictions. The form view uses this flag to automatically hide the field when unnecessary. task-5149817
A test related to employer costs calculations within the South Africa payroll module (l10n_sa_hr_payroll) was failing. This was resolved by moving the test to the related module, l10n_sa_hr_contract_salary, ensuring accurate calculations for employer contributions.
Original PR description
**Issue** : TestEmployerCostsWithSaFields.test_employer_costs_with_sa_fields fails in Single app testing of l10n_sa_hr_payroll causing this error "AttributeError: 'hr.version' object has no attribute '_compute_final_yearly_costs'" **Cause** : _compute_final_yearly_costs is defined in hr_contract_salary which is not a dependency of l10_sa_hr_payroll **Fix** : move the test to l10n_sa_hr_contract_salary , because the module depends on l10n_sa_hr_payroll and hr_contract_salary **task** - 5361838 **related PR** : enterprise#98239
This update corrects a calculation error in the Spanish tax return wizard (l10n_es_reports). Previously, certain fields relied on an outdated return ID. This change ensures these fields accurately reflect the current tax return status, improving the reliability of reporting for Spanish businesses.
Original PR description
Since the implementation of the return engine in l10n_es_reports, the wizard fields show_exempted_from_mod_390 and is_period_quarterly are computed using the return_id field ; they hence should depend on it. runbot.build.error: 243405
This update resolves a problem with the monthly payroll summary report, preventing errors when generating reports. The fix involved updating how the report template references company information, ensuring accurate data reporting for payroll summaries.
Original PR description
Step to Reproduce: - install l10n_ch_hr_payroll with demo - create a employee - create a payslip for it, move it to paid stage. - go to Reporting > Monthly summary and generate summary for same period/month Observation: - traceback for faulty template Fix: - After this commit [1] `t-call` is now parametric and cannot not accept its child variables. - to fix this, we pass set res_company for company variable [1] https://github.com/odoo/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df opw-5243792 Forward-Port-Of: odoo/enterprise#100684
This update resolves a test failure in the payroll module (l10n_eg_hr_payroll) caused by incorrect calculations for employee leave balances in 2026. The fix incorporates a 'freeze_time' setting to ensure accurate balance projections, preventing test failures and guaranteeing correct leave tracking.
Original PR description
Before this commit, the test `test_get_annual_remaining_leaves_with_allocation` was checking the balance of an employee with an allocation for 2025. As no freeze_time was set, the test would fail in 2026 as the allocation would be invalid and the employee balance would fallback to 0. Same issue for the test `test_get_annual_remaining_leaves_after_leave_taken` The PR https://github.com/odoo/enterprise/pull/98223 was targetting the wrong test and thus, the error was not fixed. This commit merges all 3 tests in one using freeze_time runbot error 231559 Forward-Port-Of: odoo/enterprise#101458
This update resolves an issue where the Frontdesk kiosk URL wouldn't display the correct company logo when switching companies. The fix ensures the kiosk always accesses the correct company record, allowing the logo to load properly. This improves the user experience and visual consistency of the Frontdesk station.
Original PR description
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least…
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least two companies, each with a logo configured. - `Enable multi-company` access (user has access to all companies). - Open any Frontdesk station configuration and change the company to one different from the currently active company. - Copy the kiosk URL and open it in an incognito/private window. - The kiosk opens, but the company logo is missing. **Issue:** - Company logo not comes on frontdesk kiosk. **Root cause:** - When the kiosk URL is accessed, Odoo logs an `Access Denied by record rules`. - This happens because the selected company on the station is not included in the `Public User’s companies`. - As a result, the public user cannot read the company record, so the logo does not load. **Solution:** - Added an `onchange` on `company_id` to automatically include the selected company in the Public User’s `company_ids` if it is not already present. - This ensures the kiosk always has access to correct company record and logo. - Also added an XML-side fix to prevent an access error that occurs when a company is not activated and we attempt to select it in the company field. **Before:** <img width="500" height="500" alt="frontdesk_image_before" src="https://github.com/user-attachments/assets/b002ac6e-5271-4561-bf03-542a3feeefd1" /> **After:** <img width="500" height="500" alt="frondesk_image_after" src="https://github.com/user-attachments/assets/7b5bffe4-ccbf-48f5-ad9c-d5e6d2e7678e" /> **opw-5138980** Forward-Port-Of: odoo/enterprise#101534 Forward-Port-Of: odoo/enterprise#100300
This update addresses a potential issue where changes to product subscriptions weren't consistently flagged, leading to incorrect behavior. The change introduces a warning message when modifying subscription settings on products that have already been sold, ensuring data integrity and preventing unintended subscription changes. This improves the reliability of our subscription management system.
Original PR description
**Purpose:** When a product has already been sold, we cannot change the subscription field in the product form. Odoo was correctly raising an error when the user tried to do it at the product.template level, but no warning was raised when doing it at the product.product level. **Specification:** Raise a warning when trying to change the subscription field at the product.product level Task-5081772 See also: - https://github.com/odoo/odoo/pull/231606
This update allows users to optionally select a date range for fields, even when those fields are required. Previously, the date range option was automatically enforced, making it less flexible. This change simplifies the user experience and provides more control over date selection.
Original PR description
…equired Before this commit, the range was automatically enforced when the main field was required (either in the view or on the field itself). As a result, the button to switch to a date range was hidden and both start and end dates became mandatory. With this change, the range option remains available and optional. The range will only be required when the related field is required. If you really want to have the related field required, you should probably use the `always_range` option. task-5186221
This update enhances the automatic bank reconciliation process by prioritizing matching bank statements with transactions from the prior or equal date. Previously, the system would hesitate when multiple matches were found. This change ensures the most accurate reconciliation by selecting the closest matching transaction, minimizing discrepancies.
Original PR description
When having multiple candidates with the try_auto_reconcile we used to do nothing since there was a doubt. This commit will slightly change that by selecting the move line with the closer prior or equal date. task-5212876 Forward-Port-Of: odoo/enterprise#98269
This update simplifies the appointment calendar by showing only one period (day, week, month, quarter, or year) at a time, instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments, improving usability.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091 Forward-Port-Of: odoo/enterprise#98796
This update corrects a previous error in the EPF (Employee Provident Fund) calculation for our Malaysian payroll system. The changes ensure accurate rounding of tax amounts to the next ringgit and reflect the latest legislative employee rate adjustments. This improves payroll accuracy and compliance.
Original PR description
Previous behavior did not account for the rounding of the amount of tax to the next ringgit. Also the employee's rate has been updated in accordance to the legislation. task-5286179 Forward-Port-Of: odoo/enterprise#100736
This update resolves an issue where filters weren't consistently applied to reports included within annual reports. Specifically, the analytic group by filter was missing from the Profit & Loss (US) report when it was part of a larger annual report. This ensures all report filters work as expected regardless of report inclusion.
Original PR description
For reports that are part of an annual reports, the _compute_report_option_filter prevent the update of the filters when the report is added as a section of another report. In the case of the analytic group by for example, even when the options was enabled, the filter was not present on the profit and loss (us) since it is a section of the annual report. opw-5185296 Forward-Port-Of: odoo/enterprise#100064
This update ensures that test reports are now generated using the Odoo test server instead of the production server. This change prevents test data from impacting live operations and improves the reliability of our testing process. The system now recognizes test mode to direct report generation to the appropriate test environment.
Original PR description
Before this commit: - when generating test reports, the files were sent to prod aspone IAP server for processing which should not be the case After this commit: - added system parameter to recognize test mode to generate test return files - if test mode is enabled the files will be send to test iap server Upgrade PR: https://github.com/odoo/upgrade/pull/8465 Task-5015350
This update corrects an issue where the Aged Receivable report was not displaying invoices correctly when the invoice due date was removed. The fix ensures the report accurately reflects outstanding balances by aligning the data source used in the report with the invoice data. This improves report accuracy and data consistency.
Original PR description
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this…
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this entry <img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" /> Observation: - on clicking the entry, when redirected to list view, there are `0` records. Issue: - The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)` https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226 - while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view - This creates inconsistencies between two. https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394 opw-5237298 Forward-Port-Of: odoo/enterprise#99883
This update resolves a bug that prevented the generation of SAFT files when a journal entry lacked a partner but included a receivable account. The fix ensures that SAFT exports can now successfully process these entries, addressing a potential compliance issue for businesses using SAFT reporting. This change was backported from another issue.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100960
Forward-Port-Of: odoo/enterprise#100296This update prevents a traceback error that occurred when clicking the 'add' button on the shopfloor screen when a specific quality check was applied to a manufacturing operation. The issue stemmed from a missing variable being passed during the button click process, which caused an error. This fix ensures the 'add' button functions correctly under all circumstances.
Original PR description
**Issue** In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`. **Steps to reproduce** 1. Create…
**Issue** In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`. **Steps to reproduce** 1. Create two products (product and component) 2. Create a BOM for this product that consumes that component 3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations) 4. Add a quality check of type “Register Consumable Material” for this operation 5. Create a MO from that BOM and confirm it 6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise 7. Click on the 'add' button → A traceback occurs **Cause** In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button. **Solution** Add the `production` variable to the props. opw-5165259 Forward-Port-Of: odoo/enterprise#98808
This update fixes a potential issue in accounting reports where data from outside designated ledgers was incorrectly included. The change ensures that reports accurately exclude journal entries from other companies when grouping by multi-ledger, improving the reliability of financial data. This enhances the accuracy of financial reporting.
Original PR description
When grouping horizontally by multi-ledger in accounting reports, ensure that items from journals outside the ledger's designated company are properly excluded. task-5384534 Forward-Port-Of: odoo/enterprise#101475
This update resolves a performance issue affecting how the VersionHistory action handles company currency. The original change didn't account for the specific version history action, leading to a bug only visible in that context. This fix ensures consistent performance across all version history actions.
Original PR description
The perfomance commit added in https://github.com/odoo/odoo/pull/151725 did not account for the version history action that does not inherit from `AbstractSpreadsheetAction`. this missing value trickled down to a bug only detectable in the VersionHistory action and which is addressed in https://github.com/odoo/odoo/pull/232985 This commit adds the same performance to VersionHistory action. Task-5187293 Forward-Port-Of: odoo/enterprise#98870 Forward-Port-Of: odoo/enterprise#98038
This update simplifies the process of creating new signature templates in Odoo Enterprise. Now, new templates automatically default to the standard 'Sign' folder, reducing manual configuration and ensuring consistency. This streamlines workflow and improves the overall user experience.
Original PR description
Assign a default document folder to sign templates so that each newly created template automatically points to the default "Sign" folder. task-5023107 Forward-Port-Of: odoo/enterprise#92624
This update resolves a critical issue in the Swiss payroll module where holiday calculations were broken after recent 19.0 updates. The fix addresses problems with the absence views and calculations, and importantly, now includes support for continued pay and disability during time off applications.
Original PR description
After recent changes in 19.0 on the time off mechanisme, leave calculation in switzerland was completely broken, we fix in this PR the view and the calculation and add the continued pay and disability on the time off application as well task-5384297 Forward-Port-Of: odoo/enterprise#101209
This update enables administrators to modify the work entries associated with payslips that have been reversed or refunded. Previously, these entries were immutable. This change improves operational efficiency by allowing corrections to be made directly within the system through the user interface.
Original PR description
-Originally, work entries for validated payslips cannot be modified. -This task allows for the modification of the work entries for the reverted payslips. -State of work entries can be modified manually through list view + form view on gear icons Task-id: #5380821 Forward-Port-Of: odoo/enterprise#101461
This update resolves an issue where the 'Returns' button on tax reports was failing when using companies with different VAT numbers. The fix ensures the button correctly checks for all companies within the branch hierarchy, allowing users to generate returns accurately.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make sure both companies have an opening date, so that they generate returns - Make both companies active in the company selector - Open the tax report - Click on the "Returns" button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. We can fix this by simply making the "Returns" button branch_allowed. task-5369592 Forward-Port-Of: odoo/enterprise#101479
This update corrects an issue where shipping labels for FedEx deliveries weren't including the company name entered during checkout. The fix ensures that the correct company name is used on shipping labels, improving order accuracy and customer experience. This was caused by a misunderstanding of how contact information is handled in the ecommerce system.
Original PR description
Steps to reproduce: - install ecommerce (i.e. website_sale) and delivery_fedex_rest - setup demo payment + fedex delivery method (including publishing it) - open the db while not logged in (i.e. in private browsing) - add something in the ecommerce page to cart + checkout > checkout - type in random contact info INCLUDING "Company Name" - continue checkout > select FEDEX as delivery method > pay now - go to Sales App > Sale orders > open the SO generated by ecommerce - open delivery + validate Expected result: - Shipping label with the name + company name from the ecommerce form Actual result: - company name is missing Issue is due to a company not being generated by ecommerce. Instead a string field is filled in (which is not visible when creating a contact directly via the contacts app). Code has been adapted to consider this use case. opw-5119089 Forward-Port-Of: odoo/enterprise#101376
This update fixes a configuration issue where Indian payroll settings were incorrectly displayed for all company types. Now, these settings are only visible within Indian companies, ensuring accurate payroll localization and compliance. This change improves data integrity and avoids potential reporting errors.
Original PR description
Before: - Indian payroll localization setting was visible to all company. After: - Indian payroll localization settings will be visible to only Indian company. Steps to reproduce: - Install l10n_in_hr_payroll > Go to non Indian company > Payroll setting visible to all company. Task: 5383944 Forward-Port-Of: odoo/enterprise#101201
This update simplifies the display of payment references in bank reconciliation reports. Previously, excessively long payment references were automatically expanded, which has now been corrected. Users must now manually unfold the line to view the complete payment reference.
Original PR description
This commit removes the expand text feature available on payment reference field in the bank reconciliation. Before this commit, a payment reference too long to be fully displayed in the bank reconciliation view could be expanded to have the full payment ref. Now, the user has to unfold the line to get the full payment ref. no task id Forward-Port-Of: odoo/enterprise#101545