Thursday, October 9, 2025
8 changes · 17.0
Resolved issues and error corrections
Inventory barcode scanning now correctly accepts different products that happen to use the same serial number in GS1 barcodes. This prevents an error that previously stopped the second product from being added to an inventory count.
Original PR description
**PROBLEM** When scanning two gs1 barcode with the same serial number, but for different products there is an error and the 2nd product is not added to the inventory count. **STEP TO REPRODUCE** 1. install stock_barcode 2. activate the gs1 barcode and select the default gs1 nomenclature. 3. scan the following barcode - 01000000000001232180085 (product barcode: 0000000000123, serial: 80085). - 01000000000000482180085 (product barcode: 0000000000048, serial: 80085). 4. there is an unexpected error notification, and the 2nd product line isn't added. **CAUSE** In _processBarcode (barcode_model.py), we only check if: - there is already a line with serial tracking with a non-null qty - this line serial number is the same serial number that we are scanning **FIX** We should also verify if the product from the lines we are checking, and the line we want to create are the same. [opw-5076045](https://www.odoo.com/odoo/project/49/tasks/5076045)
Invoices resent after a salesperson is archived now keep showing the correct sender name and image in the message history. This prevents confusion for customers and staff by ensuring invoice communications remain tied to the intended salesperson.
Original PR description
Steps to Reproduce: ------------------------- 1. Create a user (e.g., Test 1) with an email 2. Create an invoice with Test 1 as the salesperson and confirm it 3. Click Send and send the mail. 4.…
Steps to Reproduce: ------------------------- 1. Create a user (e.g., Test 1) with an email 2. Create an invoice with Test 1 as the salesperson and confirm it 3. Click Send and send the mail. 4. Archive the Test 1 user 5. Go to Customers and copy any customer’s email 6. Update the email on Test 1’s partner record 7. Go to the same previously created invoice and repeat step 3 Observation: ------------------------- In the chatter, the displayed sender name and image change. They no longer correspond to Test 1’s partner, even though the salesperson is still the same. Issue: ------------------------- In the following code: https://github.com/odoo/odoo/blob/3a1ec3bad5d4884952e09ed4eaabccf10cebbddf/addons/account/models/account_move_send.py#L451-L467 the `active_test` context is missing. Because of this, the partner search method in ORM skips archived users https://github.com/odoo/odoo/blob/3a1ec3bad5d4884952e09ed4eaabccf10cebbddf/addons/mail/models/mail_thread.py#L1942-L1951 Solution: ------------------------- Set `active_test=False` in the context so that archived user's partner records are also considered when determining the sender. opw-5067129
Opening an equipment record no longer crashes when a related maintenance request has no completion date. This prevents an error in the Maintenance app and lets users continue viewing equipment records normally.
Original PR description
**Steps:** 1. Create a new maintenance stage. 2. Create an equipment. 3. Create a maintenance request linked to that equipment. 4. Mark the maintenance stage as done. 5. Open the equipment. **Issue:** Opening equipment caused an error if close_date was empty: `unsupported operand type(s) for -: 'bool' and 'datetime.date'`. Cause: The maintenance request’s close_date remained empty when the stage was marked DONE. **Fix:** Check that close_date is not empty prior to computing MTBF. **Technical:** In _compute_maintenance_request, we calculate the difference between close_date and request_date.If close_date is empty, this calculation fails.
This fixes a validation error that could block confirmation of sales orders for made-to-order manufactured products when mandatory analytic plans are enabled. The system now carries the analytic distribution from the sales order line into the related manufacturing order, preserving required accounting details and allowing the order flow to continue.
Original PR description
## Issue: Confirming a Sale Order for a product with MTO + Manufacturing routes fails (Validation Error) when Analytic Accounting is enabled and an Analytic Plan is mandatory ## Cause: The…
## Issue:
Confirming a Sale Order for a product with MTO + Manufacturing routes fails (Validation Error) when Analytic Accounting is enabled and an Analytic Plan is mandatory
## Cause:
The analytic_distribution is first validated one time for the Sale Order line
When the MO will is created later, the `_compute_analytic_distribution()` function in `mrp_account` is triggered
Since no `account.analytic.distribution.model` is defined, the analytic_distribution field is recomputed as {}
This trigger a second validation, which fails because `{}` is invalid when an analytic plan is mandatory
## Steps to reproduce:
- Enable Analytic Accounting and Multi-Step Routes in Settings
- In Accounting > Configuration > Analytic Accounting > Analytic Plans set Projects as Mandatory
- Unarchive the MTO route
- Create a Product with MTO + Manufacturing routes
- Create a Sale Order for this product and set an Analytic Distribution for Projects
- Confirm the SO to get the Validation Error
opw-4863498The call participant volume control is now hidden unless the user has joined the call. This avoids showing irrelevant controls and makes the call interface clearer for users who are only viewing the conversation.
Original PR description
Before this PR, the volume slider for call participants was visible even when the user was not part of the call. This PR fixes the behavior by ensuring the volume slider is only available when the user is in the call. task-[5092826](https://www.odoo.com/odoo/project/1519/tasks/5092826)
This fixes an editing option that appeared on the Partners page even though it only applies to the Customers page. Website editors will no longer see or try to use a filter setting that has no effect, reducing confusion when managing website pages.
Original PR description
Scenario: - install website_customer and website_crm_partner_assign - go to /partners - in edit mode, disable the option "Countries Filter" Result: nothing happen Cause: there is no filter options on /partners page, but the options of /customers page are targetting class o_wcrm_filters_top that is common to both page, so they are shown on /partners incorrectly. Fix in stable: change the selector to only show options on /customers. Fix in master: in website_customer, change the o_wcrm_filters_top class to o_wc_filters_top class. opw-5102381
SEPA payments will now only be marked as high priority for Belgian companies. This helps avoid unnecessary bank fees in countries where high-priority payments can carry extra charges, such as Switzerland.
Original PR description
Having priority set as HIGH for SEPA payments can induce extra fees (ex. in CH). This commit only sets the priority to HIGH for BE companies. task-4874217
The employee working schedule calendar now keeps the hours-per-week value on one line. This small visual fix makes schedules easier to read and avoids awkward wrapping in the interface.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines Forward-Port-Of: odoo/enterprise#91993