Monday, August 25, 2025
22 changes · master
Resolved issues and error corrections
The product search in Kenya localization now works correctly when users filter by KRA item code. This prevents search errors and helps sales users find products more reliably.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526
Helpdesk portal tickets with logged timesheets no longer show an unrelated Timesheets breadcrumb. This keeps navigation clearer for customers viewing their support tickets online.
Original PR description
**Steps to reproduce:** 1. Install 'Helpdesk Sale Timesheet' and 'Website' modules. 2. Create a helpdesk ticket and add timesheets to it. 3. Go to the portal view of helpdesk tickets. **Issue:** If the ticket contains timesheets, the "Timesheets" breadcrumb appears in the portal ticket view. **Cause:** The reason the timesheet variable is used in the hr_timesheet portal template is because it makes the condition evaluate to true, which is why the breadcrumb for Timesheets is displayed. **Fix:** Renamed the loop variable in `t-foreach` to avoid shadowing the `timesheet` variable from the outer context. task-4744294 Forward-Port-Of: odoo/enterprise#85411
The automated setup check for field service reports has been adjusted to follow the correct page flow more reliably. This helps prevent false test failures and supports smoother quality assurance for future updates.
Original PR description
In this commit, we fix tour by splitting
{
isActive: ["auto"],
trigger: 'body:not(.modal-open) nav.o_main_navbar, button[name="action_generate_new_template"]',
run: "click",
},
in two distinct steps
For this, we use isActive key of a step that allow to activate the step with conditions.
We take advantages of this commit to add expectUnloadPage where it is required.
Forward-Port-Of: odoo/enterprise#92834Payroll administrators will now see Python code displayed correctly when working with salary rules and rule parameters. This reduces confusion and helps users review or maintain payroll configurations more reliably.
Original PR description
Forward-Port-Of: odoo/enterprise#92960 Forward-Port-Of: odoo/enterprise#91811
A missing setup entry has been added so the payroll correction wizard is properly loaded. This ensures users can access the intended correction screens in payroll without manual workarounds.
Original PR description
- wizard views file was missing from the manifest file Task: 4731029
Receipt validation now correctly triggers lot or serial number label printing after a quality check is passed. This prevents missing labels when receiving tracked products and improves completion of mixed receipts with and without quality checks.
Original PR description
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The…
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action ## Cause: The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close' ## Note: The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option ## Steps to reproduce: - Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts - Create a Product tracked by Unique Serial Number - Add a Quality Check for the Receipts operation - Create a New Receipt for the product - Mark as Done and Add the Serial Number - Validate the receipt and Pass the check - Before the fix, no document was downloaded opw-4790427 Forward-Port-Of: odoo/enterprise#92850 Forward-Port-Of: odoo/enterprise#90134
Users with appointment access can now create resource-based appointments directly from calendar events without hitting an access error. This keeps the booking flow working as expected when an appointment type has a single resource assigned.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373
This update corrects display issues in stock valuation settings and makes Peru stock report lines appear in a consistent order. It helps users avoid confusing configuration screens and prevents inconsistent report results when records share the same date.
Manufacturing orders now follow the configured backorder preference when the first work order is completed with a smaller quantity. This prevents unwanted production and work order backorders, helping teams keep manufacturing records aligned with their operational settings.
Original PR description
When marking as done the first workorder with less quantitites, backorders (mo+wo) were always created, with no respect of the 'Create Backorder' setting defined on the Manufacturing picking type. Now this setting is taken into account. task: 4440866
The Journal Audit report PDF export now works when users filter by receivable or payable account types. This prevents an error that blocked exporting the report, helping accounting users retrieve audit documents reliably.
Original PR description
- In the Journal Audit report options, set the Account Type (filter_account_type) to either receivable, payable, or both. - Attempt to export the PDF of the Journal Audit report. A traceback occurs because, in _generate_document_data_for_export, we attempt to add a join using an alias. However, if the filter_account_type option is enabled, there is already a left join in the query with the same alias: account_move_line__account_id. opw-4926547 Forward-Port-Of: odoo/enterprise#92240 Forward-Port-Of: odoo/enterprise#91683
This fixes an issue where Sendcloud delivery filters could fail when reading a shipping option identifier. Users should see more reliable Sendcloud delivery handling without invalid index errors interrupting the workflow.
Original PR description
Before this commit: `sendcloud_shipping_id` is of type `Object`. Trying to index the field was causing `invalid index error`. After this commit: Value is accessed correctly with the key `id`. opw-5011642 Forward-Port-Of: odoo/enterprise#92859
WhatsApp composer actions are now disabled when a conversation is inactive, preventing users from attempting actions that should not be available. This keeps the messaging experience consistent after recent changes to discussion actions.
Original PR description
Before this commit, whatsapp composer actions were enabled when the whatsapp conversation is inactive. This shouldn't be the case, and happened from the recent technical changes around discuss actions that affected composer actions. `showQuickAction` no longer exists in template. Commit puts the semantically equivalent code in composer action definition.
Expiration dates shown in the Barcode app are now displayed using the user's local timezone. This prevents products received with a midnight expiration time from appearing as expiring one day earlier, reducing confusion during warehouse receipt validation.
Original PR description
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the…
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the Purchase app - Create a new Request For Quotation - Select a product that: - is a good tracked by lot - has the `Expiration Date` field enabled (Inventory tab > Traceability) - Confirm the RFQ - Click the `Receipt` smart button - Click the `hamburger button` and enter an expiration date at midnight. - Go to the Barcode application > Operation > Receipts - Open the corresponding RFQ - Click Edit and increase the quantity to 1, then Validate - Observe that the date is displayed as one day earlier **Cause**: The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day. **Solution**: To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date. opw-4865513 Forward-Port-Of: odoo/enterprise#92109 Forward-Port-Of: odoo/enterprise#88526
This update corrects internal point-of-sale calls after a recent technical change, helping restaurant and UrbanPiper delivery workflows continue to behave as expected. It also updates related automated tests to match the corrected behavior, reducing the risk of checkout or ticket screen issues.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/enterprise#92696 Forward-Port-Of: odoo/enterprise#92091
When an applicant is hired through the salary configurator, their recorded skills are now transferred to the employee profile. This prevents HR teams from losing useful candidate information during onboarding and avoids manual re-entry.
Original PR description
Originally, an applicant, who became an employee through the salary configurator flow, loses his skill info. So, the migration of applicant information, through the salary configurator flow, to employee view has been adjusted. Forward-Port-Of: odoo/enterprise#92591 Forward-Port-Of: odoo/enterprise#87076
Reconciliation between a customer invoice and a vendor bill now keeps the correct partner on each accounting line. This prevents paid invoices and bills from being reflected under the wrong customer or vendor in reports such as the Partner Ledger.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#92909 Forward-Port-Of: odoo/enterprise#89972
Adds test coverage for a crash that occurred when users tried to Freeze and Share a spreadsheet containing an Odoo List from Documents. This helps ensure the sharing workflow remains reliable after the related fix in the community codebase.
Original PR description
Steps to reproduce: - Install documents_spreadsheet (enterprise) - Create a spreadsheet with an Odoo List - Open the document view - Select the spreadsheet - Click on "Freeze and Share" => Boom This commit contains only the test, the fix is done in the community PR. Task: 5025331 Forward-Port-Of: odoo/enterprise#92627
Users editing a Knowledge article will no longer lose unsaved work when another article is moved beneath it. The system now saves pending changes before reloading the article, reducing frustration and preventing accidental data loss.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Manufacturing users can now search for employees to assign without triggering errors caused by records from companies they cannot access. The employee picker is limited to employees in companies available to the current user, making work order assignment more reliable in multi-company setups.
Original PR description
Task ID: 5005753 Prev behavior: when searching for employees to assign (employee_assigned_ids) from the manufacturing page and using "Search More", it was raising an error bc it was fetching data even from employees part of companies he's not part of New behavior: added domain over employee_assigned_ids such that the accessed users are only the ones being part of a company the current user can access Forward-Port-Of: odoo/enterprise#92079
Payroll users can now edit validated work entries as long as those entries have not yet been included in a payslip. This helps teams correct payroll preparation mistakes earlier without weakening the protection around entries already used for payslip calculations.
Original PR description
Originally, the validated work entries cannot be modified, either they have been included in payslips or not. This logic has been adjusted to allow for modifying the work entries marked as "validated" if they are not linked to a payslip. Task #4921300 Forward-Port-Of: odoo/enterprise#89552
The Indian Payroll EPF report export now uses the correct date format when finding payslips. This prevents an error when users export the EPF report to XLSX after processing paid payslips.
Original PR description
Steps to Reproduce: - Install Indian Payroll Localization - enable the Provident Fund of the employee in Payroll tab of employee form view - Create a payslip of the employee and mark as paid - Try to export XLSX file of EPF report from the reporting menu Issue: - A traceback error occurs when click on 'Export XLSX File' report. Reason: - The domain used to search payslips uses an incorrect date format. Solution: - Use the correct date format for the search. task-5002518 Forward-Port-Of: odoo/enterprise#91920
The Indian Payroll yearly salary report now prints correctly when salary structure names are stored in multiple languages. This prevents an error that blocked payroll teams from generating the report after payslips were paid.
Original PR description
Steps to Reproduce:
- Install Indian Payroll Localization
- create a payslip of any employee and mark as paid
- try to print yearly salary report from reporting menu
Issue:
- A traceback error occurs when printing the yearly salary report.
Reason:
- the sturcture name is translatable field, which gives the value in a dict with the key as languages like {'en_US': 'India: Regular Pay'}.
- The error occurs because the code attempts to use this dictionary with setdefault, which expects a string.
Solution:
- Get the structure name corresponding to the appropriate language from the dictionary before passing it to setdefault.
task-5002518
Forward-Port-Of: odoo/enterprise#91901