Monday, October 20, 2025
20 changes · 19.0
Enhancements to existing features
Payslips in the Mexican payroll CFDI flow now show issue alerts when required information is missing. This helps payroll teams identify and correct problems earlier so CFDI documents can be generated correctly.
Original PR description
We now have a "issues" system on the payslips. Let's use it to signal what is missing for the correct generation of the CFDI. Task: 5068311
Swedish batch payments can now include both IBAN and BBAN, Bankgiro, or Plusgiro recipients in the same batch. The system automatically separates them into two XML files inside one zip file, reducing manual work and avoiding blocked mixed payment batches.
Original PR description
This commit add a new behaviour for batch payments in Sweden. Before this commit: batch payment with mixed payment for iban and bban/bankgiro/plusgiro wasn't allowed After this commit: now if the user create a batch payment with both type of account, we create a zip file with 2 xml files, one for iban and one for bban/bankgiro/plusgiro. Linked:https://github.com/odoo/odoo/pull/230104 [task-5107240](https://www.odoo.com/odoo/project/967/tasks/5107240) Forward-Port-Of: odoo/enterprise#97556 Forward-Port-Of: odoo/enterprise#95463
Links typed into the mail composer are now recognized and highlighted more reliably. This improves the message-writing experience while also simplifying the underlying editor setup for easier maintenance.
Original PR description
This commit enables the link plugin in the mail composer so that the link will be properly parsed and hightlighted. This commit also improves the plugin set and clean up the duplicated plugin lists. task-5172795 backport - https://github.com/odoo/enterprise/pull/97504 https://github.com/odoo/enterprise/pull/97666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updates Luxembourg payroll calculations to reflect the 2025 minimum social salary and related tax credit changes. This helps ensure employee payslips and payroll obligations stay aligned with the latest official Luxembourg rates.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf task-5176255 Forward-Port-Of: odoo/enterprise#97468
Resolved issues and error corrections
Project profitability now shows the full expected purchase cost when purchase orders are billed across multiple vendor bills. This prevents project cost forecasts from being understated and excludes canceled credit notes from the calculation.
Original PR description
## Issue: When a Purchase Order is linked to a Project and its quantity is billed through multiple vendor bills, the "Expected" amount in the project profitability view was incorrect ## Cause: When…
## Issue: When a Purchase Order is linked to a Project and its quantity is billed through multiple vendor bills, the "Expected" amount in the project profitability view was incorrect ## Cause: When at least one invoice line exists for a PO line, `_get_profitability_items()` computes `to_bill` and `billed` amounts without using the purchase order's ordered quantity This causes the computation to only consider the quantities already billed, ignoring the remaining quantity that still needs to be billed: https://github.com/odoo/odoo/blob/cdb8370647ca4b07f89edaf5fcc687508f6af16d/addons/project_purchase/models/project_project.py#L155-L178 Additionally, the code included all credit notes, even those that were canceled ## Steps to reproduce: - Ensure the "Sales" app is installed to display project profitability - Create a new Project "Profitability" and mark it as Billable - Create and confirm a PO (any product, quantity: 5, unit price: 100, Taxes: None, Other Information > Project: "Profitability") - Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: 0) - Create and confirm a Vendor Bill (Quantity: 2) - Check the project dashboard for Purchase Orders (Expected: -200, To Bill: 0, Billed: -200) - Create and confirm a Vendor Bill linked to the PO using Auto-Complete (Quantity: 3) - Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: -500) opw-5077609 Forward-Port-Of: odoo/odoo#229221
Starshipit delivery requests now include the customer city or suburb when checking available services. This prevents supported carriers such as NZ Post Domestic from being incorrectly unavailable, helping users configure shipping methods successfully.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
This fixes an issue where editing a product variant on a sales order could reset the chosen packaging, such as a pack of 6, back to standard units. Sales teams can now adjust or confirm variants without accidentally changing the customer’s ordered unit or packaging.
Original PR description
## Versions
18.2+
Note: 18.4 needs `product.uom_id` to be replaced by `product.uom.id` to work properly.
## Issue
On a SO, if a product has variants and packaging is allowed, modifying the variant resets the packaging to units.
## Steps to reproduce
*Ensure "Units of Measure & Packagings" is enables in Sales' app's settings*
- Create a new product
- Under "Attributes & Variants" tab, add the following:
- Color: add 2 colors;
- Legs: add 2 legs;
- Under "Sales" tab, select "Pack of 6" for "Packagings" (under "Upsell & Cross-Sell" section);
- Create a new quote and add that new product:
- Change its "Unit" for "Pack of 6";
- Modify the product variant by clicking the pen button next to the product name (appear on hover):
- Click "Confirm" (no changes needed);
- See the order line's product's units change back to "Units".
opw-4814166
Forward-Port-Of: odoo/odoo#224574The customer preview for shared projects now matches what portal customers actually see when timesheet invoicing is limited to validated entries. This prevents internal users from accidentally previewing draft or unvalidated timesheets as if they were visible to customers.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This update removes default OK buttons that appeared in some dialogs without serving a clear purpose, especially in Point of Sale screens. It makes popups cleaner and less confusing while preserving keyboard accessibility so dialogs can still be closed without a mouse.
Original PR description
*: point_of_sale, pos_* Since the commit [1] simplifying the method to hide the base Dialog's default button (aka. the "Ok" button) and the cleanup of the ControlPanel's buttons, this "Ok" is…
*: point_of_sale, pos_* Since the commit [1] simplifying the method to hide the base Dialog's default button (aka. the "Ok" button) and the cleanup of the ControlPanel's buttons, this "Ok" is displayed on some dialog (like containing a list view) with no real purpose. While this behavior/appearance was actually willingfull and more deterministic than the previous one, it showed us that those default buttons didn't provide a meaningful user experience and are more disturbing than anything else. This commit removes the Dialog's default "Ok" button. But, this removal has a side-effect: dialog's without any "tabbable" element (input, button...) doesn't get the focus anymore... and can't be closed via keyboard navigation. To circumvent this issue, this commit also adapts the `useActiveElement` hook to focus the referenced element itself it is focusable and it doesn't contain any "tabable" element. task-5082826 [1]: https://github.com/odoo/odoo/commit/1cf179bbf1c49a6d69588911c2a3d98dbeadd3d9
This fixes an issue where users could not see the bank account selection field when creating NACHA payments. Restoring the missing payment component helps ensure businesses can choose the correct bank account for US electronic payment files.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
Marketing cards now stop and show an error when image generation fails, instead of being treated as successfully synced while empty. Campaign changes also correctly mark all related cards as needing an update, so reused or previewed cards are refreshed when mailings are updated.
Original PR description
If wkhtmltoimage fails for any reason we currently keep going as if an image was actually rendered. Instead if the result of the image render is `None`, raise a generic error. This avoids issues with cards being marked "synced" even though they are actually empty. Additionally, when the campaign gets reused: - preview two records - update cards on a mailing - preview a record again - modify one of the fields on the card - update the cards on a mailing again - the card that was previewed is not updated ALL cards must require sync after a change to the campaign not just active ones. Otherwise they will keep their "synced" status and not be synced when they're selected for update later on. task-5048534 Forward-Port-Of: odoo/odoo#232005 Forward-Port-Of: odoo/odoo#224629
The website setup wizard now correctly selects the industry a user clicks in the dropdown instead of defaulting to the first result. This prevents setup mistakes and makes new website configuration smoother and more predictable.
Original PR description
Problem In the website configuration wizard, when selecting an industry by mouse clicking, the first industry in the list would get selected instead of the clicked one. Steps - In Odoo with the…
Problem In the website configuration wizard, when selecting an industry by mouse clicking, the first industry in the list would get selected instead of the clicked one. Steps - In Odoo with the Website addon installed - Create a new website in the website settings - Select any type of website - Write an industry name - Click on any industry in the dropdown list - The first industry of the list get selected Cause This bug only happens if the param `selectOnBlur` is activated. `selectOnBlur` makes clicking away from the input as a select of the first option. But, clicking on an option in the list is also considered as an onBlur, so when the user clicks on an industry, it will always select the first one of the list. Fix Added a flag `isOptionSelected`, set to true every time an option is selected. This is to prevent the `selectOnBlur` of overwriting what has been already selected. Deleted `selectOnTab` brought in this commit 8e6410b because the function already existed under `autoSelect`. Also added tests, and fixed linter errors in `autocomplete.js`. task-5139708
Restaurant owners can now print POS sales reports directly while a sales session is still open. This removes the need to go through the backend just to access the report, making day-to-day restaurant operations faster and more convenient.
Original PR description
- Restaurants owners need to be able to print a sales report during a session. Before this commit, they were only available to print the report via the backend. task-id: 5076080 Forward-Port-Of: odoo/enterprise#94181
This fixes errors that could occur when setting up or upgrading in-store pickup delivery methods in multi-company environments. The delivery method now uses the correct company when linking warehouses, preventing validation failures and incorrect warehouse assignments.
Original PR description
The record `carrier_pick_up_in_store` will get assigned the product `product_pick_up_in_store`. Since the warehouses are linked based[^1] on the env company, if it doesn't match that of the product…
The record `carrier_pick_up_in_store` will get assigned the product `product_pick_up_in_store`. Since the warehouses are linked based[^1] on the env company, if it doesn't match that of the product it will throw an error[^2] because of that mismatch. To reproduce: - Change the company of `product_pick_up_in_store` to one other than the active. - Delete the delivery carrier `carrier_pick_up_in_store` - Upgrade the module. **[FIX] website_sale_collect: Use right company for warehouses** While creating a delivery carrier the warehouses are linked using the env company. While using multi-company, you might select another company from the active ones rather than the one from env. This will trigger a validation error because the warehouses will be filtered by the wrong company. Same case if the company is left empty. To reproduce: - Create a delivery method selecting pick up in store, leaving the company empty. - It will still link the warehouses from the active company. - Activate a second company in the multi-company menu. - Create a delivery carrier, selecting pick up in store and the second company. - The warehouses will be linked to the first company, triggering a validation error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr [^1]:https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/website_sale_collect/models/delivery_carrier.py#L47-L49 [^2]:https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/website_sale_collect/models/delivery_carrier.py#L33-L38
Financial reports now translate currency adjustment amounts using the closing rate instead of the current rate. This restores the prior behavior so reports such as ledgers and trial balances better match expected period-end accounting values.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888 Forward-Port-Of: odoo/enterprise#97429 Forward-Port-Of: odoo/enterprise#97271
Fixes an accounting reconciliation issue where a bank payment smaller than the invoice total could incorrectly mark the full invoice as paid and create an unnecessary suspense balance. The system now applies only the correct partial amount, keeping invoice payment status and bank entries accurate.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498 Forward-Port-Of: odoo/enterprise#96847
This fixes how currency translation adjustments are calculated in accounting reports by reverting a prior change that used the wrong rate for year-over-year balance sheet revaluations. Businesses should see more accurate balance sheet currency figures when comparing periods.
Original PR description
This reverts commit c440bb52d19b8dcec8b708509973c4095a577b34 as it doesn't work as expected in year-over-year re-evaluation in balance sheets. task-5085888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231990 Forward-Port-Of: odoo/odoo#231718
Point of Sale now uses the quantity encoded in GS1 barcodes when products are scanned. This prevents checkout errors where items were added with the wrong quantity, improving accuracy for retailers using GS1 labels.
Original PR description
Before this commit, the quantity encoded in a GS1 barcode was ignored when scanning. After this commit, the product will be added with the correct quantity extracted from the GS1 barcode. opw-5126522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232010 Forward-Port-Of: odoo/odoo#229678
Point of Sale now prevents users without the required permissions from attempting to delete cash in/out entries, and shows a clear error if deletion is blocked. This avoids confusion for store staff and fixes receipt printing errors for cash movement receipts.
Original PR description
Before this commit, a user with "account.group_account_invoice" group could try to delete a cash in/out in the pos but had no feedback. Actually, his request was refused but we never tell the user why. We now display the error but also do not give the possibility to the user to delete a cash in/out if he does not have the right group. There was also errors appearing when printing the CashMoveReceipt. We call the ReceiptHeader in the CashMoveReceipt but without giving it a real order which could cause problems cause in the ReceiptHeader we consider the order that is given as a real one and we can call methods and stuff from the model. We now create a dummy order to give to the ReceiptHeader. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228789
Fixed a stability issue in Sales spreadsheet field synchronization that could cause crashes when users used undo or redo. This helps keep spreadsheet-based sales workflows reliable and avoids interruptions during editing.
Original PR description
Fix an issue where field sync would crash when used with UNDO/REDO. Task: 4854879 Forward-Port-Of: odoo/enterprise#92883