Daily updates from Odoo
Thursday, November 6, 2025
181 changes
21 changes
Resolved issues and error corrections
Fixed an issue where stock availability in the Barcode app did not refresh when a product or source location was changed. This ensures users see the correct stock quants when creating or editing internal transfers, reducing confusion and preventing incomplete picking decisions.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98850 Forward-Port-Of: odoo/enterprise#95906
This fix ensures that linked fields coming from inherited models are checked correctly for indexing when they connect to other records. As a result, the system can better detect missing indexes and help keep searches and data access efficient.
Original PR description
Many2one fields that originated from an `inherits` model were not linted for indexing if they were an inverse to a One2many field, because those fields on the inverse model have `store=False`. The Many2one field that needs to be indexed is the one on the delegated model. This commit fixes this by always getting the `base_field` for the inverse field - if it's an inherited field, it will use the source field; if not, it will use the field itself. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234530
This update corrects how the rental website sends customers to the next page after an action. It helps ensure users are redirected reliably, improving the checkout and browsing experience on rental pages.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/233842 Forward-Port-Of: odoo/enterprise#98760 Forward-Port-Of: odoo/enterprise#98492
This update corrects how several website shopping actions send users to a new page after an action is completed. It helps ensure customers are redirected reliably when updating the cart, wishlist, comparison, pricing options, or related website actions.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/98492 Forward-Port-Of: odoo/odoo#234297 Forward-Port-Of: odoo/odoo#233842
Archiving an employee with a departure reason now works without triggering an error. This fixes a traceback caused by tracking a rich text field, so HR users can complete the archive process reliably.
Original PR description
Steps to Reproduce: - Try to archive employee with departure reason. Issue: - `tracking=True` is not supported for fields.Html Fix: - Removed tracking on "departure_description" field. task-5164266 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes the total amount shown on export invoices for Turkish e-invoicing. For invoices marked "Registered For Export," the payable amount now correctly reflects the VAT deduction, so the generated XML matches the expected legal amount.
Original PR description
When the invoice's type is "Registered For Export", the total of the invoice which is shown in the cbc:PayableAmount node in XML, has to reflect the VAT deducted amount. This PR fixes the given issue. task-5159638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231221
This update prevents an error that could happen when scheduling or editing a meeting for an applicant if the user has no timezone set. If no timezone is available, the system now safely uses UTC so the meeting can be saved normally.
Original PR description
Currently, an error occurs when scheduling or updating a meeting for an applicant if the user's timezone is not set.
**Steps to Reproduce:**
1. In the user's profile, remove the TimeZone.
2. Now, install the "**Recruitment**" module.
3. Create an application and schedule a meeting for the applicant.
4. After saving the record, change the start time and try to save the record.
**Error:**
`AttributeError - 'bool' object has no attribute 'upper'`
**Cause:**
At [1], system gets the timezone from the context, but in this case, `'tz'` is `False`. As a result, `user_tz` becomes False, and using `upper()` method on a bool value triggers an error.
**Fix:**
This commit ensures that the 'UTC' timezone is assigned when the context does not include a valid timezone ('tz' is missing or False).
[1] - https://github.com/odoo/odoo/blob/78bd84c7b91f11780f152c29c8f595e3d9ed3d68/addons/calendar/models/mail_activity.py#L23
sentry-6952137101The website editor now prevents users from accidentally typing into the search bar input while editing a page in Firefox. This keeps the search bar behaving consistently across browsers and avoids unintended changes while designing pages.
Original PR description
Since the [html_builder refactoring], it's possible to type something inside of an input while in the edit mode on Firefox, which is not the expected behavior and which is not the case in other browsers, for example, Chrome. Steps to see the issue: - Open Website and start editing - Drop a searchbar - Click on the input - Type something => It will remove the searchbar and add text to the searchbar button. This happens because of the different behavior on Chrome and Firefox of `pointer-events`. When the input has `pointer-events` set to `none` Chrome blocks any activity on it, including `beforeinput` events, but Firefox doesn't. This commit fixes this problem making the input not `contenteditable`. task-5144517 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Single-day time off requests will now appear as a single-day event in the Calendar app. This fixes a display issue that could make leave requests look like they lasted two days in some time zones, reducing confusion for managers and employees.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#231662 Forward-Port-Of: odoo/odoo#224298
This update prevents Sign request emails from being resent when a contact’s email is changed only in letter case, such as uppercase to lowercase. It avoids confusing duplicate notifications for recipients and keeps email sending behavior more consistent.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
The appointment booking page now uses a configurable maximum for resource capacity instead of being capped at 12. This ensures businesses can offer and book higher-capacity resources correctly when needed.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#94935
This change prevents users from canceling a manufacturing order that has already been completed. Instead of silently canceling an associated stock transfer by mistake, the system now shows an error message to explain that the completed order cannot be canceled. This helps avoid confusion and protects the integrity of manufacturing and inventory records.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This fix stops users from canceling a manufacturing order that has already been completed. Instead of canceling the wrong related transfer, the system now clearly warns that a done manufacturing order cannot be canceled, avoiding confusion and incorrect stock operations.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/odoo#234126When a manufacturing order is split into a backorder, the shop floor screen now shows the correct quantity for the specific operation when the user opens the edit pop-up. This avoids confusion and helps operators record production accurately on each step.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#98036 Forward-Port-Of: odoo/enterprise#93599
Selecting an order line now works again when the certified scale module is installed. This restores the normal product screen behavior, so staff can tap a line to select it and use a long press for the configurator as expected.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely. Forward-Port-Of: odoo/enterprise#97992 Forward-Port-Of: odoo/enterprise#96980
The fullscreen view for course slides now correctly restarts the text highlighting interaction when enabled. This resolves a display issue that could cause highlighting to stop working properly for learners in later versions.
Original PR description
**Issue:** `this.websiteAnimateWidget` is undefined Also the fix wasn't working properly in later versions. This is due to an incorrect conflict resolution in the forward port of the related fix. **Fix:** The fix for websiteAnimateWidget was made obsolete in these versions with: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba But the original issue of `textHighlightWidget` was still present and not properly caught by the tour. The new fix add the fullscreen slide to the selector of the TextHighlight interaction which is restarted when fullscreen is enabled. related: https://github.com/odoo/odoo/commit/184c6f855f703239864f482ff252beb1293c343d opw-4978798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234107
Uninstalling certain modules could leave behind inconsistent technical records, which then caused errors or incorrect field settings after removal. This fix makes Odoo refresh the affected models properly during uninstall, so the database and metadata stay in sync and removals complete cleanly.
Original PR description
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation: For example, the…
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation:
For example, the 'appointment_account_payment' module that makes `calendar_event_id` not required anymore. After uninstalling it, the ORM will complain that the not-null constraint doesn't exist ("Missing not-null constraint on appointment.answer.input.calendar_event_id"). Also, if we look at the `ir.model.fields` record for `calendar_event_id`, it shows that the field isn't required, but it should be required again (with the correct constraints too).
Add the information of impacted models for the 'to remove' modules, and force the new registry to call `init_models` on them. This will handle constraints and reflection on `ir.model`/`ir.model.fields`. We can then remove the call to `check_tables_exist` (see 3058ca4121048796c38aad78e3e4f5ffde3530f5) since `init_models` will do the job correctly for impacted models.
Also remove a part of the uninstall hook of website because it forces reloading the registry too soon (warning of missing not-null constraint) and the uninstallation manages the case genericly (remove correctly `ir.model.fields` record of `res.config.settings.website_id`)
runbot-error-233770
Forward-Port-Of: odoo/odoo#234364This fix prevents a crash when a purchase warning is shown for a contact that has no name. It ensures purchase orders and vendor invoices can still be created normally, even if the related partner record is incomplete.
Original PR description
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure…
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure Interior` Contact > In Contact, Add Contact > Type: invoice > Save & close - Add warning in newly created contact - Create a purchase order with the newly created partner and create an invoice with the newly created partner Traceback: `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/purchase_order.py#L298 https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/account_invoice.py#L131 Here, `partner_id.name` is `False`, which leads to string concatenation with a boolean in purchase warning messages and results in the above traceback. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231603
Opening the avatar popover for an archived employee no longer triggers an error. This fixes a usability issue in Planning and ensures archived records are displayed properly when users view employee details.
Original PR description
**Steps to reproduce:** - Open the Planning app. - Archive an employee. - Open the archived employee's avatar popover. **Current behavior before PR:** Opening the popover raised an error because `get_avatar_card_data` returned an empty list for archived records. This occurred since `search_read` ignored inactive records by default. **Desired behavior after PR is merged:** The method now uses `read` instead, ensuring archived records are properly handled without error. enterprise PR: https://github.com/odoo/enterprise/pull/98230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231184
This change prevents an error when opening the avatar popover for an archived employee in Planning. It adds a safety check so missing data no longer causes a traceback, improving reliability for users who view archived staff records.
Original PR description
Purpose of this PR: A guard has been added in the override of `get_avatar_card_data` to handle empty results and prevent traceback errors when data is missing. community PR: [odoo/odoo#231184](https://github.com/odoo/odoo/pull/231184) Forward-Port-Of: odoo/enterprise#98230
This change prevents the expense report title from appearing twice when printing PDFs with DIN5008-formatted localizations, such as German. It adds a small compatibility module so the report uses the correct document title and produces cleaner, more readable expense documents.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a value `din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to extend the expense sheet report and set the `din5008_document_title` to `Expenses Report`. opw-4314414 Forward-Port-Of: odoo/odoo#234686 Forward-Port-Of: odoo/odoo#212923
13 changes
Resolved issues and error corrections
This update prevents sign request emails from being resent when a contact’s email address is changed only in letter case, such as upper- or lowercase. It avoids sending unnecessary duplicate emails to the same recipient and reduces confusion for users.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
This change removes an unnecessary test flag from the self-order kiosk tour. It prevents a debug-mode issue in local environments, helping the test flow run cleanly without affecting normal use.
Original PR description
In this commit: - Removed the `test: true` flag from the `test_kiosk_cart_restore_and_cancel` tour. - The flag is not required for tours and can cause issues when running in debug mode. - This issue only occurs in local environments when debug mode is enabled. - After this fix, no issue is generated in debug mode.
This fix prevents an error when users open the AI chat from the email composer and their profile has no timezone set. If no timezone is available, the system now safely uses UTC instead, avoiding a broken compose experience.
Original PR description
Currently, an error occurs when opening the AI chat from the mail composer if the user's timezone has been removed. **Steps to Reproduce:** 1. Install AI and Purchase modules. 2. In the user's profile, remove the 'TimeZone'. 3. Open any purchase order and click on _Send PO_. 4. In the _Compose Email_ form, click on AI icon. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The issue occurs because `self.env.user.tz` returns False when the user's timezone is not set, causing an error when it tries to use `upper()` method on bool value. **Fix:** This commit fixes the issue by defaulting to the UTC timezone when the user's timezone is not set. **Ref:** https://github.com/odoo/odoo/blob/0f40ea82a1332f0e7168d861ad446b7316ab03de/odoo/addons/base/models/res_partner.py#L225-L228 sentry-6961379038
The employee time off dashboard now correctly displays Extra Hours allocations when an employee has attendance-based overtime. This fixes a visibility issue so managers and employees can see the full balance available to them.
Original PR description
### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ### Cause: When we are getting the allocation data we check for the leave types that require allocation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays/models/hr_leave_type.py#L473 And then when checking the types that doesn't require allocation we are looping on the res that we got from the super which already excluded those types https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays_attendance/models/hr_leave_type.py#L41-L43 ### Fix: We loop over the self leave types to make sure we are getting all of the employee's leave data whether the type requires allocation or not. opw-5042325 Forward-Port-Of: odoo/odoo#225015
This change prevents the expense report title from appearing twice when printing PDFs for the DIN5008 format. It does this by providing the correct document title for expense reports, so the printed output looks clean and professional.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a value `din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to extend the expense sheet report and set the `din5008_document_title` to `Expenses Report`. opw-4314414 Forward-Port-Of: odoo/odoo#234348 Forward-Port-Of: odoo/odoo#212923
This fix prevents the chat hub from becoming hidden behind newly opened chat windows. It also stops the hub from being dragged while chats are open, making chat navigation more reliable for users.
Original PR description
Prior to this commit, moving the chat hub could cause newly opened chat windows to appear on top of it, rendering the hub invisible and unusable. This commit fixes the issue by resetting the chat hub's position whenever a chat window opens and disabling its drag functionality while any chat window remains open. task-5227499
Completed manufacturing orders can no longer be canceled by mistake. If a user tries to cancel one, the system now shows an error instead of canceling the related stock transfer, which avoids confusion and protects the integrity of manufacturing records.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/odoo#234126This fix restores employee selection in forms for users who do not have full Employees access, especially in mobile and Studio-created fields. It prevents the employee picker from showing no results when employee photos or avatar fields are involved.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#197575
Completed manufacturing orders can no longer be canceled by mistake. If a user tries to cancel one, the system now shows a clear error instead of canceling a related stock transfer, which avoids confusing and incorrect inventory actions.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This update corrects how text highlighting behaves when a course is shown in fullscreen. It ensures the highlight interaction restarts properly in fullscreen mode, so the feature works reliably for learners.
Original PR description
**Issue:** `this.websiteAnimateWidget` is undefined Also the fix wasn't working properly in later versions. This is due to an incorrect conflict resolution in the forward port of the related fix. **Fix:** The fix for websiteAnimateWidget was made obsolete in these versions with: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba But the original issue of `textHighlightWidget` was still present and not properly caught by the tour. The new fix add the fullscreen slide to the selector of the TextHighlight interaction which is restarted when fullscreen is enabled. related: https://github.com/odoo/odoo/commit/184c6f855f703239864f482ff252beb1293c343d opw-4978798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234107
This update changes the test setup so a new loyalty program is created from scratch instead of reactivating an old one. It prevents previously disabled reward items from coming back unexpectedly, which keeps the test behavior stable and reliable.
Original PR description
## Versions 18.3+ ## Issue Tests fail due to free product rewards being reintroduced when a loyalty program is reactivated. ## Cause Reactivating a loyalty program also reactivates its child records, including default rewards. See: https://github.com/odoo/odoo/blob/f03ff6d9b727a22e3b250a5c9cc875b9f1f16263/addons/loyalty/models/loyalty_program.py#L513-L518 ## Fix Create a new loyalty program instead of reactivating an existing one. runbot-232709
Fixed an issue where opening the avatar popover for an archived employee in Planning could fail. The system now correctly reads archived records, so users can view employee details smoothly without encountering an error.
Original PR description
**Steps to reproduce:** - Open the Planning app. - Archive an employee. - Open the archived employee's avatar popover. **Current behavior before PR:** Opening the popover raised an error because `get_avatar_card_data` returned an empty list for archived records. This occurred since `search_read` ignored inactive records by default. **Desired behavior after PR is merged:** The method now uses `read` instead, ensuring archived records are properly handled without error. enterprise PR: https://github.com/odoo/enterprise/pull/98230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231184
This change prevents an error that could appear when users open the avatar popover for an archived employee in Planning. It adds a safeguard so the system handles missing data gracefully instead of showing a traceback, improving reliability for everyday use.
Original PR description
Purpose of this PR: A guard has been added in the override of `get_avatar_card_data` to handle empty results and prevent traceback errors when data is missing. community PR: [odoo/odoo#231184](https://github.com/odoo/odoo/pull/231184) Forward-Port-Of: odoo/enterprise#98230
4 changes
Resolved issues and error corrections
This update prevents Shiprocket from failing when GST-specific tax tags are not available, which can happen in installations without the Indian localization module. It also makes the related test more reliable by explicitly using a 15% tax, ensuring the behavior stays consistent across environments.
Original PR description
Some other test adds a fiscal position with tax mapping. This creates 2 problems 1. The new taxes have a tag, which means we evaluate the right hand of…
Some other test adds a fiscal position with tax mapping. This creates 2 problems
1. The new taxes have a tag, which means we evaluate the right hand of
https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239
However, since l10n_in is not installed,
`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`
does not return anything (False is not a fallback)
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588
So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558
2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true
Solution
-----
1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test
-----
runbot-232692
Forward-Port-Of: odoo/enterprise#97998Completed manufacturing orders can no longer be canceled by mistake. Instead, the system now shows an error message, avoiding the accidental cancellation of related stock movements and keeping manufacturing records consistent.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This change prevents an access error that could appear when opening the Documents app after a company was archived. It ensures users only load folders they are still allowed to access, making the app more reliable in multi-company setups.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278 Forward-Port-Of: odoo/enterprise#96817
This fix restores the ability to post Italian tax closing entries when the tax period is set to quarterly. Previously, the system incorrectly blocked these returns by applying a rule meant only for monthly filings, which could prevent users from completing a valid quarterly closing.
Original PR description
A [previous PR](https://github.com/odoo/enterprise/pull/86642) improved the XML export of tax returns with Italian localization. This introduced a bug if the tax period is set quarterly. Currently, it prevents a tax return move from being posted if it detects previous tax closings, but there are none in the previous month. This should only be the case if the tax period is set monthly. Steps to reproduce on runbot: - Install the l10n_it_xml_export module - Switch to an Italian company and set the tax period to `quarterly` - Create a closing entry for the previous quarter - Try to create a closing entry for the current quarter Related ticket: opw-5156791 Forward-Port-Of: odoo/enterprise#99002 Forward-Port-Of: odoo/enterprise#98241
23 changes
Resolved issues and error corrections
This change corrects how the website builder keeps the selected Products List Page option when settings are updated. It helps ensure the page continues to use the intended option without unexpected changes.
Original PR description
In PR https://github.com/odoo/odoo/pull/233696, we forgot to add an applyTo to keep the same target's option. This commit will fix the issue by adding the missing applyTo.
This change prevents the Point of Sale session from failing when an order line has a 100% discount. It ensures sessions can be closed normally, avoiding interruptions for staff and delays in end-of-day operations.
Original PR description
Before this commit, when an order line had a 100% discount, a division by zero error occurred when closing the PoS session. opw-5240429
This update fixes an error that could block sending Romanian e-Factura invoices when a bank account is linked to the payment details. The system now correctly uses the bank’s own address field, so invoice submission works as expected.
Original PR description
Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for…
Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.
Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.
Video:
https://drive.google.com/file/d/1rweJgknjbKrpouJRTQ2cluKHsIXNZtSz/view?usp=drive_link
Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.
Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.
Test:
Linked the bank in the test suite. The test fails without this fix, confirming the issue is resolved.
opw-5099816
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231399This fix prevents the delivery date on an invoice from being unexpectedly changed when the invoice is confirmed in anglo-saxon accounting flows. It helps ensure the delivery information stays accurate for invoiced sales orders, avoiding confusion and manual correction.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable anglo-saxon accounting; 2. have a product category with automated AVCO; 3. assign category to a deliverable product; 4. set product to invoice on…
Versions
--------
- 17.0+
Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.
Issue
-----
The delivery date gets reset.
Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.
Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.
opw-4965036
Forward-Port-Of: odoo/odoo#231186This change prevents an error that could appear when asking for feedback on an appraisal if a survey was restricted to certain users. The system now only shows surveys the current user is allowed to access, so the wizard works reliably and avoids a confusing access failure.
Original PR description
To reproduce (on runbot): - As 'admin' user: * Create a survey of type 'Appraisals' and name it 'Test No Access' * Set `Restricted to' to 'admin' user only. - As 'demo' user: * Create an appraisal for another employee * Click on "Confirm" button * Click on "Ask Feedback" button * Try to choose an Employee. An exception is raised saying we don't have 'read' access to the survey 'Test No Access'. This commit force computing `survey_template_id` as non-superuser only get survey that the user has access to.
The Website editor’s gradient color picker now displays custom text more clearly in dark mode. This fixes a readability issue by increasing contrast, making the interface easier to use without changing the available options.
Original PR description
Steps to Reproduce: 1. Go to `Website` and enter edit mode. 2. Drop any `text` snippet. 3. Select the text. 4. Open color picker from the toolbar and switch to `gradient` tab. Issue: The custom text…
Steps to Reproduce: 1. Go to `Website` and enter edit mode. 2. Drop any `text` snippet. 3. Select the text. 4. Open color picker from the toolbar and switch to `gradient` tab. Issue: The custom text in the gradient tab of the color picker was not clearly visible in dark mode. Reason: The background is already light, and in dark mode the text color was also light. This resulted in insufficient contrast, making the text hard to read. Fix: Set the text color to black when button has no background image. In case of button containing style of background-image, the text color will be same as earlier. | Before | After | |-----------------------------|---------------------------------| | <img width="483" height="274" alt="image" src="https://github.com/user-attachments/assets/911c53f2-bb0e-4d70-9fb2-078ac17388c1" /> | <img width="473" height="326" alt="image" src="https://github.com/user-attachments/assets/c976fb49-6c10-47c0-b559-6a58cfcbcdc2" /> | Forward-Port-Of: odoo/odoo#227938
This update corrects how Spanish electronic invoicing tax data is loaded so the right tax settings are available during setup. It also prevents tax values from being applied to unrelated taxes, reducing the risk of incorrect tax configuration.
Original PR description
Currently the tax data defined in l10n_es_edi_facturae is incomplete and never loaded. This commit makes sure that the l10n_es_edi_facturae_tax_type is loaded correctly and adds the appropriate templates for es_common_mainland and es_canary_common. The default is also removed on the field l10n_es_edi_facturae_tax_type to avoid the value being assigned for unrelated taxes. task-4981325 Forward-Port-Of: odoo/odoo#232911 Forward-Port-Of: odoo/odoo#231277
This change updates an internal description so it matches how self-service point-of-sale orders are actually numbered. It does not change how orders work for customers, but it helps keep the code and documentation aligned for future maintenance.
Original PR description
**Description of the issue/feature this PR addresses:** When calculating the order's `order_reference`, we'd use the order's `table.id` as the reference's middle constituent. This was changed in 16.5 in [odoo/odoo:e512634935aa](https://github.com/odoo/odoo/pull/133902), from when on we used the order's `config.id` instead of its table - but the docstring was never updated to reflect the change. This commit fixes that. **Current behavior before PR:** Docstring referenced the table.id **Desired behavior after PR is merged:** Docstring references the config.id. The whole pos_reference generation was revamped in [odoo/odoo:76336f6123a6](https://github.com/odoo/odoo/pull/183085) in 18.1, so this only affects versions 17.0 and 18.0.
This change corrects how website sale pages redirect users after an action, making sure the browser is sent to the intended web address. It helps avoid broken or inconsistent navigation for shoppers and improves the overall checkout and browsing experience.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/233842 Forward-Port-Of: odoo/enterprise#98804 Forward-Port-Of: odoo/enterprise#98492
This fix ensures that when an upgrade is started and then canceled, the add-on’s status is properly reset. This prevents the system from showing an incorrect module state and helps keep module management reliable.
Original PR description
There is a typo in Odoo 19 and master: module state is not reset when upgrade action is aborted. 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
This fix prevents a rare crash that could happen when a network request was still running and the cache was refreshed at the same time. It ensures the system clears all related tracking information, so repeated requests behave safely and the web interface remains stable.
Original PR description
PR [1] recently reworked the `read` function of RPCCache to better handle rejected promises. Unfortunately, it introduced a small regression producing a crash in a specific scenario: - do an rpc - during the rpc (before it returns), invalidate the cache - still during the rpc, do that same rpc again (same params). Before this commit, it crashed because we didn't clear the `pendingRequests` structure, whereas the ramCache was emptied. In `read`, we assume that if there's a pending request, there's an entry in the ram cache for that request, which is a correct assumption, except in that faulty scenario. With this commit, pending requests are also cleared upon invalidation. [1] odoo/odoo#233610 runbot error~233763 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
Changing a contact’s email address from lowercase to uppercase, or the other way around, no longer triggers duplicate signature request emails. This prevents unnecessary repeated messages to people who have already received a signing request, reducing confusion and email noise.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
Fixed an issue where event registration forms could fail if users took more than a couple of minutes to complete them. The reCAPTCHA check is now generated at submit time, so the form stays valid and can be submitted successfully even after a longer delay.
Original PR description
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Task-4982067 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#233517 Forward-Port-Of: odoo/odoo#223538
This update corrects the quantity displayed when editing a production step on the shop floor after a backorder is created. Users will now see the amount needed for that specific step, instead of the total remaining quantity for the whole manufacturing order, which prevents confusion and mistakes.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#98036 Forward-Port-Of: odoo/enterprise#93599
Guests who have not been online recently will no longer be notified when a call starts. This reduces unnecessary alerts and avoids contacting people who are unlikely to be available.
Original PR description
With this commit, guests who haven't been online in the last 12 hours will not be notified of a call starting. task-5136330 backport of https://github.com/odoo/odoo/pull/230337 Forward-Port-Of: odoo/odoo#233969 Forward-Port-Of: odoo/odoo#233221
This change removes a Windows-specific version pin that was preventing the IoT box image from installing correctly. As a result, Windows users can now install the required dependency using the latest compatible version, improving setup reliability.
Original PR description
Forcing aiortc version to 1.4.0 on windows made it impossible to install, we then removed the marker to install the latest.
This change fixes an issue in call participant status where the same deafened state could appear twice in the sidebar. It makes the display clearer by showing only one icon when a participant is deafened, since that already means they are muted.
Original PR description
**Current behavior before PR:** The PR #228657 combined the mute and deafen actions into a single "mute" action handling both states, As a result, when a user was both muted and deafened during a…
**Current behavior before PR:** The PR #228657 combined the mute and deafen actions into a single "mute" action handling both states, As a result, when a user was both muted and deafened during a call, two identical deaf icons were shown in the participant status area (in sidebar). **Steps to reproduce:** 1. Start a call 2. Click the Mute button 3. Open Voice Settings dropdown 4. Click Deafen button 5. Observe two deaf icons in the sidebar participant status **Desired behavior after PR is merged:** Only one deaf icon is shown when the user is deafened, since the deaf state already implies being muted. **Before:** <img width="387" height="113" alt="image" src="https://github.com/user-attachments/assets/65be3365-0c7a-4d97-9260-1f440ce09c70" /> **After:** <img width="385" height="119" alt="image" src="https://github.com/user-attachments/assets/bd83fe67-d4b2-4756-9445-5f48ef3a8b5e" /> task-[5166621](https://www.odoo.com/odoo/project/1519/tasks/5166621) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures barcode transfers refresh the available stock quantities when a product or source location is changed. As a result, users will now see the correct stock information immediately instead of missing quants in the barcode interface.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98900 Forward-Port-Of: odoo/enterprise#95906
This fix stops users from canceling a manufacturing order that is already completed. Instead of affecting related stock moves by mistake, the system now clearly warns that a done manufacturing order cannot be canceled. This helps avoid confusion and protects completed production records from unintended changes.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This update prevents purchase warnings from failing when a contact has no name. As a result, users can create purchase orders and related invoices for such contacts without encountering an error, improving reliability in an edge case.
Original PR description
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure…
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure Interior` Contact > In Contact, Add Contact > Type: invoice > Save & close - Add warning in newly created contact - Create a purchase order with the newly created partner and create an invoice with the newly created partner Traceback: `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/purchase_order.py#L298 https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/account_invoice.py#L131 Here, `partner_id.name` is `False`, which leads to string concatenation with a boolean in purchase warning messages and results in the above traceback. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231603
This change makes a stock-related database query more efficient when a company has a very large number of locations. It helps prevent slowdowns and query processing issues, improving performance and reliability in large databases.
Original PR description
In the `_read_group`s on https://github.com/odoo/odoo/blob/704405b1af4cd80f0687712d280baf5b536bdc84/addons/stock/models/product.py#L203-L204 when there are too many locations (37K on a real DB) the `Domain.OR` variant leads to a very big query that runs too slow. Even the query planner has issues parsing with it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change stops users from canceling manufacturing orders that are already done. Instead of silently canceling the related stock transfer by mistake, the system now shows an error so users know the order cannot be canceled.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/odoo#234126When a graph view search returns no results, Odoo now shows the custom empty-state message configured for that action instead of the generic default one. This makes the screen message match the context set by the business and avoids confusing users.
Original PR description
Before this commit: In the graph view, when performing a search that yields no matching data, the default no content helper is shown even if a custom no content helper has been provided for that action window. After this commit: The provided no content helper for the action window is displayed instead. task-5136801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234320
13 changes
Resolved issues and error corrections
This update corrects how candidate contact records are named when an email address contains capital letters. It ensures the contact name uses the candidate’s entered name instead of accidentally showing the email address, improving the accuracy and readability of recruitment records.
Original PR description
Issue: In this issue, applicant's partner's name is not set correctly, if email contains capital letter. To reproduce: 1- Create a db with hr_recruitment installed. 2- In Recruitment app, create an…
Issue: In this issue, applicant's partner's name is not set correctly, if email contains capital letter. To reproduce: 1- Create a db with hr_recruitment installed. 2- In Recruitment app, create an application with a capital letter in email address 3- Navigate to contact's form. As you see the display name is set as the email. 4- If you do the same with a lower case email, the display name is set as the name filled in application form Cause: Inside `partner_id.find_or_create` the email is normalized: https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/mail/models/res_partner.py#L89-L94 And it is used as the partner's name. Here it is desired if the name is same as email, then we set the partner's name to candidate.partner_name: https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/hr_recruitment/models/hr_candidate.py#L119-L121 However, if the email_from is not normalized intially, the condition will not be taken. As a result the name will remain as email. opw-5162490
This change fixes a validation error that could appear during database migration when a tax distribution total was zero. It makes the validation check handle that case correctly, avoiding an unnecessary traceback and helping migrations complete smoothly.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines raise ValidationError(_("Invoice and credit note distribution should have a total…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines
raise ValidationError(_("Invoice and credit note distribution should have a total factor (+) equals to 100."))
odoo.exceptions.ValidationError: Invoice and credit note distribution should have a total factor (+) equals to 100.
```
- During the database migration, a traceback occurs because the [total_pos_factor](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L558) is being calculated as 0. When this happens, the float_compare [function](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L559) returns -1, which incorrectly satisfies the validation condition and triggers a ValidationError.
- To resolve this, we need to add an additional condition to check whether total_pos_factor is 0, similar to the condition already implemented [here](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L562) in the code.
tbg-1970
opw-5228357
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change fixes an issue where vendor credit notes sent to MyInvois could be rejected if the original bill had a custom reference. Odoo now uses the stored reference from the original e-invoice, helping credit notes validate correctly and avoiding submission errors for users.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#234199
Sales orders linked to deliveries will now be marked as invoiced once no further picking actions are expected, even if the full quantity was not delivered. This keeps order status more accurate and avoids orders appearing open when they are effectively complete from a billing perspective.
Original PR description
If no other operations are expected on the picking, even if the full quantity wasn't delivered, the order should be marked as invoiced. task-4607401 Fixes #144485 Partial revert of #115871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218322
Web notifications no longer show the raw URL when someone mentions a user or channel in a message. This makes notifications cleaner and avoids confusing or distracting link text for recipients.
Original PR description
BACKPORT Before this commit: When a user mentioned a channel or another user in a message, the web notification displayed the mention URL on the recipient’s side, causing a UI issue. After this commit: This commit resolves the issue by hiding the mention URL in web notification when a user mentions a channel or another user in a message. original-commit: 116b9d78ae74b6cd4884e62ba1eefe6af328d148 Forward-Port-Of: odoo/odoo#226337
This update prevents an error that could appear when opening a partner record after uninstalling an e-invoicing module. It now clears the related e-invoice format reference so users can continue working without seeing a traceback.
Original PR description
Before this fix, if you uninstalled this module and navigated to any partner that had a e-invoice format defined by this module, you'd have a traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12168 OPW-5172861
This fix ensures that when a subcontracted product is drop-shipped, its stock valuation does not leave behind leftover values that could distort future costing. It keeps accounting and inventory valuations accurate for FIFO, average cost, and standard cost products.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#233041
This update makes lot and serial number visibility in the barcode app match the Manufacturing setting for showing reserved lots/SNs. As a result, users only see this information when it is expected, which reduces clutter and lowers the risk of picking or scanning mistakes.
Original PR description
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs…
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs option was enabled in the Manufacturing settings. Steps to Produce: ------------------------------------- - In Manufacturing settings, disable the Show Reserved Lots/SNs option. - Create a Manufacturing Order and reserve component lots. - Go to the barcode app - Lots/SNs appear even though the Show Reserved Lots/SNs option is disabled. After this Commit: ------------------------------------- A correct value is now passed to the condition controlling the lot and serial number visibility. Lots/SNs are shown only when Show Reserved Lots/SNs is enabled in Manufacturing settings, or when they have been picked or scanned, helping users focus only on relevant information and reducing the chance of picking or scanning mistakes. Task Id: [3908929](https://www.odoo.com/odoo/project/966/tasks/3908929)
Returns for mixed products now go back to the correct supplier location, while subcontracted items still use the subcontracting location. This prevents returned goods from being sent to the wrong place and avoids confusion in supplier handling.
Original PR description
Steps to reproduce the bug: - Create a storable product "P1" and "P2" with vendor "azure interior" - for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1" -…
Steps to reproduce the bug: - Create a storable product "P1" and "P2" with vendor "azure interior" - for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1" - Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2 - Validate the receipt - Create a return for both P1 and P2 Problem: A picking is created with destination location set to the subcontracting location for both products, instead of setting the partner location only for subcontracted products. Solution: Ensure only the move line for subcontracted products uses the subcontracting destination location, while other returned products go back to the supplier location. When the `picking_id.partner_id`` is changed, it triggers a write on the picking, which in turn triggers a write on its moves, but only on the ones that are not scrapped. However, since the `scrapped`` field is a stored computed field, and as it hasn't been accessed before, it needs to be computed. And because its computation depends on `location_dest_id`, that field also needs to be recomputed. as a result, the `location_dest_id`` of the moves that we manually set may be changed unexpectedly. Therefore, in the `_create_return`` function, we check that the picking’s `partner_id` is different from the moves’ partner_id before updating it, to avoid unnecessary writes and the chain of recomputations that could alter our values. Resetting the picking’s partner_id based on the move’s partner_id could actually be removed in master, as it serves no real purpose, the move.partner_id itself is already derived from the picking’s partner_id. We just keep it in stable versions to avoid any unexpected behavior changes. opw-5208289
When a guest joins a meeting from the welcome page and changes their name, the updated name now appears right away in the meeting member list. This makes participant lists more accurate and avoids confusion for meeting hosts.
Original PR description
**Steps to Reproduce:** - Login with Admin, start a meeting, open the member list. - Join the meeting with a guest, using the invite link. - Change the guest name from the welcome page. - Admin member list doesn't show updated guest name. **Current behavior before PR:** Before this PR, the guest appeared as `Guest` in the member list even after updating their name on the welcome page. **Desired behavior after PR is merged:** This PR ensures the guest name is updated and displayed instantly upon joining, providing a smoother and more consistent experience. task-[5062702](https://www.odoo.com/odoo/project/1519/tasks/5062702) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When editing and saving website forms, temporary Turnstile loading elements and disabled states are now removed before the page is saved. This prevents unwanted button changes from being stored and ensures forms still work correctly if the Turnstile module is later removed.
Original PR description
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g. contact form) and save the page. 5. Notice that the form’s submit button temporarily shows a spinner and gets a 'disabled' class while Turnstile is initializing. 6. After saving the page, these temporary elements and classes (e.g. .turnstile-spinner and 'disabled') are incorrectly saved into the form’s HTML. 7. If you later remove or uninstall the website_cf_turnstile module, the submit button remains disabled and the spinner icon still appears, even though Turnstile is no longer active. After this commit: Now, when you save a website form in the editor, any temporary classes or elements added by Cloudflare Turnstile are removed. This prevents unwanted changes from being saved to forms. task-4951470 Forward-Port-Of: odoo/odoo#221841
The search feature now correctly handles words that change length during language normalization, such as in Thai. This prevents search results from being missed or search logic from failing in those cases.
Original PR description
The fuzzy search mechanism (specifically the _match utility) calculates the length of the string before normalizing it (e.g., with `unaccent`). However, `unaccent` can remove non-spacing marks (like Thai tone marks or vowels), which changes the length of the string. This mismatch caused the search loop to iterate past the end of the normalized string, leading to incorrect behavior or potential errors. This commit moves the length calculation to after the string has been unaccented, ensuring the loop has the correct bounds. opw-5189276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233249
This fixes an issue in the Italian tax export flow that could wrongly block quarterly tax return closings. Quarterly filings can now be posted correctly even when there is no closing entry in the previous month, which restores the expected accounting process for affected companies.
Original PR description
A [previous PR](https://github.com/odoo/enterprise/pull/86642) improved the XML export of tax returns with Italian localization. This introduced a bug if the tax period is set quarterly. Currently, it prevents a tax return move from being posted if it detects previous tax closings, but there are none in the previous month. This should only be the case if the tax period is set monthly. Steps to reproduce on runbot: - Install the l10n_it_xml_export module - Switch to an Italian company and set the tax period to `quarterly` - Create a closing entry for the previous quarter - Try to create a closing entry for the current quarter Related ticket: opw-5156791 Forward-Port-Of: odoo/enterprise#98241
7 changes
Resolved issues and error corrections
This fix prevents mention URLs from appearing in web notifications when someone mentions a user or channel in a message. It improves the notification display and removes an unwanted visual issue for recipients.
Original PR description
BACKPORT Before this commit: When a user mentioned a channel or another user in a message, the web notification displayed the mention URL on the recipient’s side, causing a UI issue. After this commit: This commit resolves the issue by hiding the mention URL in web notification when a user mentions a channel or another user in a message. original-commit: 116b9d78ae74b6cd4884e62ba1eefe6af328d148
WhatsApp messages sent from Odoo will now show web links only once instead of repeating them. This makes messages clearer and avoids confusion for recipients when a link is shared.
Original PR description
[FIX] whatsapp: remove duplicated URLs in message body Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the…
[FIX] whatsapp: remove duplicated URLs in message body Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="[https://example.com">https://example.com</a>`](https://example.com"%3Ehttps//example.com%3C/a%3E%60). Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in https://github.com/odoo/odoo/commit/a152910e3a352516ea1240d8833a406b144382dd and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. Related: https://github.com/odoo/odoo/pull/226337 opw-4936400
This change adds a validation step before an invoice is posted to ensure its line accounts belong to the same company as the invoice. It helps prevent cross-company accounting errors that could otherwise lead to incorrect postings and inconsistent financial records.
Original PR description
**Steps to reproduce:** - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A. - On the same invoice, change the company to Company B and change the journal to a journal of Company B. - Save, then confirm the invoice. **Issue:** The invoice, now belonging to Company B, still has the same account from company A, and we are able to post it on the journal from company B. **Solution:** Adding a step to check if the companies are correct on the move lines before posting. opw-5167958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the Carta Porte printout uses the same shipment identification data that was already validated and sent to the government. As a result, the PDF and QR code stay consistent each time the document is printed, avoiding confusion and mismatch issues.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648
This change fixes an error that could appear when scanning the packaging of a kit variant in the barcode app. It ensures the system recognizes the correct product behind the packaging, so warehouse operations continue smoothly without interruption.
Original PR description
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product KIT with 2 variants (for instance add the color attribute with the "white" and "black") - Crete a kit bom for…
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product KIT with 2 variants (for instance add the color attribute with the "white" and "black") - Crete a kit bom for this product: 1 x COMP - Go to Inventory > Configuration > Products > Product Packagings - Create a new packaging for KIT (white) with barcode XXX - Create a receipt for 1 unit of KIT (white) - Go to the barcode app > scan your receipt - Scan XXX #### > Error: Record product.product doesn't exist in the cache, it should return by the server ### Cause of the issue: Since commit c3fdc6e07fe7704340691fcc1bd7ed3cfb19abaf, the packaging related to KIT (white) is added to the barcode cache by the `_get_stock_barcode_data` (which was necessary to solve the related issue): https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode_mrp/models/stock_picking.py#L9-L18 However, the `KIT (white)` product itself is not be present in the cache as only products present in move lines are added the barcode cache when opening the operation in barcode: https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/models/stock_picking.py#L93-L95 This causes the issue as the package scans find the packaging in the barcode cache but can not recover its related product from it aswell: https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L988-L990 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L1251-L1252 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/lazy_barcode_cache.js#L75-L80 opw-4852875
This change stops the product system from clearing cached data when nothing has actually changed. It helps the application do less background work, which can improve responsiveness and reduce unnecessary processing.
Original PR description
Description of the issue/feature this PR addresses: Method `product.template._create_variant_ids()` triggers a `write()` on `product.product.product_template_attribute_value_ids` which will, in turn, invalidate the cache. This cache invalidation is unnecessary if the new value is the same as the old value. 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
Branch companies can now use the online payment providers configured on their parent company. This fixes an issue where customers could not complete portal payments from sales orders created in a branch company because no compatible provider was found.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a published payment provider; 2. create a branch company; 3. create a sales order in branch company; 4. enable online payment for sales order; 5. open sales order in portal view; 6. attempt to pay. Issue ----- No compatible payment providers found. Cause ----- The `payment.provider._check_company_domain` is set to the default exact match, so when it's used in `_get_compatible_payment_providers`, it's unable to find any providers for the branch company. Solution -------- Set `_check_company_domain` to `check_company_domain_parent_of`. opw-5214269