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.
This fix prevents a WhatsApp message queue from failing when a WhatsApp administrator without Marketing Automation access sends a message. It keeps other queued WhatsApp messages moving instead of leaving an entire batch blocked indefinitely.
Original PR description
When the `marketing_automation_whatsapp` module is installed, if a user **without** the "Marketing Automation / User" group but **with** the "WhatsApp / Administrator" group sends a WhatsApp message, the "WhatsApp: Send In Queue Messages" cron may crash with an access error. This happens because the system tries to access marketing traces with the user that sent the message. However, marketing traces are restricted to Marketing Automation users. As a result, all WhatsApp messages in the same batch are blocked indefinitely, even those that could otherwise be sent successfully. opw-4678339
Subscriptions made entirely of postpaid items now set their next invoice date one billing period later instead of immediately. This prevents premature invoicing and keeps billing aligned with delivered products or services.
Original PR description
…line are postpaid
This fix lets Mexican electronic invoices use the invoice date as the CFDI date when appropriate, matching what users expect to see on the PDF. It also keeps the sending timestamp stable across retries, reducing the risk of duplicate invoices after connection issues or timeouts.
Original PR description
This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the…
This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used. However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice. To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice. However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future). #### The fix-of-fix (this PR) To solve both those issues, here is what we do: - now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change). - if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too. task-none
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