Wednesday, July 15, 2026
15 changes · 18.0
Enhancements to existing features
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270
Resolved issues and error corrections
Philippine check printing now rounds the cents portion of written amounts to two decimals, even when the currency is configured with more precision. This prevents confusing or incorrect check text such as showing four decimal digits in the amount in words.
Original PR description
Current behavior: --- When paying with checks, if the currency has more than 2 decimals, the decimal amount is printed with more than 2 decimals. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. In the PHP currency, change rounding factor to 0.0001 4. In Decimal accuracy > product price, set 4 digits 5. Create a new Vendor Payment, payment method Check, amount 100.1268 PHP 6. Results: One Hundred and 1268/100, should be 13/100 Expected behavior: --- The xx/100 part of amount in words text in the check should always be rounded to 2 decimals. opw-6302337 Forward-Port-Of: odoo/enterprise#121913
Miscellaneous changes
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and ass
Original PR description
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and associated delay/latency/overall perceived slowness for the end user. opw-6206709 Forward-Port-Of: odoo/odoo#275264
The point of sale IoT integration now works better with newer IoT Boxes that no longer report certain device details. This prevents searches from relying on missing information, helping printers and SIX payment terminals be found correctly.
Original PR description
Newer IoT Boxes don't share device subtype or manufacturer. We then adapt the domains to avoid searching on fields that aren't filled. task-6388669 task-6388733
This fix makes product creation permission checks in the barcode lookup point of sale flow happen consistently and immediately. It helps ensure users only see or use product creation options when they have the right access, reducing confusing behavior at checkout.
Original PR description
Replace the asynchronous `allowProductCreation` method with the `hasProductCreationAccess` getter to evaluate product creation permissions synchronously and ensure consistent behavior. Task-6361787 Related PR: https://github.com/odoo/odoo/pull/274420
Steps to reproduce: - In Outlook, create a recurrence with an exception that is not the first occurrence. - Run the Microsoft calendar synchronization in Odoo. - The exception is imported without microsoft_id or ms_universal_event_id, and follow_recurrence is set to True. Outlook exceptions are converted without their identifiers, and calendar.event creation overwrites their explicit follow_recurrence=False value. Preserve both the Microsoft identifiers and the detached exception state dur
Original PR description
Steps to reproduce: - In Outlook, create a recurrence with an exception that is not the first occurrence. - Run the Microsoft calendar synchronization in Odoo. - The exception is imported without microsoft_id or ms_universal_event_id, and follow_recurrence is set to True. Outlook exceptions are converted without their identifiers, and calendar.event creation overwrites their explicit follow_recurrence=False value. Preserve both the Microsoft identifiers and the detached exception state during import. opw-5129848
steps to reproduce: ----------- - install the industry_fsm_repair module - create a product with type goods and enable `create repair` - enable `create repair orders` from returns in delivery orders in operation types - create a sale order with an fsm product and a goods product - confirm the sale order and validate the delivery - return the delivery and validate it (wh/in/0000x) - open the return receipt (wh/in/0000x) and create a repair - create an fsm user without sto
Original PR description
steps to reproduce: ----------- - install the industry_fsm_repair module - create a product with type goods and enable `create repair` - enable `create repair orders` from returns in delivery orders…
steps to reproduce: ----------- - install the industry_fsm_repair module - create a product with type goods and enable `create repair` - enable `create repair orders` from returns in delivery orders in operation types - create a sale order with an fsm product and a goods product - confirm the sale order and validate the delivery - return the delivery and validate it (wh/in/0000x) - open the return receipt (wh/in/0000x) and create a repair - create an fsm user without stock access - log in with the fsm user - open a task, go to `pick up`, and open the stock move - open the repair order issue: -------- the fsm user does not have access to stock lots and repair tags, which causes an access error. fix: ---- added the stock user group to the repair tags and stock lot fields so that users without the stock user group cannot access them. technical: ------ in the stable version, i did not extend the repair view in the industry_fsm_repair module. instead, i added the group directly in the repair module. In master, the group is added through the industry_fsm_repair module. task-6032336
opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per
Original PR description
opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per the latest Worldline documentation, ensuring payment requests use the correct mapping. Forward-Port-Of: odoo/odoo#275881
Description of the issue/feature this PR addresses: Current behavior before PR: meeting.rrule is stored as a full dateutil rrule string, e.g.: "DTSTART:20250218T113209\nRRULE:FREQ=YEARLY;COUNT=720" Passing the full multi-line string as a single RRULE property value causes vobject to emit two RRULE lines, where the first one ("RRULE:DTSTART:...") has no FREQ. This is not standard-compliant and is rejected by calendar clients (e.g. Thunderbird: "invalid frequency null"). Desired behavior af
Original PR description
Description of the issue/feature this PR addresses:
Current behavior before PR: meeting.rrule is stored as a full dateutil rrule string, e.g.: "DTSTART:20250218T113209\nRRULE:FREQ=YEARLY;COUNT=720"
Passing the full multi-line string as a single RRULE property value causes vobject to emit two RRULE lines, where the first one ("RRULE:DTSTART:...") has no FREQ. This is not standard-compliant and is rejected by calendar clients (e.g. Thunderbird: "invalid frequency null").
Desired behavior after PR is merged: Only a single RRULE line is generated.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMicrosoft issues a new refresh token on every access token refresh (rolling 90-day sliding window). The previous code discarded it, causing users to be forced to re-authenticate every 90 days once the original token expired. Closes #253543 Forward-Port-Of: odoo/odoo#268284
Original PR description
Microsoft issues a new refresh token on every access token refresh (rolling 90-day sliding window). The previous code discarded it, causing users to be forced to re-authenticate every 90 days once the original token expired. Closes #253543 Forward-Port-Of: odoo/odoo#268284
Issue: --- If a product template has dynamic attributes, some variants might not exist. For those variants, we are showing wrong stock in the website. To reproduce: 1- Create a product with a dynamic attribute and two values. 2- Publish the product and uncheck sell when out-of-stock and check show product when the qty is less than 5. 3- Create a purchase order with qty = 4 for the first value, so a variant is created for it. 4- Go to the website shop. Open the product. 4 available qty i
Original PR description
Issue: --- If a product template has dynamic attributes, some variants might not exist. For those variants, we are showing wrong stock in the website. To reproduce: 1- Create a product with a dynamic…
Issue: --- If a product template has dynamic attributes, some variants might not exist. For those variants, we are showing wrong stock in the website. To reproduce: 1- Create a product with a dynamic attribute and two values. 2- Publish the product and uncheck sell when out-of-stock and check show product when the qty is less than 5. 3- Create a purchase order with qty = 4 for the first value, so a variant is created for it. 4- Go to the website shop. Open the product. 4 available qty in stock is shown for the first variant which is correct. 5- Select 2nd variant. As you see, still 4 available qty is shown which is wrong. As the out-of-stock sale is unchecked, an out-of-stock warning should be shown. Cause and Fix: --- This is due to `isMainProduct` being always False when `product_id` is not set which makes `free_qty` and `out_of_stock` not to be updated. Also in `get_combination_info_website`, `is_storable` value is set to variant `is_storable` field which will be False if product variant is not exist. opw-6237602 Forward-Port-Of: odoo/odoo#273104
### Steps to reproduce the issue: 1. Download Accounting 2. Go to one move type (ex. customer invoices, vendor bills, etc.) 3. Select some records, click the wheel button and then export ZIP 4. Error raised: Nothing to export ### Cause of the issue: Commit 438603ac forward-ported the zip export feature from v17 to v18, but failed to adapt the action_export_zip function and import the controller route. ### Reason to introduce the fix: It has been decided to completly remove the butto
Original PR description
### Steps to reproduce the issue: 1. Download Accounting 2. Go to one move type (ex. customer invoices, vendor bills, etc.) 3. Select some records, click the wheel button and then export ZIP 4. Error raised: Nothing to export ### Cause of the issue: Commit 438603ac forward-ported the zip export feature from v17 to v18, but failed to adapt the action_export_zip function and import the controller route. ### Reason to introduce the fix: It has been decided to completly remove the button EXPORT ZIP since we already have other buttons that download/export the PDFs in a zip file (ex. button Download PDF). opw-6313750 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps: - Enable `pos_hr` and configure employees - Open the POS - Log in as an employee - Open the burger menu in the navbar Issue: - The "Create Product" menu is not visible immediately after the employee logs in. - It only appears after refreshing the POS. Cause: - The visibility of the menu is determined when `Navbar` component is mounted. - Since the `Navbar` is mounted only once when the POS UI loads, the value is not updated after employee login. Fix: - Replace the asynch
Original PR description
Steps: - Enable `pos_hr` and configure employees - Open the POS - Log in as an employee - Open the burger menu in the navbar Issue: - The "Create Product" menu is not visible immediately after the employee logs in. - It only appears after refreshing the POS. Cause: - The visibility of the menu is determined when `Navbar` component is mounted. - Since the `Navbar` is mounted only once when the POS UI loads, the value is not updated after employee login. Fix: - Replace the asynchronous permission check with a getter that evaluates product creation rights. - Cache the group access information in `posService` and let the hr override use the getter. Task-6361787 Related PR: https://github.com/odoo/enterprise/pull/123073
Rather than assign `log_target` and blow up if the third branch is taken, use a `defaultdict` and just increment the count in each branch on hit. The continue in the third branch is not strictly necessary, but that way it protects us if anyone decides to add post-processing which also doesn't account for the third branch.
Original PR description
Rather than assign `log_target` and blow up if the third branch is taken, use a `defaultdict` and just increment the count in each branch on hit. The continue in the third branch is not strictly necessary, but that way it protects us if anyone decides to add post-processing which also doesn't account for the third branch.
This update resolves an issue where non-administrator users accessing the POS payment method form would encounter an error. The change grants read-only access to the `payment.provider` model for POS managers and restricts the form's visibility to authorized users, ensuring a smoother experience for POS staff.
Original PR description
Only admin users have read access to the `payment.provider` model. Opening the PoS payment method form as a non-admin would raise an access error because the `online_payment_provider_ids` many2many field tries to fetch `payment.provider` records on form load. Grant read-only access on `payment.provider` to `group_pos_manager` so POS admins can use the field. Restrict the field's group in the form view to `point_of_sale.group_pos_manager,base.group_system` so it is not rendered for users without either role. opw-6208656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263837