Thursday, May 15, 2025
44 changes · 18.0
Enhancements to existing features
The bank reconciliation model form now shows whether each listed tax is for sales or purchases alongside the tax name. This makes it easier for accounting users to choose and review the right tax when configuring counterpart items.
Original PR description
Before this commit: - In the bank reconciliation model form view, under the "Counterpart Items" section, the "Taxes" column displayed only the tax name. - Taxes were not distinguished between Sales and Purchase types, making it difficult to identify their type. After this commit: - The "Taxes" column now displays the tax type beside the tax name, making it easier to distinguish between them. task-4752604
UAE invoice reports now show each line amount in the company currency when the invoice uses a different currency. This helps businesses meet FTA requirements to express payable amounts in AED and respects the company's tax display setting.
Original PR description
Description of the issue/feature this PR addresses: Task ID: 4636082 Current Behavior before PR: - When printing an invoice with a currency that is different than the company's currency. The amount value of each line is only printed in the invoice's currency and not the company's currency. - As per the FTA article 59, the line amount should also be expressed in AED. - The tax excluded amount was also always printed regardless of the company's setting. (something that was fixed in https://www.odoo.com/odoo/project.task/4625855?debug=1 but there seems to be no intention to backport this to 18.0). Desired behavior after PR is merged: - Add a new column to print the line amount in the company's currency if the invoice has a different currency than the company. - Print tax excluded/include amount based on company's setting. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixes an issue that prevented users from adding payment methods back to credit card journal settings after the default method was removed. Credit card journals now show available payment methods consistently with bank journals, helping users configure incoming and outgoing payments without getting stuck.
Original PR description
Description of the issue/feature this PR addresses: This PR addresses an issue where, in the credit card journal configuration form (for either Incoming Payments or Outgoing Payments), users are…
Description of the issue/feature this PR addresses: This PR addresses an issue where, in the credit card journal configuration form (for either Incoming Payments or Outgoing Payments), users are unable to add a new payment method. Steps to reproduce the error: 1. Open the credit card journal configuration form. 2. In either Incoming Payments or Outgoing Payments, delete the default manual payment method. 3. Attempt to add either the deleted payment method or a new one. Video: https://drive.google.com/file/d/1CnghnPyfn90xIv5TZiU8PVyMatX7rGt3/view Current behavior before PR: The list view of Incoming/Outgoing payments displays a 'no record' label, and users are unable to add either the deleted payment method or a new one. Desired behavior after PR is merged: The credit card journal configuration should display all available payment methods, similar to how the bank journal behaves, allowing users to add new payment methods. I've created a related ticket here: https://www.odoo.com/es_ES/my/tasks/4501396 Thanks in advance! :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Better phrasing, better compatilibity of the colors. Removal of tracking. task-4782004 Forward-Port-Of: odoo/odoo#210049
Original PR description
Better phrasing, better compatilibity of the colors. Removal of tracking. task-4782004 Forward-Port-Of: odoo/odoo#210049
This fix prevents Odoo from automatically recreating accounting setup items such as accounts, taxes, and fiscal positions during localization upgrades. It helps businesses keep their existing accounting configurations intact and avoids unwanted duplicate or unexpected records after upgrading.
Original PR description
- Updated UK localization template handling to avoid automatic recreation of accounts, taxes, and fiscal positions when upgrading. - Added `force_create = "0"` parameter to `try_loading` to ensure that existing configurations are retained and no new records are created unless explicitly required. - Fixed a similar issue for all impacted localizations, following the discussion in the previous task (https://www.odoo.com/odoo/project/967/tasks/4556250). task-4712602 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies an internal note about the disabled website theme preview before selection. It helps teams avoid confusion around a known disabled feature and its related automated test, with no expected impact on day-to-day users.
Original PR description
The theme preview feature before selection was disabled in [1]. This commit precises the TODO comment that was added with it. It comes alongside a theme repo commit which actually disables the related nightly test of the feature... that was red since then. [1]: https://github.com/odoo/odoo/commit/7cb71e9479df0ee9af0b7ad39302857666726177 Related to task-3454790
The product configurator test tours now select the intended products more precisely when demo data is present. This reduces random test failures and helps keep validation of sales product configuration stable.
Original PR description
When the test DB includes all demo data, sometimes the corrected tours took the wrong products This commit makes the selection of products in test tours more precise, just as it is the case for some other selectors. runbot-error-161984 runbot-error-108034 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue where full-height cover sections could jitter while visitors scrolled on mobile browsers. Website pages with large hero or cover blocks should now feel smoother and more polished, especially on phones where the browser address bar changes size while scrolling.
Original PR description
Scenario:
- add a cover snippet with 100% height at the top of the page
- open the page on a mobile (eg. safari on iOS)
- scroll down the page
Result: there is a vertical jittering of the content of cover snippet
when going down.
Cause: we are setting the size in pixel to {viewport height} - {height
of stuff (menu, logged in user bar, ...)} but the mobile browser changes
the viewport height when going down and hiding the address bar UI, so
the fixed pixel height is only updated when the code is called again
instead of being adapted smoothly.
Fix: set the height of the cover using 100dvh minus the size of the
content, so the height is increased/decreased smoothly by the
application of CSS.
opw-4575726This fix prevents accounting mappings from being updated when no new taxes or accounts are being created. It helps avoid unintended changes during chart template upgrades or setup operations, keeping accounting configuration more stable.
Original PR description
Since we only update the fiscal positions for newly created taxes, there is nothing to update in the mapping when nothing will be created. upg-2769042
The Customer Lot Report now includes delivered serial numbers even when the delivery record was linked indirectly through stock movements. This improves report completeness for customer deliveries, including dropshipping cases, so businesses see a more accurate product history per partner.
Original PR description
The Customer Lot Report displays all SN delivered to a partner. To do so, the SQL query is mainly based on SML. The problem is that it only considers SML linked to a picking through the field `picking_id`. However, this field is not required and it is possible to have an SML without any value for that field, still linked to a picking through its SM (RPC, data import...) This commit therefore add a `join` on the SM, so we can find the picking in all cases. Moreover, [1] has been merged to get the customer of a dropshipping (tldr: the partner of a dropship is the supplier). However, now that we have the SM of the SML, we can simplify a lot the code and rather use the partner of the SM: https://github.com/odoo/odoo/blob/24235855d01e52df314479e0437c0308864edc23/addons/stock/models/stock_move.py#L95-L99 [1] https://github.com/odoo/odoo/commit/bace02e0355f3ed657421ca452af0b17ef4886bc OPW-4559129
Event registration confirmation emails are now translated into the language set for the related contact. This ensures attendees receive clearer, localized communication when they are booked for an event.
Original PR description
Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click…
Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click on New - In the 'Booked by' field, select the partner with the foreign langage - Save Current Behavior: A registration email is created but the body of the email is not translated to the language of the partner Expected Behavior: The body of the registration email should be translated in the language of the partner Cause of the issue: In order for the translation to happen inside _render_field() the variable 'equality' has to be True Link 1: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L180 Because field is equal to 'body' the value of equality is the value of self.body_has_template_value Link 2:https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L168 self.body_has_template_value is computed by checking if the 'body' attribute of self (self is an instance of mail.compose.message) is either equal to self.template_id.body_html or tools.html_sanitize(self.template_id.body_html) Link3: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L70 In this case, self.body has been computed using html_sanitize(self.template_id_html) Link4: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/odoo/fields.py#L2231 so self.body_has_template_value shoud be True The reason it's False is that when computing the value of self.body (Link4) the method html_sanitize is used with an argument (**sanitize_vals) which is not the case when comparing self.body to html_sanitize(self.template_id.body_html) (Link3) As a result self.body and html_sanitize(self.template_id.body_html) are not equal which makes self.body_has_template_value be False which makes equality be equal to False which makes the translation not happening Fix : Inside _compute_body_has_template_value() I made the method also return True if self.body is equal to html_sanitize(self.template_id.body_html,**sanitize_vals) with santize_vals having the same value as when self.body is computed opw-4349122
The product form now shows the Purchase checkbox when Accounting is installed, even if the Purchase app is not installed. This restores the ability to mark whether a product can be purchased, while keeping the Purchase tab visible only when the Purchase app is installed and the option is enabled.
Original PR description
After 18.0, the Product form has changed and the Purchase taxes field was moved on the main tab. By doing so, we removed the "Purchase" checkbox (as the tab would have been empty), but by doing so we lost the ability to tell that a product can be purchased or not. Now when account is installed we make the checkbox visible on the Product form even without the Purchase app, the tab will then only be visible if both the Purchase app is installed and the checkbox is ticked. task- 4742975
Credit card journals now show the normal payment method options when users add incoming or outgoing payment lines. This prevents users from getting stuck if the default manual payment line is removed and keeps credit card journal setup consistent with bank and cash journals.
Original PR description
**Steps to reproduce:** - Install account - Go to "Invoicing / Configuration / Accounting / Journals" - Create a "Credit Card" type journal - In "Incoming Payments" tab (or "Outgoing Payments"), try to add a line **Issue:** There is no option for "Payment Method" select field. If the default "Manual Payment" line is removed, it's not possible to add it again. **Cause:** The list of available payment methods for credit card journal is empty. The method that is computing the available payment methods is always returning False for credit card journals, but it should not. **Solution:** Compute the available payment methods normally as it is the case for bank and cash journals. opw-4754110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue that could show an error when a user lost and restored network connection during login. The system now handles the missing notification value safely, improving reliability in unstable network conditions.
Original PR description
Currently an error occurs when the user reconnects after a network interruption during login process. Steps to replicate: - Open an incognito tab browser and open the login page. - Input credentials,…
Currently an error occurs when the user reconnects after a network interruption during login process. Steps to replicate: - Open an incognito tab browser and open the login page. - Input credentials, and during the login process go to offline. - Again, go online, and after a few times, an error will occur. Note:- If an error does not occur, close the window and open a new one, try offline and online again. Error: `BusController.has_missed_notifications() missing 1 required positional argument: 'last_notification_id'` This error occur because at code line [1] the `lastNotificationId` is still undefined (due to the network interruption). This results in the client calling `/bus/has_missed_notifications` with an invalid or missing parameter, causing the controller to raise a `TypeError` due to a missing required argument. This commit will fix above issue by providing a default value for `last_notification_id` as 0, so that the field is always present before making the RPC call to `/bus/has_missed_notifications`. [1]-https://github.com/odoo/odoo/blob/18.0/addons/bus/static/src/outdated_page_watcher_service.js#L55 Video for error replication: https://github.com/user-attachments/assets/3facbc96-b864-442b-8db8-73508eaf5e9e sentry-5741581459 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail test suite was adjusted to avoid failures caused by smooth scrolling behavior. This helps keep automated checks stable so future updates can be validated with fewer false failures.
Original PR description
Tests were failing because of smooth scrolling. runbot-103421
This fix prevents an error that could occur when the system checked for missed notifications after a disconnection, but had no prior notification data to compare against. Users benefit from a smoother experience because the application avoids making an invalid check in that edge case.
Original PR description
When no notification was received before bus disconnection, the `has_missed_notifications` route is missing a parameter, leading to an error. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves Odoo's internal browser test framework and related test mocks so automated checks behave more like real user interactions. It helps reduce false test results and improves confidence when validating changes across apps such as Discuss, CRM, Recruitment, Website editing, Lunch, and Dashboards.
Original PR description
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
A small typo in the website HTML editor's history handling was corrected. This restores the intended condition check, helping prevent incorrect undo/redo behavior in edge cases.
Original PR description
There was a typo in the history plugin, making an `if` statement useless. This fixes the typo. Backport of https://github.com/odoo/odoo/pull/186917/commits/0269326853abd35e988359e776632b47febf2e60.
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discoun
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discounts & free products, this isn't an issue, as claiming them will use as many points as possible, meaning there's no points left to claim more, but free shipping can only be claimed once per order. Solution -------- Filter out rewards that have already been claimed. opw-4784359 Forward-Port-Of: odoo/odoo#209739 Forward-Port-Of: odoo/odoo#209508
The selectionchange event is triggered in the next microtask tick. Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969. Forward-Port-Of: odoo/odoo#209907 Forward-Port-Of: odoo/odoo#209844
Original PR description
The selectionchange event is triggered in the next microtask tick. Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969. Forward-Port-Of: odoo/odoo#209907 Forward-Port-Of: odoo/odoo#209844
Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported. Steps to reproduce: - open CRM - switch to the graph view - Check the "cumulative" checkbox - Group by create date: month - Filter on March and April (the last 2 months in the filter) - insert in spreadsheet - reload => the chart data changed. It now includes historical data Task-4792009 Description of the issue/feature this PR addresses: Current behavior before PR: Desired be
Original PR description
Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported. Steps to reproduce: - open CRM - switch to the graph view - Check the "cumulative" checkbox - Group by create date: month - Filter on March and April (the last 2 months in the filter) - insert in spreadsheet - reload => the chart data changed. It now includes historical data Task-4792009 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#209857 Forward-Port-Of: odoo/odoo#209637
before this commit, in the profitability dashboard the cogs section is show with label cost_of_goods_sold  after this commit, the label will be shown as Cost of Goods Sold  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo
Original PR description
before this commit, in the profitability dashboard the cogs section is show with label cost_of_goods_sold  after this commit, the label will be shown as Cost of Goods Sold  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209868
Description of the issue/feature this PR addresses: Adding 2 new accounts that addresses newly enacted law for cash payment rounding. [Legal doc (only in Lithuanian)](https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/5d1b9590e33711ef8cdff2c320e69444?jfwid=m8xvfl87c) approving chart of account with the new added accounts. [Legal doc](https://www.e-tar.lt/portal/lt/legalAct/9926c840f1be11ee9f5b8ffa077f9188) approving the cash rounding itself. As a bonus I added translations for the new accounts
Original PR description
Description of the issue/feature this PR addresses: Adding 2 new accounts that addresses newly enacted law for cash payment rounding. [Legal doc (only in Lithuanian)](https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/5d1b9590e33711ef8cdff2c320e69444?jfwid=m8xvfl87c) approving chart of account with the new added accounts. [Legal doc](https://www.e-tar.lt/portal/lt/legalAct/9926c840f1be11ee9f5b8ffa077f9188) approving the cash rounding itself. As a bonus I added translations for the new accounts, but unsure if I should have done that, let me know if I should remove them. [MORE INFO ABOUT IT ALL](https://www.lb.lt/en/rounding-of-cash-payments) Current behavior before PR: No `5009` and `6319` accounts Desired behavior after PR is merged: Accounts `5009` and `6319` present --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209096 Forward-Port-Of: odoo/odoo#208306
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
Original PR description
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
Scenario: in mobile, edit the link of the category back button Result: the link is changed, but it is overriden by t-att-href so will not be taken into account. Fix: add o_not_editable on parent to prevent editing this part, this prevent to change style but there is no simple way to prevent editing only the link and there is no information that there is a "t-att-href". opw-4725198 Forward-Port-Of: odoo/odoo#209500
Original PR description
Scenario: in mobile, edit the link of the category back button Result: the link is changed, but it is overriden by t-att-href so will not be taken into account. Fix: add o_not_editable on parent to prevent editing this part, this prevent to change style but there is no simple way to prevent editing only the link and there is no information that there is a "t-att-href". opw-4725198 Forward-Port-Of: odoo/odoo#209500