Daily updates from Odoo
Navigate
Branch
Wednesday, October 22, 2025
205 changes
12 changes
Enhancements to existing features
Users can now download invoice exports as a single ZIP containing all supported formats, such as PDF and XML. This makes it easier for businesses to share sales and purchase invoices with accountants who may use different tools, especially in PEPPOL workflows.
Original PR description
With PEPPOL, many clients use Odoo for invoicing while their accountant uses another tool. To easily send invoices to the accountant, it’s important to export invoices for both sales and purchase. Adding a `Export ZIP` option to download invoices in all supported extensions (pdf, xml, ..etc) in the same zip. task-4946367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Shopee orders marked as delivered but awaiting buyer confirmation will no longer be treated as delivery errors in Odoo. This prevents unnecessary error states and helps teams track fulfillment more accurately.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
Fixed an issue where company-specific special products could be missing from Point of Sale setups for that same company. This ensures PoS users can reliably access the products configured for their company after reloading data.
Original PR description
### Problem When assigning a special product to a company, the product will not be loaded when accessed from a PoS config of the same company. The issue occurs because `product.sudo().company_id == self.company_id` fails as `self` is an empty recordset. ### Steps to Reproduce on Runbot * Add a company to the special PoS product. * Access a PoS config on the same company. * Reload data. * The product will not be loaded. original PR: https://github.com/odoo/odoo/pull/194451 opw-5157959 Forward-Port-Of: odoo/odoo#231273
This fixes Turkish Nilvera export e-invoices so delivery information is only included when required and placed correctly. It prevents Nilvera from rejecting export e-invoices that include discounts, helping affected invoices process successfully.
Original PR description
The Delivery node is only required for Export E-Invoices. Additionally, the position of the Delivery node should not follow the AllowanceCharge node. This inconsistency in node positioning causes a blocking issue on Nilvera’s side, preventing the successful processing of export E-Invoices with discounts. task-5155802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230935
Saudi e-invoices now keep the negative value of 0% tax invoice lines instead of converting it to a positive amount. This prevents unnecessary ZATCA validation warnings and helps businesses submit cleaner compliant invoices.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
French VAT report submissions now follow ASPOne’s required data format more closely. This reduces the risk of rejected filings caused by outdated address fields or overly long postal code and city values.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
This fixes duplicated screenshots and screen recordings when automated tests fail, reducing clutter and avoiding a failure in the reporting process itself. It also saves recording frames directly as readable images, making test failure evidence more reliable if a crash interrupts processing.
Original PR description
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok`…
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure. Do a bit of rejiggering to fix things up: - in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing) - only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already. And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs. Forward-Port-Of: odoo/odoo#232472
This fix prevents module updates from failing when default marketing tracking labels such as LinkedIn have been customized or duplicated by users. It preserves user-managed tracking data during updates, reducing disruption for teams using link tracking and live chat attribution.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
Users who choose to handle notifications in Odoo and have browser push notifications enabled will no longer receive two alerts for the same message. This reduces confusion and notification noise when Odoo is open in another tab.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221259Job applications created by email now keep the company from the job position when the linked department has no company set. This prevents recruitment users from losing company context and avoids issues when assigning recruiters or interviewers.
Original PR description
When an applicant applied to a job position with a company_id and department_id, but the department itself had no company_id set, the application would have company_id set to False rather than the company_id from the job position. This caused bunch of issues such as the inability to add a recruiter or interviewers to the application.The bug seems to come from the default values created in the method `_alias_get_creation_values` on the job position, which sets the default company_id to the department's company_id when the job has a department that can result in False when the department exists but has no company set. task-5184275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232492
This fixes a visual inconsistency where certain website badges appeared larger than standard badges after a prior styling change. Badges now keep the expected text size, improving visual consistency across website pages.
Original PR description
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img…
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img width="437" height="392" alt="image" src="https://github.com/user-attachments/assets/b6896545-34b5-4816-a35f-5c2605d4153b" /> | Prior to Commit[^1], the front-end badges using `.badge.o_tag` were receiving a `12px` font size, which came from a rule defined in portal. This looked fine, although odd, since a style from portal was affecting the entire front end. After Commit[^1], this rule no longer exists, meaning that `.o_tag` now falls back to `0.875rem` (14px by default), while standard badges use a default font size of `0.75em` (12px by default) Since using `.badge.o_tag` never allowed overriding the `font-size` value, we fixed the issue by assigning the `--badge-font-size` CSS variable directly to the badge definition, ensuring the correct visual result. task-4900376 [^1]: https://github.com/odoo/odoo/commit/8f8a370a84d136f3d2316eb1a55c7168b7ae6ccf#diff-23677f06a9aaf2e3395e957cfb9580ce6fcc9aba2635b560fe8f15fa27707313L29 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
An obsolete setup component for advance invoicing in external tax sales was removed because it is no longer used. This reduces maintenance overhead while keeping the process aligned with Odoo's standard behavior.
Original PR description
The `wizard/` folder contained only `sale_make_invoice_advance.py`, which overrode `_prepare_down_payment_lines_values` but is no longer used. All functionality now relies on Odoo's standard implementation. Forward-Port-Of: odoo/enterprise#95608
11 changes
Resolved issues and error corrections
Shopee orders that are delivered but still awaiting buyer confirmation are now handled correctly. This prevents Odoo from incorrectly showing these delivery orders in an error state, reducing confusion for sales and operations teams.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
Point of Sale now correctly loads special products that are assigned to the same company as the PoS configuration. This prevents missing products during data reloads and helps ensure company-specific PoS setups work as expected.
Original PR description
### Problem When assigning a special product to a company, the product will not be loaded when accessed from a PoS config of the same company. The issue occurs because `product.sudo().company_id == self.company_id` fails as `self` is an empty recordset. ### Steps to Reproduce on Runbot * Add a company to the special PoS product. * Access a PoS config on the same company. * Reload data. * The product will not be loaded. original PR: https://github.com/odoo/odoo/pull/194451 opw-5157959 Forward-Port-Of: odoo/odoo#231273
French VAT report submissions now better match ASPOne's required format. This reduces the risk of rejected filings caused by outdated address fields or address values that are too long.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
This fixes the payable total shown on Turkish e-invoice XMLs for invoices marked as Registered For Export. The amount now correctly reflects VAT deductions, helping ensure exported invoice documents match legal and accounting expectations.
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
Saudi e-invoices now keep negative amounts correctly for invoice lines that are not subject to VAT. This prevents unnecessary ZATCA validation warnings when sending invoices that include negative 0% tax lines, improving compliance feedback and reducing manual follow-up.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
Updating the UTM module could fail if users had created or edited tracking sources or media with duplicate names, such as LinkedIn. This change protects the default tracking records during module updates so upgrades complete without disrupting marketing link tracking data.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from using taxes that should no longer be available. This helps keep invoice tax calculations aligned with current tax setup and avoids accidental use of obsolete tax rules.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775 Forward-Port-Of: odoo/odoo#230729
Users who choose to handle notifications inside Odoo could receive two browser alerts for the same message when push notifications were enabled and an Odoo tab was open. This fix prevents the duplicate alert so users receive a single, clearer notification.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221259Email-based job applications now keep the company from the job position when the related department has no company set. This prevents recruitment teams from losing key application permissions, such as assigning recruiters or interviewers.
Original PR description
When an applicant applied to a job position with a company_id and department_id, but the department itself had no company_id set, the application would have company_id set to False rather than the company_id from the job position. This caused bunch of issues such as the inability to add a recruiter or interviewers to the application.The bug seems to come from the default values created in the method `_alias_get_creation_values` on the job position, which sets the default company_id to the department's company_id when the job has a department that can result in False when the department exists but has no company set. task-5184275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232492
Budget line reports now show the committed amount for the specific budget line instead of counting amounts from the whole budget. This prevents duplicated committed values when budgets use multiple analytic plans, giving users accurate budget reporting.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
Deferred dates on bill receipts are now kept correctly, and deferral entries use the right account when a bill is changed to a receipt. This helps prevent incorrect deferred revenue or expense accounting for receipt-type documents.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97653
6 changes
Enhancements to existing features
Finnish accounting reports can now be exported in the required file format for submission to the tax administration. This helps businesses prepare and send tax report data more easily and reduces manual handling.
Original PR description
The aim of this commit is adding the tax report export file to allow our customers to send their tax reports to their administration. task-5135868 Forward-Port-Of: odoo/enterprise#96256
Resolved issues and error corrections
Shopee orders marked as delivered but awaiting buyer confirmation will no longer be treated as delivery errors in Odoo. This prevents unnecessary error states and gives users a more accurate view of shipment progress.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
This fix updates French VAT report submissions so the address information sent to ASPOne follows the required format. It helps prevent rejected filings caused by postal codes or city names that exceed ASPOne's accepted limits.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
Delivery label printing now includes every label attached to the delivery record, instead of printing only one when multiple files are present. This helps warehouse and shipping teams avoid missing labels and reduces manual reprints or shipping delays.
Original PR description
Before this commit, only 1 label get printed even if multiple files are in the chatter After this commit we handle the cases with multiple files + revert suppression of public method for API opw-5181209 Forward-Port-Of: odoo/enterprise#97805
Fixes an issue where creating multiple payslips for the same employee in one batch could duplicate the full expense amount on each payslip. This helps ensure payroll expenses are assigned to the correct payslip and prevents overstatement of employee payments.
Original PR description
since 9435b76 an issue arise when an employee gets two payslip generated for them in the same batch as both would get the full expense input line amount whereas only one gets the expenses linked to it. This adds a context key to bypass the computation when the payslips are created from a batch and trusting the create of the payslip to handle the proper assignation of expenses and computation of the lines Forward-Port-Of: odoo/enterprise#81987
Budget line reports now show committed amounts only for the selected budget line instead of counting matching amounts from the whole budget. This prevents overstated commitments when a bill is split across multiple analytic plans, helping users trust budget reporting figures.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
36 changes
Security fixes and vulnerability patches
Access to Mexico-specific employee payroll fields is now limited to authorized HR users. This helps protect sensitive employee information and keeps payroll data visible only to the appropriate team members.
Original PR description
backport the fix in odoo/enterprise https://github.com/odoo/enterprise/pull/94488 to 19.0 RB-231712 Forward-Port-Of: odoo/enterprise#96728
Enhancements to existing features
The VoIP recent call experience is now cleaner and easier to use, with fewer visible buttons and related actions grouped into dropdown menus. Mobile users get the same actions in a bottom-sheet layout, making call follow-up tasks easier on smaller screens.
Original PR description
*: voip, voip_{ crm, hr_recruitment, sms } This commit introduces several improvements in the recent call tab in the VoIP interface: 1. There is always a maximum of 3 buttons to the left of the call…
*: voip, voip_{ crm, hr_recruitment, sms }
This commit introduces several improvements in the recent call tab in the VoIP interface:
1. There is always a maximum of 3 buttons to the left of the call card and one call button on the right.
<img width="466" height="188" alt="image" src="https://github.com/user-attachments/assets/ba7b3492-1205-4645-a101-42c2466bc196" />
2. Group all create actions in one dropdown menu.
<img width="381" height="313" alt="image" src="https://github.com/user-attachments/assets/dab7f172-2f24-43a1-a88d-952aca0b0a6c" />
3. Group regular actions + send actions in one dropdown menu with a separator. This also includes adding some actions that weren't there, like "subscriptions" and "tickets".
<img width="380" height="411" alt="image" src="https://github.com/user-attachments/assets/7d1f9284-6163-4a18-b0b7-f73018e2cc1e" />
4. All the mentioned dropdown menus above are open as a bottom sheet when opened on mobiles.
<img width="462" height="615" alt="image" src="https://github.com/user-attachments/assets/d5fa4233-d0e7-44b0-a0c9-d5fdb8e59c6e" />
Task-4962728Financial reports with many expanded lines now build display data more efficiently. This reduces waiting time for users viewing large account reports, with the provided benchmark improving from 2.65 seconds to 1.93 seconds.
Original PR description
The column dicts contains all the data needed for the ui to display each cell of a line. In order to compute them, we iterated over `aggregated_group_totals` ( which basically represents the data gotten from the query for each line) and then over each expression. But if we had a lot of lines, the operations we do with the expressions became expensive. With this commit, the operations on the expressions are processed first, then we iterate over the lines. Benchmark --------- For an `account.report` using a custom handler, containing 1 `account.report.line` and 6 `account.report.column`, which unfolds into ~5300 lines: | | Before | After | |-------------|-----------|---------| | Timings | 2.65s | 1.93s |
This update modernizes parts of the online sales rental, stock rental, and subscription areas by replacing older browser code with a lighter standard approach. It helps reduce reliance on an external library, which can make these website shopping features easier to maintain and improve over time.
Original PR description
This PR aim to convert all jQuery code into Vanilla JS in website_sale, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
The German tax report has been reorganized after the removal of a balance column. This keeps the report logic aligned with the new layout and helps ensure tax reporting remains clear and reliable for German localization users.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
This update tidies the return flow used after Stripe-related expense actions. It improves maintainability and consistency without introducing a significant change for everyday users.
Original PR description
Forward-Port-Of: odoo/enterprise#97765
This update reorganizes how several website-related widgets load their supporting content, moving it into a dedicated bundle that is loaded only when needed. This should make pages lighter and improve maintainability without changing the visible user experience.
Original PR description
This pr moves static xml files of JS widgets from assets_frontend bundle to new bundle and that bundle is loaded with assetLibs property of JS widget. task-4146919
This draft update replaces several older pop-up, tooltip, notification, and menu elements with shared standard components across affected apps. This should make the user experience more consistent and easier to maintain, with a specific fix for planning calendar pop-ups.
Original PR description
Work in progress
This update restores automated checks for the OCR manual correction experience, helping ensure users can reliably adjust extracted document data. It broadens coverage for field availability, rectangular selection, and smart line handling, reducing the risk of regressions in future changes.
Original PR description
Commit 935b25f has refactored and improved the boxes interface of the OCR, but, due to the lack of time (19.0 freeze), the tests were removed as they needed to be rewritten. This commit re-introduce the tests in a more generic fashion by moving them directly into the mixin instead of inside the `account_invoice_extract` module and it also covers the new features: - Availability on all fields. - Rectangular selection. - Smart line creation/filling for x2many fields. Related to task-[5055731](https://www.odoo.com/odoo/project/2068/tasks/5055731) Forward-Port-Of: odoo/enterprise#95778
Opening and folding the WhatsApp section in the Discuss sidebar is now more responsive. This improves day-to-day navigation for users who manage WhatsApp conversations in Odoo, reducing friction when switching between communication categories.
Original PR description
Part of Task-5003012
The softphone now shows direct buttons to a customer's helpdesk tickets and subscriptions. This helps sales and support teams get relevant customer context faster during calls, reducing navigation time and improving service responsiveness.
Original PR description
*: voip_helpdesk, voip_sale_subscription Task-4962728 Community: https://github.com/odoo/odoo/pull/225421
This change streamlines how IoT device keyboard settings are updated by combining two related actions into one. It reduces unnecessary communication with the IoT Box, helping device setup and configuration run more efficiently.
Original PR description
`_update_layout` keyboard action method now also calls `_save_is_scanner` to reduce the number of call from the db to the IoT Box. Community PR: [https://github.com/odoo/odoo/pull/186326](https://github.com/odoo/odoo/pull/186326)
The Mexican localization demo company has been updated from Kemper School to a SAT-approved demo company that supports payroll stamping as well as existing electronic invoicing scenarios. This keeps demos and test flows usable for payroll, invoicing, stock, and accounting documents in Odoo 19.
Original PR description
The SAT has a list of ‘demo’ companies to enable invoicing demo operations through Electronic Data Interchange (EDI). Currently, in Odoo, the default demo company is Kemper School. However, with the release of payroll stamping in version 19, this company is no longer useful, as it cannot stamp payroll. So, instead of adding another company, we modified the Kemper School data to change it to another company that can stamp payroll and all other existing documents. The demo company data was changed, the certificates were changed, and a file that was never added to the manifest and therefore had no use was deleted. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95221
Follow-up and customer statement reports now have a cleaner header with centered titles and less clutter. Bank account information is shown near the tax ID, making key customer payment details easier to find.
Original PR description
This commit updates the layout for follow-up and customer statement reports. Changes made: --- **Follow-up & Customer Statement Reports:** - remove journal and filter details from header. - centered the title of the report. - Added the partner bank account display below the Tax ID. --- task-4823880 Forward-Port-Of: odoo/enterprise#97546 Forward-Port-Of: odoo/enterprise#90068
Resolved issues and error corrections
Financial reports now use the correct closing exchange rate for currency translation adjustments, reverting a prior change that used the current rate. This helps ensure reported balances are more accurate and consistent for accounting and reporting decisions.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888 Forward-Port-Of: odoo/enterprise#97541 Forward-Port-Of: odoo/enterprise#97271
Manual AI server actions now include the current record information they need to complete follow-up actions such as creating records, scheduling activities, or sending emails. This makes manually triggered AI workflows behave consistently with automated ones and also improves access to AI auto-sort tools from the documents setup modal.
Original PR description
Purpose: -------- Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed. Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation). This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed). Task-5107876 Forward-Port-Of: odoo/enterprise#95343
This fix makes scheduled product image lookups more reliable by replacing an inefficient safeguard with a cleaner scheduling approach. It also reduces unnecessary background processing overhead, helping keep broader scheduled task creation efficient.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected. Forward-Port-Of: odoo/enterprise#97411
Fixed an issue where undoing automatic rescheduling in the Gantt planning view could trigger an error instead of restoring the previous schedule. This helps manufacturing planners safely use auto-reschedule and undo changes without interrupting their workflow.
Original PR description
When rescheduling workorders in mrp's Planning by Workcenter using Auto-Reschedule mode and then Undo-ing, a bad query error occurs, due to
WHERE "mrp_workcenter"."id" IN ('m', 'r', ...
This comes from web_gantt_reschedule returning something like
{'3': {'date_finished': '2025-10-20 11:43:51',
'date_start': '2025-10-20 09:43:51',
'workcenter_id': 'mrp.workcenter(1,)'}}
Forward-Port-Of: odoo/enterprise#97717This fix ensures write-off entries created during journal item reconciliation are always treated as standard journal entries. It prevents errors caused by customized default entry types, helping accountants complete reconciliations reliably.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
Belgian reporting fields now respect the right access group when the Accountant app is not installed. This prevents users from seeing access errors and keeps the fields hidden when they are not available to them.
Original PR description
This commit fixes the access right problem for `l10n_be_region_id` and `l10n_be_company_type_id` when `accountant` is not installed. When `accountant` is not installed and users have `l10n_be_reports` installed, an access error was raised when these fields were accessed. A group `account.group_account_user` is added to these fields such that they become invisible when when `accountant` is not installed. task-5156687 Forward-Port-Of: odoo/enterprise#97759
UPS shipment requests now include the VAT numbers for the sender and customer. This ensures commercial invoices generated for cross-border UPS deliveries show the required tax information instead of leaving VAT fields blank.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356
Shopee orders that are delivered but still waiting for buyer confirmation will now be treated as a normal delivery state instead of an error. This prevents unnecessary error flags and helps teams track Shopee deliveries more accurately in Odoo.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
This update fixes several payroll accounting setup issues so salary structures receive the correct default journal regardless of installation order or active company. It also improves reliability of localization tests without demo data and prevents Chilean electronic invoicing logic from affecting documents for other countries.
Fixed an issue where budget line reports could show committed amounts twice when a bill used analytics from multiple plans. The report now matches the specific budget line, giving users accurate committed amounts for budget tracking.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
Automatic printing after validating a delivery now includes both shipping labels and shipping documents in the normal validation flow. This prevents missed print actions when the page reloads, making delivery processing more reliable for users with connected IoT printers.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97761 Forward-Port-Of: odoo/enterprise#97462
A test for selecting an invalid rental period on the website shop was adjusted to avoid inconsistent failures caused by timing issues. This helps keep automated checks stable so future changes to online rental flows can be validated more reliably.
Original PR description
This blows up locally, but apparently not on runbot. It's also extremely odd because splitting the 4 operations into separate steps does not fix the issue (let alone just adding a timeout before performing both the edition and the tabbing), only when everything is the same `run()` step does it reliably fix the issue. Also apparently only necessary for the `end` step, not either of the `start` steps. <insert confused nick young>
This fix prevents an error when settling invoices in Point of Sale if a customer's related commercial partner details were not fully loaded. The process now uses the already available partner ID, making invoice settlement more reliable for users.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-5112883 Forward-Port-Of: odoo/enterprise#96828
The spreadsheet collaborative status tooltip now appears in the user's selected language. This improves consistency for multilingual users and avoids untranslated interface text in collaborative spreadsheet workflows.
Original PR description
Tooltip in collaborative status component was not translated. Task: 5164097 Forward-Port-Of: odoo/enterprise#97075
Public and portal users can now print or export shared Knowledge articles without getting blank pages. The fix ensures the right print styling is loaded and removes conflicting Planning print rules, improving reliability for customer-facing documentation and shared content.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96656 Forward-Port-Of: odoo/enterprise#92665
Trial Balance PDF exports now correctly respect search filters when hierarchy and subtotals are enabled. Users can filter exported reports by account details or account group names, ensuring the PDF matches the report view and shows the expected lines.
Original PR description
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create…
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create an account group (e.g Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance ) - In the Options select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to pdf #### Current behavior: - No lines are displayed in the pdf as the backend uses only the account name to apply the filter #### Expected behavior: - Lines are displayed using account name and group name to filter #### Cause: - Filter was applied only on account name #### Solution: - If hierarchy is enabled, display accounts where filter appears on either account or group opw-4906593 Forward-Port-Of: odoo/enterprise#96338 Forward-Port-Of: odoo/enterprise#90403
Fixed an accounting issue where deferred dates on bill receipts could be cleared and related deferral entries could use the wrong account. This helps ensure receipt-based deferred accounting is handled consistently with bills and sales documents.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5.…
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97824 Forward-Port-Of: odoo/enterprise#97653
Features or functions removed from Odoo
A web_studio-specific check for saving embedded fields was removed because that behavior now belongs in the website area. This keeps responsibilities clearer internally and should not affect day-to-day users.
Original PR description
`save_embedded_field` is being moved to website, as it's website-specific. This check is not necessary anymore. task-5065980
Code cleanup and technical improvements
The SEPA Direct Debit module now reuses an existing calculation when checking online payment status and related payment counts. This reduces duplicate processing behind the scenes, which can improve efficiency without changing user workflows.
Original PR description
The compute methods for the `is_online_payment` and `payment_transaction_count` fields rely on exactly the same read_group. This commit refactors the `_compute_is_online_payment` method to reuse the result of the computation of `_compute_payment_transaction_count` in cache, thus avoiding two `_read_group` calls.
This update replaces older jQuery-based frontend code with modern standard JavaScript across several Odoo areas. It should help keep the platform easier to maintain and prepare these customer-facing pages for future improvements without changing business workflows.
Original PR description
task-3770362
This update standardizes how true/false values are checked across several Odoo apps. It is an internal code cleanup that should not change user workflows, but helps keep the system easier to maintain and less prone to subtle inconsistencies.
Original PR description
odoo/odoo#220171
The IoT box update process has been cleaned up by removing outdated logic and unnecessary checks. This makes the update flow easier for support teams to troubleshoot, with minimal direct impact on users.
Original PR description
The update box method had old unsupported code, and redundant checks. It has been simplified to ease debugging.
16 changes
Enhancements to existing features
The Taiwan localization now includes updated balance sheet and profit and loss reports that better match common Taiwanese business practices. The previous report versions are kept as legacy for now but are planned for removal in a future version.
Original PR description
This commit adds new improved accounting reports (balance sheet & profit & loss), providing users with improved reports that aligns better with the common Taiwanese business practices. The old balance sheet and profit & loss reports are depreciated and will be fully removed in later versions. [Task-4915057](https://www.odoo.com/odoo/project.task/4915057)
The Taiwan localization now includes a refined chart of accounts and updated default accounts aligned with common local business practices. This helps Taiwanese companies start with accounting structures that better reflect publicly listed company reporting formats.
Original PR description
This commit adds improved Chart of Accounts for Taiwan to better match common business practices. The chart of accounts, balance sheet, and profit and loss are referenced from the accounting structures used by publicly listed companies in Taiwan to ensure relevance and practicality. Updates: - Revise Taiwanese chart of accounts - Revise Taiwanese default accounts [Task-4915057](https://www.odoo.com/odoo/project.task/4915057) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts image shape controls in the HTML builder, making it easier to manage how images appear on web pages. It helps editors create more polished page layouts with a small usability improvement.
Resolved issues and error corrections
Shopee delivery orders that are delivered but still awaiting buyer confirmation are no longer incorrectly marked as errors. This prevents unnecessary error states and helps teams track delivery progress more accurately in Odoo.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
This change ensures older browsers load the compatibility support needed after users log into Odoo. It prevents backend crashes so affected users can continue using Odoo normally.
Original PR description
Description of the issue/feature this PR addresses: Old browsers crashing for Odoo 19.0 after logging into backend ``` TypeError: this._tables.difference is not a function\n at request.onsuccess (http://.../web/assets/d7f7d1b/web.assets_web.min.js:4763:464) ``` Current behavior before PR: Polyfill for Set difference() is only loaded in web.assets_frontend_minimal and not loaded after login since 2d56c0930f824ae9a8fd33c376e1dd9f34900ffa Desired behavior after PR is merged: Polyfill for Set difference() is also loaded in backend and the User can use Odoo. References: https://www.odoo.com/de_DE/forum/hilfe-1/error-code-new-to-odoo-278378 https://www.odoo.com/de_DE/forum/hilfe-1/there-is-an-error-please-solve-this-error-282526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Info @wt-io-it
This change prevents a client-side error that could appear when using Odoo 19 on mobile browsers, especially Safari on iOS. It replaces a browser-incompatible operation with a standard approach, improving reliability for mobile users on newly created databases.
Original PR description
Description of the issue/feature this PR addresses: Error occurred only on mobile device on v19.0 community installation with new created database. On the same device and browser no error on v18.0…
Description of the issue/feature this PR addresses:
Error occurred only on mobile device on v19.0 community installation with new created database.
On the same device and browser no error on v18.0 but always this error on v19.0
Error:
———————
UncaughtPromiseError > TypeError
Uncaught Promise > this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
Occured on mydomain.fr on 2025-09-17 19:05:42 GMT
TypeError: this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
@https://mydomain.fr/web/assets/debug/web.assets_web.js:48443:58 (https://mydomain.fr/web/assets/debug/web.assets_web.js:48443)
———————
Analyze:
——
Original: Using .difference()
const newTables = this._tables.difference(dbTables);
- This syntax assumes that _tables is a Set and that the difference method exists.
- However, native JavaScript has never defined Set.prototype.difference in the ECMAScript specification.
- In some environments (e.g., Node.js with a polyfill, or certain experimental JS engines), it might exist, but Safari does not have this method, which causes the error.
FIX: Using filter and new Set()
const newTables = new Set([...this._tables].filter(x => !dbTables.has(x)));
- Here, we convert _tables to an array, filter out elements that are not in dbTables, and then create a new Set.
- Everything is standard ECMAScript, so it works in all modern browsers, including Safari on iOS
Fix:
Use standardized JS function supported by all browsers in indexed_db.js
Test:
All is fine, no more error on client side
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where company-specific special products could be missing from Point of Sale configurations for that same company. This ensures stores can reliably access the products assigned to their company after reloading PoS data.
Original PR description
### Problem When assigning a special product to a company, the product will not be loaded when accessed from a PoS config of the same company. The issue occurs because `product.sudo().company_id == self.company_id` fails as `self` is an empty recordset. ### Steps to Reproduce on Runbot * Add a company to the special PoS product. * Access a PoS config on the same company. * Reload data. * The product will not be loaded. original PR: https://github.com/odoo/odoo/pull/194451 opw-5157959 Forward-Port-Of: odoo/odoo#231273
This fix strengthens spreadsheet dashboard validation so carousel items are checked for the correct models and fields. It helps prevent dashboards from relying on unavailable data, reducing configuration errors and broken dependencies.
Original PR description
The json validation didn't check the fields and models of carousel figures. Obviously, it already lead to wrong dependencies: in the Product and Sales dashboard, a domain uses the field `product_tmpl_id.recurring_invoice` which defined in another module which is not a dependency. Task-5138412 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 fixes the French VAT report submission so address details follow ASPOne’s required validation rules. It helps prevent rejected filings by limiting postal code and city values correctly and using the expected address field format.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
This fixes duplicate screenshots and screen recordings when automated tests fail, reducing unnecessary files and avoiding related crashes. It also saves recording frames directly as readable PNG images, making failure evidence more reliable if a test run stops unexpectedly.
Original PR description
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok`…
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure. Do a bit of rejiggering to fix things up: - in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing) - only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already. And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs. Forward-Port-Of: odoo/odoo#232472
This fix prevents module updates from failing when users have edited or duplicated default UTM tracking names such as LinkedIn. Marking the default tracking records as not updated preserves user changes and avoids uniqueness conflicts during upgrades.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
The collaboration status tooltip in spreadsheets now appears in the user's selected language. This improves clarity for multilingual teams and provides a more consistent localized experience.
Original PR description
Tooltip in collaborative status component was not translated. Task: 5164097
This fixes problems that could make Odoo's internal profiler crash, hang briefly, or produce unusable results when stopping after a set number of entries. The change improves reliability for performance diagnostics, helping teams investigate issues without profiler-related interruptions.
Original PR description
Issue: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. Cause: - The profiler has two ways to exit. One is through the context which calls…
Issue: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. Cause: - The profiler has two ways to exit. One is through the context which calls the end() through the parent thread. Another is reaching the entry_count limit or whatever limit used. The exit this way was called through the child thread of the collector. This caused a deadlock as the thread was waiting for itself, which caused python to through out an error "cannot join current thread". Solution: - The solution for this issue is to set an event from the child thread, have the parent spawn another thread that waits for that event so it doesnt block the main thread, and then joins when the even is set. Issue: - Another issue was that the periodic profilers were waiting the full amount of the sleep before ending. Cause: - This was caused because the join waits until the function of the thread is done. Which means it would wait until the sleep is done either way. Solution: - This was also circumvented with the same way by using an event wait. The event wait is broken as soon as the event is set, but it waits a default amount of time before releasing the wait. Issue: - Another issue is that when using the entry_count, the memory profiler was throwing a non serializiable object. Cause: - This is because when accessing the entry_count, which was accessing the entries attribute. This attribute to calculate was triggering the post processing function as well. The post processing function is called once per collector and then it does not enter the function. If the object was not post processed correctly, the collector would have entries that have tracemalloc object. This object is not serializable. Solution: - A simple counter was used instead of the entry_count to check. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users who choose to handle notifications inside Odoo and also enable browser push notifications will no longer receive two alerts for the same message. This reduces confusion and notification noise when users are working with Odoo open in a browser tab.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221259The point of sale customer display now automatically scrolls to show the currently selected order line. This helps customers see the latest or active items clearly during checkout, reducing confusion at the register.
Original PR description
Steps to reproduce: - Turn on customer display in point of sale - Add some order lines - Customer display doesn't auto scroll Current behavior: - Customer display doesn't auto scroll Expected result: - Customer display should scroll to the selected lines
Documentation and clarification updates
This pull request adds Harold Campo's signed Contributor License Agreement record to the project documentation. It supports legal compliance for accepting contributions and has no effect on Odoo product features or users.
Original PR description
Add CLA for Harold Campo 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
12 changes
Resolved issues and error corrections
This update ensures French VAT report submissions sent to ASPOne follow the required format rules. It helps prevent submission errors by using the expected address field and limiting postal code and city values to accepted lengths.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
Saudi e-invoices now preserve the negative amount on tax-exempt invoice lines instead of sending it as a positive value. This prevents avoidable ZATCA validation warnings and helps ensure invoices with refunds, discounts, or negative exempt lines are reported accurately.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
This fix prevents module updates from failing when default tracking sources or mediums have been renamed or duplicated by users. It helps keep CRM live chat and UTM tracking data stable during upgrades without disrupting existing customizations.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
The HTML editor toolbar no longer appears when users select non-editable content inside an editable area, such as protected report elements. This reduces confusion and prevents users from seeing editing options that do not apply, while still allowing toolbar editing for icons.
Original PR description
Before this commit: The toolbar appeared even when selecting a contenteditable false element within the editable area. For instance, while editing a report, clicking on a non-editable element like a delivery slip would still show the toolbar. After this commit: The toolbar is hidden when the selection is within contenteditable false elements or consists only such elements. Exception: The toolbar remains visible for icons, as they are editable by the toolbar. Tests are added. task-4309925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now open link previews for frontend pages like Contact Us or shop category pages without browser errors or incorrect warnings. The link popover also shows available page descriptions, making it easier to verify and manage links while editing content.
Original PR description
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. -…
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. - Click on a link to a frontend page, such as "Contact Us". - An error was thrown in the browser console. - Also, the link popover did not show the page description (even if it existed). This commit: - Fixes the error that occurred in the browser console. - Adds support for frontend website pages in the link popover. - Displays the page description in the linkpopover, if available. (The page description refers to the SEO field that can be set via: Site > This Page > Optimize SEO > Description) Commit 2: b8908f3 Before this commit: the condition to check if an url is internal is not complete as the user could user the odoo instance domain instead of the real domain. The check if an internal url is a frontend one is rather naive as there are cases where the url ends with a number but actually not leading to a record. Reproduction for the second use case: 1. create a link with frontend url for example `/shop/category/16` 2. click on the link, when it loads the preview, a warning pops up After this commit, the cases explained above are included. task-4971829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now correctly finds matching text even when it appears after a line break in longer descriptions or formatted content. This ensures automated rules and filters trigger as expected when using "contains" searches across multi-line text.
Original PR description
Problem: When the ilike comparator is applied in filtered_domain, it is unable to match text beyond a newline character (\n). This is due to the regex being used not having the DOTALL flag. Purpose: Add the DOTALL flag to the re.compile arguments when defining like_regex. Steps to Reproduce on Runbot: 1. Create an Automation Rule on the Task model with an Apply On condition of Description contains "test". 2. Create a Task and add an Info Banner element, then either within the element or afterwards include the "test" text, then save. 3. The automation rule does not trigger. opw-5134374
Delivery label printing now includes every attached label file in the chatter instead of printing only the first one. This ensures shipments with multiple label files are handled correctly, reducing manual reprints and fulfillment errors.
Original PR description
Before this commit, only 1 label get printed even if multiple files are in the chatter After this commit we handle the cases with multiple files + revert suppression of public method for API opw-5181209 Forward-Port-Of: odoo/enterprise#97805
The blog sidebar's "Add some" tag link now opens the correct backend tag management page instead of sending users to the homepage. This helps website editors quickly add or manage blog tags without hitting a broken navigation path.
Original PR description
Scenario:
- go on frontend to a blog post without tag
- edit the page and in Customize enable the sidebar
- click on "Add some" link in tag section
Result: the link is like /odoo/action-/1?menu_id=451 and redirects to
the homepage.
Cause: there is no action variable set in the view from 16.0 up to master,
not having the action worked in URL that contained the model and record id
before 18.0 update (9cf0b8c256589ccd71b01bd28bd2e595848ff45e) but it
doesn't work with /action-{action_id}/{res_id}.
Fix: using the model route directly (that is what we would be redirected
if we used the old URL path).
opw-4706629
opw-4783643Public ecommerce customers could get stuck after a successful payment because the system hit an internal access error while confirming accounting records. This fix ensures the payment confirmation can complete reliably when restricted journal security settings are enabled.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189
Long mailing list names now stay within their designated area instead of covering nearby fields. This keeps the Marketing mailing list view readable and easier to use when lists have lengthy names.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users crop an image manually and then apply a shape, Odoo now keeps their chosen crop instead of reverting to the original image. Reset controls are also shown and styled more consistently, making image editing in the website editor clearer and more reliable.
Original PR description
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task…
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task [3678061](https://www.odoo.com/odoo/my-tasks/3678061), all shapes were applied using a 1:1 ratio for better UI. However, we didn’t account for cases where the user had manually cropped the image. In such cases, the shape was being applied to the original image with forced 1:1 cropping, ignoring the user's manual crop. Fix: Previously, applying a shape always cropped the image to 1:1 if crop was required and the aspect ratio wasn't already 1:1. This caused the user's custom crop area to be discarded. Now, a new `is-manual-crop` attribute is introduced. If present, the default 1:1 crop is skipped, preserving the user's manual crop. Also, the reset button didn’t appear for flexible crops(not using fixed ratios like 1:1 or 2:3) due to aspect ratio being 0/0. We now add the `o_we_image_cropped` class on save and remove it on reset to properly show or hide the reset button. After cropping, the reset button appears in red, while the transform reset button is grey. To maintain consistency, we are adding the `o_we_bg_danger` class to transformation button. This PR aims to respect the user’s manual crop when applying shapes. task-4718769
This change makes an automated mail test more consistent by setting a visual border value explicitly. It helps prevent environment-specific differences from causing build failures, improving reliability for future updates.
Original PR description
Problem: Runbot build fails due to different resulting `border-color` values. Cause: The default `border-color` can change depending on the environment, leading to non-deterministic behavior. Solution: Specify the `border-color` explicitly to ensure consistent results. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
7 changes
Resolved issues and error corrections
This fix prevents module updates from failing when users have edited or duplicated default UTM tracking names such as LinkedIn. It protects business continuity by allowing updates to complete without triggering uniqueness conflicts in marketing tracking data.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
Event registrations now request the reCaptcha check only when the user submits the form. This prevents valid attendees from being blocked if they take more than two minutes to complete registration.
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
Portal users can no longer edit the customer field on shared project tasks, preventing accidental removal of the customer that they cannot restore themselves. The fix also restores reliable task creation for portal users by avoiding an access error when assigning the default customer.
Original PR description
Since the user can only set himself as customer for task in the portal view, we removed this option in order to avoid issues on the customer side. E.A. setting the customer to False, then save, and being unable to put back the original customer. 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
New field service tasks created from the portal now automatically use the current user as the customer when none is provided. This prevents task creation failures caused by a missing mandatory customer and makes field service workflows more reliable.
Original PR description
When creating a new FSM task in the portal view, the current user will now be set as default user instead of False. The fix is done to be more generic. The customer field is mandatory on fsm tasks, but there is no restriction on it in the backend side. So we might encounter a similar issue again. With assigning a default user for fsm tasks at the creation, we ensure that the field is always set.
Project and sales administrators can now open and manage SMS templates used for projects and tasks without running into access errors. This removes an incorrect permission restriction and ensures template rules apply to the right project-related records.
Original PR description
**Issue** Project administrators are not able to manage SMS templates related to project models. **Steps to reproduce** - Have `project_sms` and `sale_sms` installed. - Have a regular user (not admin) with Project: "Administrator" and Sales: "Administrator" rights. - Go to Project/Task kanban view > cog icon on top of columns > edit > try to open/modify the SMS template. Issue: access rights error **Cause** - the rule in `sale_sms` is problematic because it is the only record rule affecting read operations, while other modules only target CUD operations. It has the effect of restricting read operations for Sale:Administrator users. - the rule in `project_sms` was referencing the wrong models, SMS templates are linked to `project.project` and `project.task`. opw-4908909
Miscellaneous changes
This pull request corrects a minor typo in the Spanish translation. The term "Concepto Nota de Crédito" was missing the accent on "Crédito". This fix improves visual consistency and translation accuracy in the l10n_co_edi module.
Original PR description
This pull request corrects a minor typo in the Spanish translation. The term "Concepto Nota de Crédito" was missing the accent on "Crédito". This fix improves visual consistency and translation accuracy in the l10n_co_edi module.
This pull request corrects a minor typo in the Spanish translation. The term "Concepto Nota de Crédito" was missing the accent on "Crédito". This fix improves visual consistency and translation accuracy in the l10n_co_edi module.
Original PR description
This pull request corrects a minor typo in the Spanish translation. The term "Concepto Nota de Crédito" was missing the accent on "Crédito". This fix improves visual consistency and translation accuracy in the l10n_co_edi module.