Daily updates from Odoo
Navigate
Branch
Monday, June 30, 2025
166 changes
72 changes
New functionality added to Odoo
A new Live Chat - Ongoing Sessions dashboard helps teams monitor active conversations and track how sessions are progressing in real time. This gives managers better visibility into workload and service activity so they can respond faster when conversations need attention.
Original PR description
This commit introduces the "Live Chat - Ongoing Sessions" dashboard which allows to track progression of ongoing live chat sessions. task-4805308
Enhancements to existing features
Recent visitor page views are now shown in the live chat channel information panel instead of the banner. This keeps important browsing context available to operators while making the chat banner less cluttered.
Original PR description
This commit moves the recent page views from the banner to the livechat channel info panel. task-4889090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers and sales users can now choose the unit of measure when buying or configuring products in the online shop and product configurators. Cart and configurator displays were updated to show quantities, product options, and selected units more clearly, with pricing corrected so base unit prices stay consistent across unit choices.
Original PR description
task-4485463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Search Panel now uses persistent caching so previously loaded options can be reused more reliably. This should make navigation and filtering feel faster while avoiding unnecessary refreshes when cached data has not really changed.
Original PR description
This commit will modify the search panel to use the new persistent cache introduced in [1] and [2]. [1] https://github.com/odoo/odoo/commit/f3d955b3235cb256bda79e834df38da0f6a4ac1a [2] https://github.com/odoo/odoo/commit/e5cee98d6ebbf318386ec4002007fbecc0fb3937 opw-4894490
The public employee area now shows the same updated help screen as the private employee area. This creates a more consistent experience for users viewing employee information and reduces confusion between the two views.
Original PR description
This PR adds the new help screen to the public employee action to align it with the private one. Task: 4886479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update aligns online rental, subscription, and appointment sales flows with recent shared platform changes. It helps keep product configuration and checkout behavior consistent across related sales features, reducing friction for customers and maintaining reliability after the backport.
Original PR description
Backport of 24e39d1a6169a36076e9dfcfba2200db8ab8748a (post-freeze) task-4485463
Australian payroll rule parameters have been updated for the 2025 period. This helps ensure payslip calculations stay aligned with current requirements, reducing manual adjustments for payroll teams.
Original PR description
Forward-Port-Of: odoo/enterprise#88323
Resolved issues and error corrections
Fixes a display issue in Mail where clearing a message while editing could make the empty message bubble stretch across the full conversation area. This keeps chat and discussion views cleaner and avoids confusing visual glitches for users.
Original PR description
This commit fixes a UI bug where editing a message and clearing its content results in the message bubble expanding to full width. **Current behavior before PR:**  **Desired behavior after PR is merged:** 
The live chat widget now waits for the correct availability check before showing the start chat button. This prevents visitors from briefly seeing a chat option that may not actually be available, creating a smoother website experience.
Original PR description
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it…
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it doesn’t consider the live chat rules.
These rules depend on the URL. Since `get_livechat_info` is called from the website template, we can’t determine which rule applies at that point. The goal is mainly to avoid calling `init_livechat` ("/mail/data") if we already know the live chat won’t be available. However, this check alone isn’t enough to decide whether to show the chat button.
This commit renames `isAvailable` to `can_load_livechat` for clarity. If `can_load_livechat` is set, we can load the live chat and call `init_livechat`, which will then set the `livechat_available` value.
task-4908197
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-prWebsite editing could show duplicate live chat bubbles and windows because both editing and visitor assets were loaded at the same time. This fix keeps the chat experience clean during website editing by hiding the extra chat elements with styling, avoiding more complex communication between page frames.
Original PR description
When editing is enabled, the website loads both the backend and frontend assets. Until [1], this resulted in two sets of chat windows and bubbles being displayed. This commit is a follow-up to the above PR, maintaining the same behavior but relying only on styles. This avoids the need for cross-iframe or cross -window communication. [1]: https://github.com/odoo/odoo/pull/212452 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
The messaging menu button in the top bar now displays with the correct background. This fixes a small visual issue so the interface looks consistent and polished for users.
Original PR description
This commit fixes a background issue on the messaging menu button in the systray. issue introduced by: https://github.com/odoo/odoo/pull/198012 before:  after: 
This fixes an issue where using the Tab key in the color picker could preview or apply colors incorrectly, including changing more text than selected in the editor. Users can now navigate color options by keyboard more reliably, reducing accidental formatting changes.
Original PR description
Following [1], which introduced the preview when focusing color buttons inside a colorpicker (and revert when focusing out of them), tabbing on the color selector within html_editor stopped working as expected: 1. the reset button doesn't trigger a preview 2. For instance in the To-Do app: - Select a single word - Open the "Apply Font Color" picker and use tab to navigate => The color of the whole line is changed. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This update fixes a broken automated test for the website editor so the test suite better reflects the current behavior. It helps maintain release stability by reducing false test failures during development and deployment checks.
Original PR description
This commit adapt the broken tests test_05_specific_website_editor.
Clicking a GIF preview in Mail now works without triggering an error when no click handler is available. This prevents a confusing interruption for users who open GIF links from messages.
Original PR description
**Current behavior before PR:** When a user posts a GIF link and clicks the preview, it opens in a new tab but throws an error because `props.onClick` is called unconditionally, even if undefined. **Desired behavior after PR is merged:** The issue is fixed by ensuring `props.onClick` is only called if it is defined. **Task**-4908537 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now only shows the quick-create option for grouped list and kanban views when the view uses its intended default grouping. This prevents confusing or unsupported behavior when users group records by other fields.
Original PR description
This commit updates the conditions for enabling group quick create in list and kanban views. In addition to existing checks, the view must now be grouped using its default groupby (if defined) for quick create to be available. This ensures that group quick create is only shown in contexts where it is properly supported and avoids undesired behavior when grouping by arbitrary fields. task-4897809
This fix improves the range slider used in the website builder so keyboard navigation no longer triggers repeated updates that can confuse sidebar options. It also makes keyboard focus styling clearer, improving usability for people navigating with the keyboard.
Original PR description
1) This commit adds proper styling on focus-visible on the BuilderRange. 2) When using the arrows to modify its value, it commited after every keydown. If the action relies on a load, the behavior is buggy. This is for instance the case on image optimization options: - Select an image - Set a filter on top > the "Quality" option appears - Use tab to focus it - Press an arrow and stay pressed for a while => The sidebar options are wrongly computed. To avoid that, we debounce the commit just like what was already done in the BuilderNumberInput. Note that while it prevents unwanted UI flickers and doesn't commit until after you let go of the key, the preview doesn't happen: this is due to the fact that each preview is cancelled by the next, preventing the load to ever complete, and thus the apply from happening. task-4367641
This fixes a small error in how the Time Off app checks which team members are currently online. The change makes the status check more reliable and reduces the risk of incorrect availability information being shown.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/198012 PR above made a typo in code in which list of "online" member IM status is a list of string, and it uses + to concatenate items like in python but this doesn't work in JS. Thankfully it kinda "worked" because this casted the array into list (e.g. `["a", "b"]` becomes "a,b") and other items were appended to string. Since this list was used for `.includes()` by chance the ".includes()" method is on Array and String and functionally this results to about the same intention... Again by chance!
Restores the missing help tooltip in the website builder's product filter dropdown. This makes it easier for website editors to understand filter choices such as recently viewed products when configuring product snippets.
Original PR description
> [LIPI] Missing dynamic filter help tooltip added in https://github.com/odoo/odoo/pull/196493 (quick fix: `title="fitler.help"` in dynamic_snippet_option.xml:9) Steps to reproduce: - Open website builder (with website_sale) - Drop snippet `s_dynamic_snippet_products` - Open the "Filter" dropdown and hover "Recently Viewed Products (...)" - Bug: No tooltip appears with a help message The tooltip with a help message on filter option was implemented on master in parallel of the initial refactor of the website builder. This commit adds the tooltip on the refactored builder Help on filter option: 5e21f518d285d0e3ca619ba3505ded6da5fb2e67 Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Website editors can no longer accidentally submit forms or navigate away by clicking page content while the builder is open. This keeps users safely in editing mode and avoids disruptions such as login attempts or forum post navigation during page edits.
Original PR description
> [ROLE] Go to '/@/web/login' > Edit > > - Click on "Login" => instead of allowing to edit the label, it opens the warning that every field must be completed. > - Enter a login/password and clock on "Login" > you're logged in, redirected, and now out of the editor iframe (every link is clickable). > - (Another way to reproduce the same bug: go to Forum > Help > New Post, then edit)
This fixes a crash that could happen in the website HTML builder when users moved the mouse while pressing a key. The change keeps editing interactions stable and avoids interrupting page-building work.
Original PR description
__Current behavior before commit:__ The `onMouseMoveOrDown` event listener is inside `throttleForAnimation` therefore it might be called asynchronously. In this case `ev.currentTarget` is `null` and the following traceback appears when we move the mouse while pressing a key in the html builder: ``` TypeError: Cannot read properties of null (reading 'removeEventListener') ``` __Description of the fix:__ Replace `ev.currentTarget` by `this.editable` since the `onMouseMoveOrDown` event listener is always added on the latter.
This update fixes several issues in website image galleries, especially when all images are removed. Galleries now handle empty states safely, show the add-image prompt only when appropriate, and keep navigation controls intact for easier editing.
Original PR description
Miscellaneous fixes about the image gallery: - survive when empty - "Add images" message display conditions - "Remove all" detroying the navigation
This fix prevents an error when loading restaurant sample data after product categories have been removed. It adds a fallback so the sample sushi combo product can still be created, helping users set up restaurant demos without manual troubleshooting.
Original PR description
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading…
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading the demo data. - new demo data has been added : odoo/odoo@94734feba5670b23acf73a2ad485efe3d480efc0 - `raise_if_not_found` conditions has been added for all demo data : odoo/odoo@e6430737bdcea0162e4a3d5ee82e9ab6caa697e9 Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete food category. 4. Navigate to Point of Sale → Load Restaurant Sample Data. 5. An error is triggered during the process. Error: ```python odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/odoo/saas-18.3/addons/pos_restaurant/data/scenarios/restaurant_demo_data.xml:605, somewhere inside ``` This issue occurs because `sushi_drink_combo` also references a missing product category. As with previous products, this change ensures a fallback to prevent failure when no categories exist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213345
This fixes an issue where Chrome could show a “too many redirects” error inside the website editor after translated page names changed. The editor now reloads the preview with a fresh URL when this browser cache behavior is detected, helping users continue editing without disruption.
Original PR description
Since [1], the fix introduced with [2] was lost. This commit adapts [2] to the new `WebsiteBuilderClientAction`. If you have the backend in a language A but the website in English only, you can: 1)…
Since [1], the fix introduced with [2] was lost.
This commit adapts [2] to the new `WebsiteBuilderClientAction`.
If you have the backend in a language A but the website in English only, you can:
1) modify a record's (event, product...) name in language A (say "New Name").
2) visit the page `/new-name-11` => the server will redirect you to the English page `/origin-11`, with the only slug that actually exists on the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the iframe, which in turn raises a CORS error when the app tries to update it.
At the time of this commit, the flow described here should be expected of users, because the translation UI in the backend is not clear: the default field displayed is in language A even though the website does not use it, and the way to update translations is not obvious (you have to click on the language tag, which doesn't look like a button).
After this commit, if we detect that behavior, we reload the iframe with a new query parameter, making the URL brand-new (and not cached) for Chrome.
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog (Obviously, reproducing it that way is not fixed by this commit.)
[1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
[2]: https://github.com/odoo/odoo/commit/16d47ddf128f31f13e8d0d74597635faf7f9702a
task-4367641The website builder now treats unset social media links as empty values rather than missing entries. This ensures all expected social media options remain available when editing a social media snippet, especially on databases without demo data or preconfigured links.
Original PR description
Steps to reproduce: - On a database without demo data (and no social links set) - Open website builder - Click on a social media snippet (by default there is one in footer) - Bug: social media not in the snippet are not present in the option The bug was introduced when changing the handling of empty social media records to fix a crash: d4621f81698cdbf3e6a1d72349b3e5f135e0ee53
Fixes an issue where installing a missing app from a website snippet did not refresh the website builder afterward. The install dialog now shows the correct app name instead of the snippet name, making the process clearer for users.
Original PR description
This was forgotten in the website refactor [1]. The builder was not reloading after installing a new module via the "Install" button on a snippet. The install module dialog was showing the snippet name and not module name, because of a forgotten recent change [2]. Adapted tests to check presence of the module name and not snippet name. Steps to reproduce: - Install website - Click install on a snippet that's missing its module (e.g. Donation button) - Install module dialog appears - Dialog should show the module name - Builder should reload after clicking on "Save and Install" [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [2]: https://github.com/odoo/odoo/commit/dd33ab018db7aa0fe7ad5e636636b75aaadd5d7a Related to task-4367641 Related to task-4434981
The website builder's Theme > Advanced section now shows the Code Injection and Google Map Custom Key controls as proper buttons. This improves clarity for users configuring advanced website settings and removes some unused internal code.
Original PR description
Before this commit, the buttons "Code Injection" and "Google Map Custom Key" in `ThemeAdvancedOption` were defined with the tag `button` instead of `BuilderButton` and were acting via `t-on-click` instead of using a `BuilderAction`. This commit converts the two elements to `BuilderButton` using `BuilderAction`. In addition, unused references are removed from `ThemeTabPlugin`. **How to reproduce** 1. In the website builder 2. In the "Theme" tab 3. In the "Advanced" section 4. Problem: the two objects on the rows "Code Injection" and "Custom Key" do not look like buttons. task-4367641
The website builder now hides the Header Position option when a sidebar header is selected, since that setting does not affect sidebar layouts. This prevents users from seeing a confusing control that has no visible impact while editing website headers.
Original PR description
> [BVR] select the "sidebar" header. Select "over the content" => no effect .. I think the option should be hidden for "sidebar" (check before mysterious egg). Steps to reproduce: - Open website builder - Click on the header - Change the "Template" to the last one: "Sidebar" - Bug: "Header Position" is still visible This bug was introduced during the initial website builder refactor. Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
This fix updates a web test so it uses a reliable record created during the test setup instead of depending on existing demo data. It reduces false test failures and helps keep quality checks stable for future releases.
Original PR description
Before this commit, the test TestLoadBreadcrumbs was failing with demo data. After this commit, the test uses a record created during the setUpClass, thus resolving the issue introduced in #212950 .
This fixes a regression in the HTML builder where special handling for style options like text and background colors was lost during a previous refactoring. Restoring this behavior helps users apply visual styling in the builder as expected, reducing disruption when editing website content.
Original PR description
Following the refactoring introduced in [1], the `builder_style_actions` which defines custom behavior for specific CSS styles such as `background-color` and `color` was unintentionally omitted. This commit restores its implementation. The `border-radius` style implementation, that still remains untouched will be restored in another PR: [2] [1]: https://github.com/odoo/odoo/commit/b4b2153 [2]: https://github.com/odoo/odoo/pull/215371
A daily automated check now keeps each employee linked to their correct current HR version. This helps ensure employee records stay accurate over time without requiring manual updates.
Original PR description
This adds a cron that will update the current_version_id of all employees every day. Task: 4886048
Saving changes in the website menu editor now preserves any page edits already made in the website builder. This prevents users from losing their work when adjusting navigation menus during website editing.
Original PR description
This plugin fixes a bug where making changes on the editor, opening the menu editor and clicking save would cause the changes to be discarded. Steps to reproduce: - Open editor - Make any change - Click on any navbar element (like Home) to open the navbar popover - Click on the edit menu button in the popover - A modal will open, click save - All changes have been discarded After the fix the changes will be saved when clicking save in the menu editor modal
This update fixes an internal validation issue in the HTML builder that could allow duplicate action identifiers when actions are defined in newer formats. It helps keep website editing behavior consistent and reduces the risk of unexpected builder conflicts.
Original PR description
With the changes of b4b215325db61fbbe9793545293c8b6fbc99f310, some actions are declared as classes with their id as a static field instead of an object for which th id is the key in the resource `builder_actions`. The check for unique action id has not been adapted and only checked if the key is not the id of another action. But for classes the key is not the id, which could lead to duplicates. It also introduced an inconsistency between the actions declared with objects and classes: the id field was added to the object, but not the other. As this field is not used, this commit removes it for both. task-4367641
When an invoice submission to Kenya's eTIMS times out, the system now checks whether the government already received it before trying again. If it was received, Odoo restores the confirmation details such as the QR code, reducing duplicate submissions and manual follow-up.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
This fixes which Helpdesk ticket form is opened from timesheet-related views so users see the appropriate ticket layout for their team restrictions. It helps prevent navigation to the wrong form and keeps the Helpdesk timesheet workflow consistent.
Original PR description
- Replaced `form_view_ref` from `helpdesk_timesheet.helpdesk_ticket_view_form_inherit_helpdesk_timesheet` to `helpdesk_timesheet.helpdesk_ticket_view_form_inherit_helpdesk_timesheet_restrict_teams`. - Add primary mode
A new automated check confirms that website rentals count both the start and end dates correctly. This helps prevent pricing or availability errors where a two-day rental could be calculated incorrectly.
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88671 Forward-Port-Of: odoo/enterprise#88264
This update adjusts internal test expectations for the Mail enterprise module after a recent merge caused performance checks to fail. It helps keep automated validation reliable without changing business functionality for users.
Original PR description
Started to fail just after merge, weird. runbot-227060
This fix ensures AI email rendering no longer changes shared settings provided by custom modules. It helps avoid unexpected behavior when the same settings are reused elsewhere, improving reliability for customized deployments.
Original PR description
In custom modules the caller parameters are reused, don't modify them in place as it is a bad practice and copy the dict.
This fix ensures that when users save a website form, the related access setting is properly applied instead of being skipped. It also makes the option clearer with a tooltip and improves reliability by avoiding inconsistent handling of form model information.
Original PR description
When [1] converted the form access option to fit inside `html_builder`, the form access was supposed to be enabled upon saving a form, but the used selector was incorrect, which led to the form access not being enabled. Also, a `ModelCache` was created which kept track of the same model but according to various ways to write this key. This system was flawed and led to reaching distinct object depending on the used "synonym" key. This commit: - fixes the selector used during the save operation - removes `ModelCache` and uses a plain cache with the model name as key in all situations - makes changes to form access included in the history - adds a tooltip on that confusing option [1]: https://github.com/odoo/enterprise/commit/689a2186fbe3b932b90bef3b64716c8443bad551 task-4367641
This fix keeps accounting report tests focused on the intended generic tax report, even when US accounting localization is installed. It prevents test failures caused by automatic switching to the US-specific report variant, improving release reliability without changing user-facing behavior.
Original PR description
https://github.com/odoo/odoo/commit/174fda9bde8460df0d819100aed7974321d43a59 added a new US variant for the tax report. When running the tests, some failed, because the active company was then a US one, and calling the generic tax report actually rerouted to that new variant. We now ensure we don't reroute in those tests by using the appropriate option key. runbot-226719
This update prevents errors when Belgian Intrastat VAT report export views are combined with related screens. It removes an empty view definition that could disrupt normal reporting workflows.
Original PR description
In l10n_be_intrastat, we have vat_report_export.xml, which contains an empty arch (because it had to be removed in master). But as this view is inherited by other views, it raises an error, because we're trying to merge a string (the inherits) and a None (the empty arch). We will remove the empty arch in 18.4 (as we did in 18.3), and remove totally the view in master, with an upgrade script. no-task
Features or functions removed from Odoo
The web interface no longer shows the reset filters button in the action helper. This simplifies the screen and removes an option that was no longer needed, with related view tests updated to match the new behavior.
Original PR description
This commit removes the button used to reset filters in the action helper. task-4891535
Miscellaneous changes
This commit fixes the calculation of the duration of an attendance record for an employee on a fully flexible working schedule. Previously, we were using the adjusted start and end times, which were adjusted from their original values to be the outer bounds of the interval made up of the original times and the UTC-converted times. This resulted in a duration that was too long. Now, we use the original start and end times to calculate the duration of the attendance because this value is ti
Original PR description
This commit fixes the calculation of the duration of an attendance record for an employee on a fully flexible working schedule. Previously, we were using the adjusted start and end times, which were adjusted from their original values to be the outer bounds of the interval made up of the original times and the UTC-converted times. This resulted in a duration that was too long. Now, we use the original start and end times to calculate the duration of the attendance because this value is timezone-agnostic. Forward-Port-Of: odoo/odoo#214918 Forward-Port-Of: odoo/odoo#213700
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 -
Original PR description
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open…
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 - Third line with a price of 0.020 and a qty of 3 - Create a new request for quotation for this product with this vendor - set a quantity of 3 **Current behavior:** The unit price is 0.022 **Expected behavior:** It should be 0.020 **Cause of the issue:** When sorting the set of product.supplierinfo, rounding should not be applied because the rounding will be the one of the currency and the Product Price could allow more decimal than the currency. If we allow vendors price to be more precise the the currency, the sorting should take into account this precision when choosing a vendor. opw-4823919 Forward-Port-Of: odoo/odoo#213826
Forward-Port-Of: odoo/odoo#213890
Original PR description
Forward-Port-Of: odoo/odoo#213890
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior be
Original PR description
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to…
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior before PR: - When selling to other EU countries, a 19% sales tax is added to goods and services. - When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services. Desired behavior after PR is merged: - When selling to other EU countries, a 0% sales tax is added to goods and services. - When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216082 Forward-Port-Of: odoo/odoo#211746
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an mrp.production order and clicking on "Set as done". Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg. At the end of
Original PR description
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an…
Description of the issue/feature this PR addresses:
I'm not sure how to reproduce right now. Clue: these modules are installed:
- sale_stock_margin
- stock_account
Other clue: user is going to an mrp.production order and clicking on "Set as done".
Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg.
At the end of the rabbit hole, the code ends up here, where there's a pretty obvious bug: a singleton value being extracted from a multi-record variable.
So, yes, this is probably the worse fix description ever. 😅 However, the bug is so obvious that I'm not sure I really need something more elaborate in this case. So, here's the fix! 🎁
@moduon MT-7556
Current behavior before PR:
<details>
```
Traceback (most recent call last):
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 15, in _call_kw
raise ValueError
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5182, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1651, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/opt/odoo/custom/src/odoo/odoo/service/[model.py](https://model.py/)", line 133, in retrying
result = func()
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1678, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1882, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/[ir_http.py](https://ir_http.py/)", line 154, in _dispatch
result = endpoint(**request.params)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 734, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 46, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 19, in _call_kw
return super()._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 469, in call_kw
model.env.flush_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 745, in flush_all
self._recompute_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 741, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 6282, in _recompute_field
field.recompute(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1370, in recompute
apply_except_missing(self.compute_value, recs)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1343, in apply_except_missing
func(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1392, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 4240, in _compute_field_value
fields.determine(field.compute, self)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/sale_stock_margin/models/[sale_order_line.py](https://sale_order_line.py/)", line 18, in _compute_purchase_price
purch_price = product._compute_average_price(0, line.product_uom_qty, line.move_ids)
File "/opt/odoo/auto/addons/mrp_account/models/[product.py](https://product.py/)", line 54, in _compute_average_price
return super()._compute_average_price(qty_invoiced, qty_to_invoice, stock_moves, is_returned=is_returned)
File "/opt/odoo/auto/addons/stock_account/models/[product.py](https://product.py/)", line 788, in _compute_average_price
qty_valued, valuation = candidates._consume_specific_qty(qty_invoiced, qty_to_invoice)
File "/opt/odoo/auto/addons/stock_account/models/[stock_valuation_layer.py](https://stock_valuation_layer.py/)", line 113, in _consume_specific_qty
rounding = self.product_id.uom_id.rounding
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1154, in __get__
record.ensure_one()
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5185, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: uom.uom(1, 12)
```
</details>
Desired behavior after PR is merged: Fixed!
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183402The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happe
Original PR description
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was…
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happened because `s_progress_bar_text` was forgotten during the initial implementation of `s_numbers_charts` [1]. This commit addresses these problems by: - Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template. - Including `s_progress_bar_text` in `_computeSnippetTemplates` to ensure that existing databases also receive this fix, as snippets are stored in the database. - Adding a check in the `progress` option to prevent the aforementioned crash. Steps to reproduce the crash: - Drop the `s_numbers_charts` snippet. - Click on a progress bar within the snippet. - Select the option `Label`. - Hover over "Hide" without any other prior interactions. - A crash will occur. [1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd Forward-Port-Of: odoo/odoo#215946 Forward-Port-Of: odoo/odoo#214318
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
Original PR description
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_
Original PR description
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has…
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_id set The POL has the qty set to the min_qty of the invalid supplierInfo and the vendor code of that supplier info is not displayed. And if you further remove the invalid supplier info from the product page, the vendor code will be read and the POL qty will be the min_qty of the valid supplier info. This is because on creating a POL, two functions are got called, the first one is `_suggest_quantity` which suggests the initial quantity to set on the POL when the PO is created. This one is based on the minimum min_qty of all the supplierInfos related to the same product we are purchasing regardless if they are completely valid or not. Hence it chose the invalid supplierInfo min_qty. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/purchase/models/purchase.py#L1386C9-L1388C45 After the qty of the POL is set based on the `_suggest_quantity`, the `_compute_price_unit_and_date_planned_and_name` is called because it depends on the product_qty which calls the `_select_seller` function on the product. The `_select_seller` filters all the supplierInfo keeping only the valid ones BASED on the qty we are asking (so it eliminated the one with the smallest min_qty because the date_end is < PO.date and also the second one because the min_qty of the second_supplierInfo is > qty we are asking) ending up with empty list of supplierInfo to apply on our POL. Then the POL is set to the standard price and no vendor code is attached and read into it. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L616-L617 https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L603-L612 opw-4640937 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#216126 Forward-Port-Of: odoo/odoo#205915
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://g
Original PR description
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within…
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L18 During recursion in `_compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call. Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L77 Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders. Root Cause: The stock_moves passed into the method have env.company set to Company 1. At https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L66 bom_lines are extracted, inheriting the environment from stock_moves. As a result, _compute_average_price is executed within the context of Company 1, which may lead to incorrect computations when the intended company context is different. Fix: Ensure that stock_moves is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution, preventing unintended company switching. opw-4222976 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#216326 Forward-Port-Of: odoo/odoo#192890
take default_employee_id from the employee_id not from active_id task-4885649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215177
Original PR description
take default_employee_id from the employee_id not from active_id task-4885649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215177
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts
Original PR description
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts - Select your order and pay for it - The points are awarded once again depending on how much was left to pay **Why the fix:** The points should just be awarded once when the order is confirmed, even if it has not been paid for yet. We now ignore the line if it's about a settled order, as those points have already been awarded. opw-4770142 Forward-Port-Of: odoo/odoo#215690 Forward-Port-Of: odoo/odoo#214137
Steps to reproduce the bug: - Create two purchase orders and add a note - Try to merge them Problem: A traceback is triggered: ``` ValueError: AttributeError("'int' object has no attribute 'total_seconds'") while evaluating 'if records:\n action = records.action_merge()' ``` opw-4890120 Forward-Port-Of: odoo/odoo#216080 Forward-Port-Of: odoo/odoo#215958
Original PR description
Steps to reproduce the bug:
- Create two purchase orders and add a note
- Try to merge them
Problem:
A traceback is triggered:
```
ValueError: AttributeError("'int' object has no attribute
'total_seconds'") while evaluating 'if records:\n
action = records.action_merge()'
```
opw-4890120
Forward-Port-Of: odoo/odoo#216080
Forward-Port-Of: odoo/odoo#215958Have a cron action written like the following: def cron_complex(...): # prepare items_to_do = collections.deque(...) while self._commit_progress(remaining=len(items_to_do)): item_to_do = items_to_do.pop() try: process(item_to_do) self._commit_progress(1) except: pass This case is similar to what ir.autovacuum is doing: it doesn't always mark an item done, but instead de
Original PR description
Have a cron action written like the following: def cron_complex(...): # prepare items_to_do = collections.deque(...) while self._commit_progress(remaining=len(items_to_do)): item_to_do =…
Have a cron action written like the following:
def cron_complex(...):
# prepare
items_to_do = collections.deque(...)
while self._commit_progress(remaining=len(items_to_do)):
item_to_do = items_to_do.pop()
try:
process(item_to_do)
self._commit_progress(1)
except:
pass
This case is similar to what ir.autovacuum is doing: it doesn't always
mark an item done, but instead decrease the remaining counter.
The problem with this code is the `while` conditional.
The first call to `_commit_progress` is gonna be `done=0`. In case the
function `return 0` (no remaining time) then the `while` is gonna break
and the function will return immediately. The ir.cron would then be in
the condition `not progress.done` which for this case should be
understood as PARTIALLY DONE (there are remaining items to process) but
instead is understood as FULLY DONE.
This scenario is the direct consequence of commit https://github.com/odoo-dev/odoo/commit/f135c06cfde62256348f5e0791a49fa019d1f15c: always run
at least 10 seconds AND at least 10 times. The action runs for 10
seconds the first time, but is called a second time in which it returns
immediately, with progress done=0, remaining>0.
Forward-Port-Of: odoo/odoo#215918Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it,
Original PR description
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it, the form will be hidden by default then shown based on attributes such as data-visibility-selectors. But on the root tag, we only allow to modify only a very restricted list of tags, so we saved the hiding of the form, but didn't save the attributes that made it visibile based on a condition. Fix: add the attributes used for visibility in the authorized list on the root tag. opw-4765026 Forward-Port-Of: odoo/odoo#215479
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting pla
Original PR description
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting plain text inside code blocks preserves indentation using normal spaces, avoiding insertion of `nbsp`. task-4815939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215252 Forward-Port-Of: odoo/odoo#211386
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read t
Original PR description
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213807
Followup to https://github.com/odoo/odoo/commit/fdcb584b20af1f99cf760eaff94e489a77e6c36d When the `_onClickUpdateQuantity` was updated to use a view instead of a wizard that opens in a new window, it was not checked that the HTML help when no records found is correctly rendered. This fixes that by ensuring it's correctly parsed, i.e. copied same solution as here: https://github.com/odoo/odoo/commit/f9f7d9d6a8470f3ca5ff464bb425b219ac4ed571 Steps to reproduce: - open any product > click
Original PR description
Followup to https://github.com/odoo/odoo/commit/fdcb584b20af1f99cf760eaff94e489a77e6c36d When the `_onClickUpdateQuantity` was updated to use a view instead of a wizard that opens in a new window, it was not checked that the HTML help when no records found is correctly rendered. This fixes that by ensuring it's correctly parsed, i.e. copied same solution as here: https://github.com/odoo/odoo/commit/f9f7d9d6a8470f3ca5ff464bb425b219ac4ed571 Steps to reproduce: - open any product > click on forecast report button - click on "Update Quantity" - apply a filter so that no records are found (e.g. only "Transit Locations" Expected result: normal no records found icon + help Actual result: raw html Additionally cleaned up some of the junk code that was left by the original commit.... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208896
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== r
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062 Forward-Port-Of: odoo/enterprise#87919 Forward-Port-Of: odoo/enterprise#87301
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The
Original PR description
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The Ticket should continue to include a reference to the originating Lead (existing behaviour). - The Lead should also display a chatter message referencing the newly created Ticket. Forward-Port-Of: odoo/enterprise#87463
Show the Do Not Disturb state text on the voip header Task-4891947 Forward-Port-Of: odoo/enterprise#88362
Original PR description
Show the Do Not Disturb state text on the voip header Task-4891947 Forward-Port-Of: odoo/enterprise#88362
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88061
Original PR description
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88061
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are
Original PR description
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking. runbot-115003 Forward-Port-Of: odoo/enterprise#88316 Forward-Port-Of: odoo/enterprise#81643
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Change: Skip access rights of `hr.contract` when refusing an applicant. Reasoning: If you have the right to refuse an applicant, you should be able to refuse an applicant and retrospectively, **sudo** refuse the associated offer(s). Task-4868368 Forward-Port-Of: odoo/enterprise#87730
Original PR description
Change: Skip access rights of `hr.contract` when refusing an applicant. Reasoning: If you have the right to refuse an applicant, you should be able to refuse an applicant and retrospectively, **sudo** refuse the associated offer(s). Task-4868368 Forward-Port-Of: odoo/enterprise#87730
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
Original PR description
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Original PR description
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Before, aml.ref had to be at least 5char length to be a full match candidate. But it seems 5 is not enough and leads to unwanted matches, so let's increase the limit to 7. no-task Forward-Port-Of: odoo/enterprise#88554
Original PR description
Before, aml.ref had to be at least 5char length to be a full match candidate. But it seems 5 is not enough and leads to unwanted matches, so let's increase the limit to 7. no-task Forward-Port-Of: odoo/enterprise#88554
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Reproduce: 1. Select a document so that its token is now part of the URL 2. Refresh the page 3. The document is not selected as it should This is problematic because if you are given a link to access a document in a folder with any siblings, you have no way to know which one the link pointed to. Technically, since 18.3, records are no longer found in `onMounted`. Note that due to another (older, independent, and less critical) bug, non-previewable records are not focused. Task-4
Original PR description
Reproduce: 1. Select a document so that its token is now part of the URL 2. Refresh the page 3. The document is not selected as it should This is problematic because if you are given a link to access a document in a folder with any siblings, you have no way to know which one the link pointed to. Technically, since 18.3, records are no longer found in `onMounted`. Note that due to another (older, independent, and less critical) bug, non-previewable records are not focused. Task-4873715 Forward-Port-Of: odoo/enterprise#88555
Currently, an error occurs when the system initializes the voip configuration for the currently logged-in internal user. Steps to Reproduce: - Install the `voip` module. - Delete the activity type where the `Action` is `'Phonecall'`, and then refresh the page. `IndexError: tuple index out of range.` This error occurs when the system initializes the voip configuration and no phonecall activity type exists. The system attempts to search for activity types with the 'phonecall' catego
Original PR description
Currently, an error occurs when the system initializes the voip configuration for the currently logged-in internal user. Steps to Reproduce: - Install the `voip` module. - Delete the activity type where the `Action` is `'Phonecall'`, and then refresh the page. `IndexError: tuple index out of range.` This error occurs when the system initializes the voip configuration and no phonecall activity type exists. The system attempts to search for activity types with the 'phonecall' category, which returns an empty recordset. Then it tries to access the first record of this empty recordset[1], which raises an error. [1] https://github.com/odoo/enterprise/blob/2896974e9eda61bfe5e1d67423dc56f6ab17b2af/voip/models/res_users.py#L128 This commit ensures that if activity type with the 'phonecall' category is present, it store the activity type id, otherwise, it stores False as the activity type id. sentry-6689050392 Forward-Port-Of: odoo/enterprise#87958
19 changes
New functionality added to Odoo
VoIP users can now open CRM leads linked to a contact directly from the softphone. This helps sales teams move from a call to the related opportunity information faster, using the same experience already available for recruitment applicants.
Original PR description
This commit adds a button that connects the contacts to its leads via the VoIP module. It uses the same logic as "Applicant" button introduced before. Task-4855484 Community: https://github.com/odoo/odoo/pull/214031
Enhancements to existing features
Australian payroll rule parameters have been updated for the 2025 period. This helps ensure payroll calculations use the latest required values, supporting accurate payslips and compliance for Australian employees.
Original PR description
Forward-Port-Of: odoo/enterprise#88323
Resolved issues and error corrections
The Kenyan eTIMS integration now checks whether an invoice that timed out was already received before trying again. This helps avoid duplicate submissions to the government and restores confirmation details such as QR codes when the original submission succeeded.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
A new automated check confirms that date-based rentals count the full rental period correctly, such as January 1 to January 2 being treated as two days. This helps prevent future changes from accidentally causing incorrect rental durations and pricing behavior on eCommerce rental flows.
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88671 Forward-Port-Of: odoo/enterprise#88264
The accounting reconciliation process now safely stops when there are no bank statement lines to process. This prevents users from seeing an error when running reconciliation models with no available transactions.
Original PR description
SQL syntax error occurs when trying to auto reconcile transactions via reconcile models,it is because there are no statement lines to reconcile. **Steps to reproduce:** * Install `accountant` module (No demo data needed) * Accounting Dashboard> Bank dropdown menu * Under reconciliation>Models>Internal Transfers>Run Now `syntax error at or near ')' LINE 57: WHERE st_line.id IN ()` **Solution:** * Return the function if there are no statement to reconcile. **Sentry-6610155279**
Printed payslips now display title-style salary rule lines with the correct formatting. This makes generated payroll documents clearer and more professional for employees and HR teams.
Original PR description
### Steps to reproduce: - Generate and print a payslip after marking a salary rule line as a title. ### Fix: - Added conditional styles and classes to fix the issue. task-4780481
This fix prevents an error from appearing when staff mark a point-of-sale preparation order as done shortly after it arrives while using debug mode. It adds a safety check so the display no longer tries to use order information that has already been removed.
Original PR description
Steps to reproduce: - Open a preparation display in debug mode - Make an order that will appear on the preparation display - Click on the done button before 5 seconds - Traceback will appear 5 seconds after the order was received Issue: When receiving an order useDelayedValueChange is called in the setup of the Orderline component. This method will try to access the props after a timeout. When the preparation orders are deleted in debug mode, the states are deleted from the front end. Since the props of orderline are the preparation state linked to it a traceback arises. Fix: A check is added to check if the state record exists.
Fixed an issue where Chilean point-of-sale invoice settlements always showed an amount of $1 instead of the actual outstanding balance. This ensures staff can settle customer invoices accurately in POS and avoid undercharging or manual corrections.
Original PR description
**Problem:** When trying to settle an order in POS with a Chilean company, the amount to be settle will be 1$, regardless of how much needed to be settled. **Steps to reproduce:** - Set the company to a Chilean company. - Make an invoice for a Chilean customer and confirm it. - Go to pos, and click settle invoices for your client, chose the invoice you just made. - The amount will be 1$ **Why the fix:** The field *pos_amount_unsettled* was not loaded into the invoice if the company is from Chile. It resulted in it being undefined, thus it was set to 1 afterwards. We now load this variable into the invoice when loading the data. opw-4856764
Removing a parent emission source from an ESG emission source no longer triggers an error. This keeps emission source management reliable and prevents disruption when users update ESG reporting structures.
Original PR description
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new…
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new emission source with a parent emission source. - Remove the parent emission source. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=3>,).activity_flow_direct_indirect` This error occurs when the parent emission source is removed, causing the scope to become False in _compute_scope[1]. Subsequently, in _compute_activity_flow[2], none of the cases match, which results in a failure to assign the activity flow and raises an error. [1] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L75 [2] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L77-L78 This commit ensures that if the parent emission source is removed, the activity flow is properly maintained. sentry-6690968543
HR users can now update employee leave requests even while they are waiting for approval, provided the leave has not already been included in payroll. This helps HR correct or adjust leave records before payslip processing without unnecessary blockers.
Original PR description
- Allowing HR people to always edit the leave, as long as it's not included in a payslip. task-4866887
This update keeps the automated checks for Mexican electronic invoicing in Point of Sale aligned with a recent underlying system change. It helps ensure invoice-related POS workflows continue to be tested correctly without affecting day-to-day users.
Original PR description
In this commit, I’ve updated the test in invoice_order_tour to align with the new signature of the selectOrder function introduced in the PR referenced below. Odoo PR: https://github.com/odoo/odoo/pull/212434
Miscellaneous changes
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: -
Original PR description
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: - Use the correct default account codes directly (101403, 101404) - Avoid reassignment of codes that are now created by the CoA template task-4826385 Forward-Port-Of: odoo/enterprise#88745 Forward-Port-Of: odoo/enterprise#88068
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it : 1) Use a Belgian company and an employee with a contract; 2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example); 3) Try to create a payslip for this employee. Error : File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half work_data[('half', work_entry.work_entry_type_id.id)] +=
Original PR description
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it :
1) Use a Belgian company and an employee with a contract;
2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example);
3) Try to create a payslip for this employee.
Error :
File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half
work_data[('half', work_entry.work_entry_type_id.id)] += dt.days * 24 + dt.seconds / 3600 # Number of hours
TypeError: 'float' object is not iterable
[opw-4752109](www.odoo.com/odoo/project/49/tasks/4752109)
Forward-Port-Of: odoo/enterprise#87895
Forward-Port-Of: odoo/enterprise#84810Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The
Original PR description
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The Ticket should continue to include a reference to the originating Lead (existing behaviour). - The Lead should also display a chatter message referencing the newly created Ticket. Forward-Port-Of: odoo/enterprise#87463
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime". The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]` I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forwar
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88730With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Original PR description
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
9 changes
New functionality added to Odoo
Adds support for the new Belgian Blackbox v2 requirements in Odoo Point of Sale. This helps Belgian businesses stay compliant with fiscal regulations while continuing to use POS workflows such as employee access and loyalty features.
Resolved issues and error corrections
This fixes how employee online status lists are combined in Time Off, replacing behavior that only worked accidentally. It reduces the risk of incorrect availability checks when showing or using employee presence information.
Original PR description
PR above made a typo in code in which list of "online" member IM status is a list of string, and it uses + to concatenate items like in python but this doesn't work in JS. Thankfully it kinda "worked" because this casted the array into list (e.g. `["a", "b"]` becomes "a,b") and other items were appended to string. Since this list was used for `.includes()` by chance the ".includes()" method is on Array and String and functionally this results to about the same intention... Again by chance! Forward-Port-Of: odoo/odoo#216598
This fixes Spanish SII reporting so credit notes identify OSS taxes using the correct refund tax information instead of invoice tax information. It helps ensure refunds are reported accurately and reduces the risk of incorrect tax data being sent.
Original PR description
Before this commit, the method _has_oss_taxes was determining whether a tax is OSS based on the tax_ids.invoice_repartition_line_ids.tag_ids This works fine for invoices, but for credit notes it should be based on tax_ids.refund_repartition_line_ids.tag_ids This commit solves this issue followup of: https://github.com/odoo/odoo/pull/215614 task-4548095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216603 Forward-Port-Of: odoo/odoo#216543
The mail message composer now keeps a consistent height when empty in Chromium-based browsers. This prevents the input box from visibly resizing as users begin typing, making messaging feel smoother and more polished.
Original PR description
Before this commit, composer height was too small when it had no content. This lead to composer changing height when typing some characters which looks off. This bug is specific to Chromium browsers and seems to be new since Chrome 138.0. The code expected that textarea had unchanged scrollheight when textarea has height 0 and fits its content in at most 1 line, but this seems to have changed with Chrome 138.0. This commit fixes the issue by cheating when composer is empty: the fake textarea artificially adds a character so that the computation for height when empty works as if it has 1 character, thus the computed height is the same when there are few characters in composer.
New Argentine companies will now start with the more commonly used Responsable Inscripto chart of accounts instead of the less common Monotributista option. This reduces incorrect default accounting setup for most Argentine businesses and aligns automatic setup with typical usage.
Original PR description
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in Argentina we have different CoA depending on the AFIP Responsibility, and the one that is currently installed by default is the 'ar_base' (Responsable Monotributista): the less used one. In this case we prefer to do not install any CoA and let the user to install it manually (as it was working in older versions, but it is not possible). For that reason we made this change force to install 'ar_ri' (Responsable Inscripto) CoA by default instead ### Current behavior before PR: 1. Create a new company with country AR 2. Will automatically install the "Responsable Monotributista" Coa ### Desired behavior after PR is merged: Now will install the "Responsable Inscripto" Coa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue on invoice forms where an empty section could leave an odd line and extra spacing beside invoice amounts. The invoice screen now hides that whole section when it is not relevant, making the layout cleaner for draft invoices or invoices without outstanding items.
Original PR description
Repro steps: Navigate to the form view of an invoice that is either 1. not posted 2. does not have outstanding debits/credits Problem spotted: next to the invoice amounts, a weird line and margin to the right can be seen Cause: The field invoice_outstanding_credits_debits_widget of an invoice may be invisible with this condition invisible="state != 'posted' or not invoice_has_outstanding" and in that case, it's containing group would still be visible (showing the aforementioned margin). Fix: This commit fixes this issue by moving the invisible condition to the group containing the field invoice_outstanding_credits_debits_widget instead of the condition being on the field itself. task-4882509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts recent shortcut naming in the web testing library that could cause some databases to show a blank screen with a browser error. It helps restore normal loading while the underlying asset generation issue is investigated separately.
Original PR description
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown,…
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown, here are the main cuplrits: [this first commit](<https://github.com/odoo/odoo/pull/213223/commits/d4c7e7abbde31806a49d4cdba340cd238eb9130b>) and [this second commit](<https://github.com/odoo/odoo/pull/213223/commits/f7426b366431ebc6266113700eeb3821e9e6a884>). The first commit adds support for '$' characters in JS variable names, while the second takes advantage of that feature to declare short-hand aliases for the Hoot-DOM library. The issue is caused because the aliases from the second commit seem to have been applied to the static assets (and it also seems that they have been correctly transpiled by the server), but for some reason the transpiler still doesn't support '$' characters and ignores the added export statements. Database server code has been verified as having the correct version of the transpiler code, but the resulting static assets still present this issue. **What can be done?** This PR should fix the issue, as it effectively reverts changes on the second commit. The first commit has not been reverted (yet), as the cause of the issue is still unknown, and the damage need to be mitigated as quickly as possible. A temporary fix while the revert arrives in stable is to head to the crashing DB in `debug=assets` mode, to head to the debug menu (Bug icon) and to `"Regenerate Assets"`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated website payment donation test so it handles the payment confirmation redirect reliably. It helps keep donation-related website checks stable and reduces false test failures during quality assurance.
Original PR description
In this commit, we fix the donation_snippet_use tour. At the end of the tour, when you click on submit donation, you are redirected to a page "Your payment has been processed." From this page, you are then redirected to a page with "Thank you". This intermediate redirection page can be a problem if there are several steps that concern it because we do not know when the redirection will be triggered (in the first or the second step?) Therefore, it is essential to have only one step for intermediate redirections. 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
Error dialogs in debug mode no longer show an unrelated internal request ID as if it were a record ID. This avoids misleading information when users or support teams review crash details for server actions.
Original PR description
Steps: - Enable debug mode - Go to server actions - Create a server action that crashes with `Execute code` - Example -> "a" (will crash because `a` is undefined) - Traceback will contains an invalid ID `Occured on odoo180 on model ir.actions.server and id 19 on 2025-06-30 09:20:48 GMT` This was an error and this ID is not linked with the model, it is the rpc id, so it should not be on the traceback. This commit remove this id to have something like this `Occured on odoo180 on model ir.actions.server on 2025-06-30 09:20:48 GMT` opw-4816514