Daily updates from Odoo
Wednesday, October 22, 2025
68 changes
10 changes
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
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
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
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
This fix prevents an error when settling an invoice in Point of Sale if the customer’s commercial partner details were not fully loaded. The system now uses the already available partner ID, making invoice settlement more reliable for cashiers and staff.
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
Contacts in the Dominican Republic can now use valid 11-digit Cédula tax ID numbers, not only 9-digit RNC numbers. This prevents valid customers or partners from being rejected during VAT checks.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228077 Forward-Port-Of: odoo/odoo#224507
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from automatically using taxes that should no longer be available. This helps keep invoice tax calculations aligned with current tax settings and reduces the risk of incorrect accounting entries.
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#231462 Forward-Port-Of: odoo/odoo#230729
A typo in Web Studio’s new field list was corrected from “Multine” to “Multiline.” This improves clarity for users creating or editing views and avoids a small but visible labeling mistake.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Invoice terms and services now refresh in the selected customer language when that language is changed during invoice creation. This prevents customers from seeing outdated or untranslated terms on invoices, improving communication accuracy.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
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
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
The event registration page now shows the date selection labels in the visitor's chosen language. This improves the experience for multilingual event attendees by avoiding untranslated English text during registration.
Original PR description
Scenario: - adds slots to an event - register to that event with another language Result: "Selected Date" or "Select a Date" is not translated or translatable. Fix: wrap those JS strings with _t function. opw-5167911
This update fixes and improves Odoo's internal unit testing tools, especially Hoot, so developers can diagnose failed tests and server errors more accurately. It also improves the test interface and documentation, reducing maintenance friction while keeping changes limited to the testing ecosystem.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/97851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232474 Forward-Port-Of: odoo/odoo#231263
This pull request updates several automated tests so they work correctly with recent changes in Odoo's Hoot testing tools. The changes are limited to the test environment and help keep quality checks reliable without affecting customer-facing features.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/232536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A typo in the Web Studio field list was corrected from “Multine” to “Multiline”. This makes the field name clearer and avoids confusion when users create or edit views in Studio.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Invoice terms and conditions now refresh in the customer's selected language when that language is changed during invoice creation. This prevents invoices from showing terms in the wrong language and helps maintain clear communication with customers.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
Long mailing list names now remain inside their designated area instead of overlapping nearby fields. This keeps the Marketing mailing list view readable and easier to use when records 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 Forward-Port-Of: odoo/odoo#232312
4 changes
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
A point-of-sale restaurant preparation display test was corrected to match the latest behavior for empty preparation tickets. This helps keep automated quality checks reliable and reduces the risk of false test results during updates.
Original PR description
pos_* = post_restaurant_preparation_display Before this PR (https://github.com/odoo/odoo/pull/231733), the checkPreparationTicketData method returned True if the preparation ticket was empty. This is no longer the case, so the test has been updated to work correctly now. Related Community PR: https://github.com/odoo/odoo/pull/231733
A spelling mistake in Odoo Studio’s field options was corrected from “Multine” to “Multiline.” This helps users see the intended field name clearly when configuring views.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Sales users planning service work from a sales order can now see and enter allocated hours when creating a planning slot. This restores an important scheduling field in the specific flow where the combined date-and-hours widget is hidden, helping avoid incomplete shift planning.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776
7 changes
Resolved issues and error corrections
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#97717Belgian 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
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
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
18 changes
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 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 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
Contacts in the Dominican Republic can now use valid 11-digit Cédula tax identification numbers without being rejected. This prevents incorrect validation errors when saving customer or partner VAT details.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228077 Forward-Port-Of: odoo/odoo#224507
This fix prevents certain batch payment tests from running when the required accounting app is not installed. It helps keep automated checks reliable without affecting day-to-day users.
Original PR description
We have tests for payment wihtout journal entries. But these payments can only be generated if accountant in installed. It makes these tests fail if the module is not installed. To avoid making a bridge module only to test these, we add a class that will be skipped if the module is not installed. runbot-232728
Customers receiving Gelato shipping notifications will now get a working tracking link when their order ships in a single parcel. This prevents broken links in delivery emails and helps customers follow their shipment without contacting support.
Original PR description
After receiving the shipping webhook from Gelato, we send a shipping notification with the tracking information to the customer. This commit fix the tracking url for single parcel, which was pointing to an inexistant url. opw-4637331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232520 Forward-Port-Of: odoo/odoo#232071
This fixes an issue where settling an invoice in Point of Sale could fail if full commercial partner details were not loaded. The system now uses the already available partner ID, making invoice settlement more reliable without changing the user workflow.
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
Odoo now shows a clear validation message when a user enters a check number that is too large for a bank journal. This prevents confusing technical errors and helps accounting users correct the value immediately.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225103
This fix prevents the editor's page monitoring service from repeatedly reconnecting when a user lacks permission to access a related document. It avoids unnecessary log noise and makes the system behave more reliably by not subscribing users to channels they cannot access.
Original PR description
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img…
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" /> Each reconnect attempt causes a log entry: ``` 2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Marc Demo (id=6) doesn't have 'write' access to: - Lead/Opportunity, Modern Open Space (crm.lead: 25) Blame the following rules: - Personal Leads If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. ``` Current behavior before PR: Reconnect loop. Desired behavior after PR is merged: Do not add channels without sufficient rights. Related to: https://www.odoo.com/de_DE/my/tasks/5026412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231599 Forward-Port-Of: odoo/odoo#223890
Odoo now correctly uses the icon specified in a module's manifest before falling back to the standard default icon. This ensures modules display their intended branding or visual identifier wherever module icons are shown.
Original PR description
Description of the issue/feature this PR addresses: The `get_module_icon` function is used in multiple places allowing to default to the standard icon if none is found. First, if the module already has a checked icon as a cached property, just return it. Afterwards, read the raw value from the manifest as the icon to check, we were checking only the default location so the cached value effectively ignored what was defined in the manifest. Current behavior before PR: 'icon' attribute is ignored in the manifest. Desired behavior after PR is merged: Check the icon defined in the manifest before defaulting to the default icon location. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Performance tests for the online shop page were updated so they no longer fail because of expected differences in demo data or installed apps. This helps teams keep monitoring page speed reliably while reducing false alarms in automated testing.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/233319 FAIL: TestWebsiteAllPerformancePostInstall.test_perf_sql_queries_shop FAIL: TestWebsiteAllPerformance.test_perf_sql_queries_shop AssertionError: 65 not less than or equal to 37
This fixes a visual inconsistency where some website badges appeared larger than intended after a prior styling change. Badges now keep the expected size, preserving a consistent look 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 Forward-Port-Of: odoo/odoo#230530
The API documentation now generates JavaScript examples that send request data in the correct format. This prevents users from encountering failed requests when copying examples from the documentation.
Original PR description
**Current behavior before PR:** Before this commit, the example generated for JS was incorrect and returned a 400 Bad Request error. This was due to the fact that we must use `JSON.stringify` on the body before making the request. **Desired behavior after PR is merged:** JS example works --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The ESG dashboard graphs now use colors that display correctly in both light and dark mode, making the data easier to read for users. On mobile, the initiative card layout was also adjusted to leave more room for key action buttons.
Original PR description
Before this commit, the color chosen for the graphs in the ESG dashboard does not take into account the dark/light mode and so they does not have the right color when the user is in dark mode. This commit makes sure the graphs are well rendered in dark mode. task-5138512
Customers viewing product pages can now click a product image once to zoom in and click again to zoom back out. This makes image browsing smoother and avoids shoppers getting stuck in a zoomed-in view.
Original PR description
Step to reproduce: 1. Install 'website_sale' 2. Create a product with an image 3. Open its page on the website via smart button 4. Click on the product image **Issue:** - After zooming in on the image with mouse click, there is no option to zoom out with mouse click. **Solution:** - Implement a toggle mechanism: - First click on the image zooms in - Second click zooms out opw-5104526
14 changes
Resolved issues and error corrections
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
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-4783643Long 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
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
Spanish point-of-sale receipts now correctly display the company's state name instead of empty brackets. This avoids confusing or incomplete receipt details for businesses using simplified invoices in Spain.
Original PR description
**Steps to reproduce:** - Set a spanish company, set the state - Set the "Simplified Invoice" journal in the settings - Go to PoS and make a purchase - On the receipt, empty brackets are shown where the state should be **Why the fix:** Before this commit, we checked that the company had a state set, and if it had, we displayed *state_id[1]* between brackets. Even if the state_id existed, this is not the correct structure for the state_id, so *state_id[1]* did not exist, and we displayed only the brackets. We now display the correct state name, still between brackets. opw-5098212
The website editor now correctly applies speed changes made with the slider for animated background shapes. This restores expected visual customization behavior when users design pages with animated snippets.
Original PR description
Steps to reproduce: - Drop a snippet - Add a background shape (e.g. Rainy 05) - Use the slider to change the speed - Nothing happens This commit is adapting `CSS_ANIMATION_RULE_REGEX` as it was too restrictive, the space after the colon is now optional. task-5170549
This change fixes how Odoo's web test tools handle custom responses during automated testing. It helps ensure tests behave as intended when a developer supplies a complete response, reducing misleading test results and improving development reliability.
Original PR description
Before this commit, when an 'onRpc' handler would return a 'Response' object, it would still be wrapped in a JSON-RPC payload (under the 'result' key) if the "content-type" header specified that it was a JSON-RPC. However, if a 'Response' object is returned by the handler, it usually means that the response should be that object as-is, as it was created with the desired final parameters. This commit ensures that 'Response' values are returned as they are, instead of being wrapped in a JSON-RPC payload object. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an Accounting issue where grouping customer invoices by sent status showed every invoice in both the Sent and Not Sent groups. Users can now rely on this grouping to accurately review which invoices have or have not been sent.
Original PR description
### Issue: The groups "Sent" and "Not Sent" display all the invoices. ### Steps to reproduce: - Go in Accounting > Customer > Invoices - Create a custom GroupBy with "Sent" - Unfold the groups: all invoices appear in each group ### Cause: `web_read_group` returns the groups with their length and the domain corresponding. When unfolding `web_search_read` uses the given domain to get the records to display. Here the issue comes from the domain returned, it contains `['move_sent_values', '=', 'sent']`, but `move_sent_values` is a computed field that doesn't have a `_search` method so the domain doesn't filter on this field. ### Solution: Add the method `_search_move_sent_values` to search on `is_move_sent`. opw-5164650
This fixes a formatting issue where page numbers could split across two lines in folder-style report footers when using the Montserrat font. Keeping the page number on one line improves the professional appearance and readability of generated reports.
Original PR description
The folder layout is using the same footer than the `external_layout_standard` but when using Montserrat, the page number wraps in 2 lines on the folder layout. It's missing a `text-nowrap` class. task-4942402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The blog archive preview test no longer depends on the English name for October. This prevents the test from failing when the website is used in another language, improving reliability for multilingual sites.
Original PR description
Before this commit the blog_tags_with_date tour tried to select the October option by label. In other locales the month label differs and the tour could not find it, so the tour aborted at that step. Steps to reproduce: - Change the website language to one where October has another name. - Run the blog_tags_with_date preview tour. The tour now selects the first month option by index, independent of labels. runbot-233321
A typo in the Web Studio field name was corrected from "Multine" to "Multiline". This improves clarity for users configuring views and helps avoid confusion when selecting field types.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Fixed a visual issue in the timesheet month view where text could spill into the timer and total/footer areas when users increased text size and scrolled horizontally. This keeps timesheet information easier to read and avoids confusing overlapping content.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182
4 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
The work center efficiency button now uses the same underlying figures as the detailed report, so managers see consistent OEE values in both places. This avoids confusion when reviewing manufacturing performance and also slightly streamlines the calculation.
Original PR description
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed…
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report. **Expected behavior:** Same values **Steps to reproduce:** 1. Make a workcenter and a BoM with an operation performed at the workcenter 2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration) * example: 0:20 expected, 1:01 actual 3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different **Cause of the issue:** the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values. **Fix:** Don't use the rounded intermediary values in computing `oee`. Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value). opw-4795463
The Helpdesk SLA reporting view now keeps the SLA status available as a grouping option after users remove the default grouping. This avoids forcing users to reload the report to get back to the original view organization.
Original PR description
Currently, when the user opens the sla reporting view, if he removes the default grouping of sla_status, he has no way to get it back unless he reloads the view completly. This commit fixes this issue by adding the sla_status field to the group_by options. task-5076401
The Field Service “To Schedule” view now excludes tasks that are already done or cancelled. This keeps scheduling lists focused on active work that still needs assignment or planning, reducing confusion for teams.
Original PR description
**steps to reproduce:** Go to field service Go to all tasks > to schedule **issue:** The To Schedule filter was also displaying tasks in cancelled or done state, whereas it should only show open tasks that need to be scheduled or assigned. **cause:** The filter domain did not exclude cancelled/done state, causing closed tasks to appear in the filtered view. **fix:** Updated the filter domain to exclude cancelled/done state, to ensure only open tasks are shown under the To Schedule filter. task-5138590