Monday, August 25, 2025
15 changes · 18.0
Enhancements to existing features
When an Indian EDI e-invoicing retry is triggered, Odoo now records a message on the related accounting document. This helps businesses see which user retried the process, improving traceability especially when repeated requests can lead to temporary GST request blocks.
Original PR description
Following the implementation of [Black list request by GST](https://github.com/odoo/iap-apps/pull/1039) the users are blocked for 24 hours on generating too many request. When processing through EDI there is no log when clicked on the retry button, Which is more essentially needed now to know by which user the EDI was retried and we logged the same on the move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223886 Forward-Port-Of: odoo/odoo#207184
Resolved issues and error corrections
The Employee app resume section now keeps the skills table within its intended area, even when a resume entry contains a very wide table. This prevents resume content and action buttons like Add and Delete from being hidden, making employee profile editing more reliable.
Original PR description
Steps to reproduce:
1- Go on employee app
2- Click on resume section
3- Click on Add on resume tab
4- Put on description a big table with at least 20 columns
5- Save
The resume table and the buttons "add", "delete" with be hidden by the skill table.
Reason:
The skill table element is too wide
Solution:
The skill table's width is fixed and is contained in resume section element
task-4881917
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-prThis fix prevents errors when creating, updating, or validating work entries for employees with fully flexible schedules. It helps HR teams process these entries reliably when no fixed working calendar is assigned.
Original PR description
When we validate/write/create a work entry for an employee with a fully flexible working schedule, we can encounter a traceback when trying to call `_attendance_intervals_batch` on a non-existing calendar. To rectify this issue, we continue in the loop when no calendar is set. opw-4979974 opw-4968312
The Job Position form now shows eligible recruiters and interviewers even when no company is selected. This prevents hiring teams from seeing empty selection lists and makes recruitment setup smoother in multi-company environments.
Original PR description
In the Job Position form, the 'Recruiter' and 'Interviewers' fields were empty when no company was selected. This was due to the static domain using 'company_id' directly without taking into consideration that company_id can be False. This fix introduces computed domain fields (, ) that dynamically adapt based on the selected company. If a company is set, users belonging to that company are shown. If not, only internal users are listed regardless their companies. Related task: 4926154. 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#217884
This fixes an error that could appear after merging contacts and then selecting multiple contact records. Peppol-related contact information is now calculated separately for each contact, keeping contact management workflows from being interrupted.
Original PR description
**Steps to Reproduce:** 1. Install `account_peppol` and `contacts`. 2. Open the Contacts app (list view). 3. Select any two contacts and click on "Merge" from the "Actions" menu. 4. Open any of the merged contacts in form view. 5. Close the form view and click on "Add a line". 6. Select multiple records. **Error:** ValueError - Expected singleton: res.partner(11, 9) **Cause:** The method `_compute_available_peppol_eas` accesses `self.available_peppol_eas` directly. When multiple `res.partner` records were involved, it will raised a singleton error. **Fix:** Loop over each partner to compute `available_peppol_eas` for each. This prevents the singleton error when multiple records are processed. sentry-6807787390
The Italian localization now uses the updated €100 threshold for the VP7 line in VAT tax reports, replacing the previous €25.82 amount. This keeps tax reporting aligned with current requirements and reduces the risk of incorrect report values.
Original PR description
While implementing the modulo tag of the tax report xml export, it came to light that the vp7 line of that report which previously used a 25,82€ threshold has been changed for one at 100,00€. This commit adapts the amount across the module. --- Enterprise PR: https://github.com/odoo/enterprise/pull/86642 task-4826511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216887
Users returning from editing a shared project task are now taken back to the correct project instead of another project's task board. This prevents confusion when multiple shared projects are available and keeps the portal navigation aligned with the task being edited.
Original PR description
Steps to Reproduce: ------------- 1. Install project and create two projects and tasks. 2. Share both projects with edit access. 3. Edit a task from the portal view (Back to edit mode) then click the (back to tasks) button. 4. Instead of the correct project the page redirects to the another project kanban view. Issue: -------------- - When redirecting to a task from project sharing (edit mode – task form view) it redirects to a different project’s kanban view instead of the actual project. Cause: ------------- - In the portal view the URL is hardcoded with `id=1` instead of dynamically using the correct project ID. Fix: --------------- - pass the correct `project_id` in the URL instead of using a hardcoded value. The issue occurred from this PR-https://github.com/odoo/odoo/pull/174648 task-5031632
New recruitment candidates and applicants now create linked contacts using the candidate's name instead of falling back to the email address. This helps recruiters and other users identify people correctly in contact records, while related point-of-sale test updates help keep automated checks reliable.
Original PR description
after this commit when a candidate or applicant is created, the corresponding contact should display the candidate’s name correctly, rather than defaulting to the email address. task-4687196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Check validation now compares payments using the check's effective payment date instead of the operation date. This prevents valid customer receipts with already-issued checks from being incorrectly blocked or warned.
Original PR description
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with…
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with past payment dates. This commit changes the validation to use payment_date, which is the correct reference for ensuring that the payment operation is not prior to the last effective payment of the check. Description of the issue/feature this PR addresses: When validating check movements in `l10n_latam_checks`, the system compares the operation date (`date`) of the last check operation against the current payment date. This generates false blocking warnings in cases such as customer receipts, where checks can be received with past payment dates (already issued and ready to be deposited). Current behavior before PR: The validation uses `last_operation.date` for comparison. If the last operation's `date` is greater than the current payment's date, the system raises a warning, even if the check's `payment_date` is already in the past and valid. Desired behavior after PR is merged: The validation uses `last_operation.payment_date` instead of `last_operation.date`. This ensures that the comparison is consistent with the effective payment date of the check, avoiding false positives when processing checks in customer receipts. Video: https://drive.google.com/file/d/1Ro2NvKGK_uRyBovMuNeA395y-6MUbzu5/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops users from selecting the Shop Floor screen as their default home action. It prevents a login-time error that could appear when that screen opened before the system had loaded the current app context.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** On the js side, the Shop Floor action uses the `menu` service to get the name of the current app. when accessing the 'Shop Floor' action as a home action, the `menu` service app is set after the action is rendered, so the current app during rendering is undefined. **FIX** Prevent the user from selection the 'Shop Floor' action as a home action (we already do this for action that doesn't work as home action). opw-4926317
Installing the Belgium Accounting localization now continues successfully even if a referenced demo account tag was previously deleted. This avoids a setup failure in demo-data scenarios and makes localization installation more reliable for affected users.
Original PR description
Currently, installing the Belgium Accounting localization fails with an error, if the user has deleted referenced demo account tags. **Steps to reproduce:** - Install the Accounting app. - Delete the "Demo Capital Account" account tag. - Install the Belgium Accounting localization (`l10n_be`). **Error:** `ValueError - External ID not found in the system: account.demo_capital_account` At [1], if the `account.demo_capital_account` is not found, it raises an error if the external ID is missing. This commit prevents the error by explicitly passing `raise_if_not_found=False` and skipping the tag if not found. [1] - https://github.com/odoo/odoo/blob/71d1c9a4bef1c29485e3b0390713a9301ad6db4f/addons/l10n_be/demo/account_demo.py#L13-L19 sentry-6776341713 Forward-Port-Of: odoo/odoo#221227
The contract offer screen now hides the signature request button when the current user cannot access any related signature request. This prevents users from clicking a button that would lead to an error, while still allowing authorized users such as signing administrators to use it.
Original PR description
Before this PR, when logged in as a different user from the one responsible for counter-signing the contract, the smart button still showed, and clicking on it caused an error. This PR fixes that, by hiding the smart button when there are no accessible signature requests. Note that sign admins will still be able to see the smart button; users with access to the signature request. Task-4966129
Portal users viewing helpdesk tickets with logged timesheets will no longer see an unrelated Timesheets breadcrumb. This keeps ticket navigation clearer and avoids sending users toward the wrong portal section.
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
Product weight and volume information retrieved from barcode lookup is now properly saved on the product record. This helps keep product data complete and avoids missing logistics details after lookup.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so even when data was retrieved, it was not stored in the product record. After this commit: ----------------------- - We have added the weight and volume fields to ensure that whenever data is fetched, it is properly stored in the product record Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colomb
Original PR description
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#sales-journals) record 5. Send it with DIAN box checked Issue: -------- `Payment Means` and `Payment Method` are not translated to spanish(es_419). Cause: -------- After this 88d7e5a, the `<br/>` tag was removed and its related **.pot** and **.po** files were not updated. Solution: ----------- Apply the changes to the **.pot** and **.po** files to resolve the issue. opw-4790642