Thursday, May 15, 2025
34 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
Resolved issues and error corrections
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
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
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 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 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
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.
This fix ensures documents keep the correct company information when they are moved. It helps avoid cross-company organization issues in multi-company setups, so users see and manage documents under the right company.
Original PR description
Forgotten in c632b843 / task 4491333. Task-4703626
Helpdesk now checks for existing customers whose email matches even when they are not assigned to a specific company. This helps avoid creating duplicate customer records when tickets are generated from incoming emails.
Original PR description
Before this commit, the #84245 adds an extra_domain to find the customer to assign on the ticket based on the email address received. The problem is the partners could also have no company set and so the method could not find the existing partner with the email given and will create a duplicate partner because of that. This commit adds inside the extra_domain to also search on partner without any company set to be sure to not create duplicate the partner.
This update adjusts automated tests across several Odoo apps so they better match current interface behavior and data expectations. It helps reduce false test failures and supports smoother maintenance without changing day-to-day user workflows.
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
Fixes an issue where copying an account report correctly update the formulas of the report but not the subformulas. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209742 Forward-Port-Of: odoo/odoo#208071
Original PR description
Fixes an issue where copying an account report correctly update the formulas of the report but not the subformulas. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209742 Forward-Port-Of: odoo/odoo#208071
During the rendering of email marketing templates, links will be automatically shortened to aliases, which also enable tracking on the links' activity. However, since some links are generated by Odoo, these are protected (blacklisted) from being shortened during the email generation process. Since that blacklist is keyword-based, some external pages are also affected by this (notably Google Docs' forms, whose URL contains "/viewform", matching keyword /view. Steps to reproduce: - Creat
Original PR description
During the rendering of email marketing templates, links will be automatically shortened to aliases, which also enable tracking on the links' activity. However, since some links are generated by Odoo, these are protected (blacklisted) from being shortened during the email generation process. Since that blacklist is keyword-based, some external pages are also affected by this (notably Google Docs' forms, whose URL contains "/viewform", matching keyword /view. Steps to reproduce: - Create a new mass mailing - Add a link to a Google Docs form, and a link to a Wikipedia page - Send the mass mailing - On the received email: The link to Wikipedia is shortened, the Google Docs form link is not To reduce the number of false positives, this commit makes it so that blacklist elements need to be followed by a path symbol ( / # ? or link termination) to be counted as positives. task-4196321 Forward-Port-Of: odoo/odoo#201060 Forward-Port-Of: odoo/odoo#190819
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment, several accounts created by default don't match the CoA pattern: - 999000001 Cash Difference Gain - 999000002 Cash Difference Loss. - 999300000 Cash Discount Loss - 999400000 Cash Discount Gain - 999999 Undistributed Profits/Losses ## Fix Given correct codes to the existing accou
Original PR description
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment,…
## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment, several accounts created by default don't match the CoA pattern: - 999000001 Cash Difference Gain - 999000002 Cash Difference Loss. - 999300000 Cash Discount Loss - 999400000 Cash Discount Gain - 999999 Undistributed Profits/Losses ## Fix Given correct codes to the existing accounts and modifying data for some records:. | Account | New code | New name | New Account type | |-------------------------------------|-----------|------------------------------------------------------------------------------|------------------| | 999000001 Cash Difference Gain | 403.01.01 | Other Income | ~ | | 999000002 Cash Difference Loss | 601.84.02 | ~ | ~ | | 999300000 Cash Discount Loss | 402.01.01 | Returns, discounts or bonuses over sales and/or services at the general rate | other income | | 999400000 Cash Discount Gain | 503.01.01 | Returns, discounts or bonuses over purchases | ~ | | 999999 Undistributed Profits/Losses | 305.01.01 | Uncut Result | ~ | --- opw-4288080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203714 Forward-Port-Of: odoo/odoo#196852
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (
Original PR description
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (at least as a result of `stopLoading`) while we're waiting for service workers to shut down as well as pending responses. If this is still an issue, we may want to add a separate flag and set it right before or after the `Page.stopLoading` call. Hides runbot errors 54858, 55676, 109214, 109473, 110840, 134469, 162284, 162340, 193182, 198562, and 199232 Forward-Port-Of: odoo/odoo#209902
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the C
Original PR description
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209819
Description of the issue/feature this PR addresses: IOT crashes parsing a response from https://www.odoo.com/odoo-enterprise/iot/x509 not containing 'data' Current behavior before PR: Crash Desired behavior after PR is merged: - Related internal PR: https://github.com/odoo/internal/pull/3480 opw-4711613 Forward-Port-Of: odoo/odoo#205444 Forward-Port-Of: odoo/odoo#205168
Original PR description
Description of the issue/feature this PR addresses: IOT crashes parsing a response from https://www.odoo.com/odoo-enterprise/iot/x509 not containing 'data' Current behavior before PR: Crash Desired behavior after PR is merged: - Related internal PR: https://github.com/odoo/internal/pull/3480 opw-4711613 Forward-Port-Of: odoo/odoo#205444 Forward-Port-Of: odoo/odoo#205168
**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item.
Original PR description
**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item. opw-4479406 Forward-Port-Of: odoo/enterprise#77422
Forward-Port-Of: odoo/enterprise#82304 Forward-Port-Of: odoo/enterprise#77188
Original PR description
Forward-Port-Of: odoo/enterprise#82304 Forward-Port-Of: odoo/enterprise#77188
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product. - Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved - Click on the wheel icon > Split production > Split in 2 - On the MO-001, SN1 is reserved - Open
Original PR description
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as…
### Steps to reproduce:
- Install both mrp and quality_control
- Create 2 products:
- FP (Final Product)
- COMP (Component) tracked by SN > pu SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.
### Cause of the issue:
Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.
### Fix:
Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.
opw-4656240
Forward-Port-Of: odoo/enterprise#84796
Forward-Port-Of: odoo/enterprise#84606Issue: ---------- A user with Sale Manager access is unable to confirm a recurring service type sale order. Root Cause: -------- The Sale Manager lacks write access to task and recurrence records, which are updated during order confirmation. Fix: ------- Used sudo() when updating the recurrence to bypass access restrictions, allowing the Sale Manager to confirm the sale order successfully. Steps to Reproduce: ------------- - Install the project_sale_subscription module
Original PR description
Issue: ---------- A user with Sale Manager access is unable to confirm a recurring service type sale order. Root Cause: -------- The Sale Manager lacks write access to task and recurrence records, which are updated during order confirmation. Fix: ------- Used sudo() when updating the recurrence to bypass access restrictions, allowing the Sale Manager to confirm the sale order successfully. Steps to Reproduce: ------------- - Install the project_sale_subscription module. - Create a user with Sale Manager access only. - Log in as that user and create a subscription-based sale order. - Add a recurring service product to the order line. Forward-Port-Of: odoo/enterprise#85489
#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852. Forward-Port-Of: odoo/enterprise#82318 Forward-Port-Of: odoo/enterprise#81270
Original PR description
#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852. Forward-Port-Of: odoo/enterprise#82318 Forward-Port-Of: odoo/enterprise#81270
When user quickly presses the ``Enter`` key multiple times to record a timesheet, A traceback will appear. Steps to reproduce the error: - Go to Timesheets > My Timesheets - Now, Quickly press the ``Enter`` key multiple times to record a timesheet Traceback: ``` ValueError: Expected singleton: timer.timer(1, 2) File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer timesheet.action_timer_start() File "home/odoo/
Original PR description
When user quickly presses the ``Enter`` key multiple times to record a timesheet, A traceback will appear. Steps to reproduce the error: - Go to Timesheets > My Timesheets - Now, Quickly press the…
When user quickly presses the ``Enter`` key multiple times to record a timesheet,
A traceback will appear.
Steps to reproduce the error:
- Go to Timesheets > My Timesheets
- Now, Quickly press the ``Enter`` key multiple times to record a timesheet
Traceback:
```
ValueError: Expected singleton: timer.timer(1, 2)
File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer
timesheet.action_timer_start()
File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 460, in action_timer_start
super().action_timer_start()
File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 86, in action_timer_start
self._stop_timer_in_progress()
File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 140, in _stop_timer_in_progress
model = self.env[timer.res_model].browse(timer.res_id)
File "odoo/fields.py", line 1228, in __get__
record.ensure_one()
File "odoo/models.py", line 6196, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/enterprise/blob/58348c5f9276e5cb4397f0f73d23b41f5a454868/timer/models/timer_mixin.py#L128-L131 When a user quickly presses the ``Enter`` key,
``timer`` will have multiple records,
So, It will lead to the above traceback.
sentry-6557099219
Forward-Port-Of: odoo/enterprise#73984- In the check report, the amount in numbers are now moved leftward so that it is closer to the beginning of the line 4720121 Forward-Port-Of: odoo/enterprise#85342
Original PR description
- In the check report, the amount in numbers are now moved leftward so that it is closer to the beginning of the line 4720121 Forward-Port-Of: odoo/enterprise#85342