Tuesday, March 12, 2024
28 changes · 17.0
Enhancements to existing features
This update consolidates repeated code from multiple payment terminal drivers into a shared parent class, making the system easier to maintain and update. All payment terminals now benefit from improved features like smarter sleep management and better handling of simultaneous requests, ensuring more reliable payment processing across all supported devices.
Original PR description
Currently, we have some code repeating in SixDriver, WorldlineDriver_L and WOrldlineDriver_W. The goal of this PR is to move this code to a parent class for easier maintenance and better code strcture Additionally, it applies the code to every ctypes dependant terminal driver, adding some features like "smart sleep" or rejecting double request processing when the terminal is busy for every single of them task-3707945 Forward-Port-Of: odoo/enterprise#57064
The report editor now displays meaningful error information when reports fail to load in debug mode, allowing administrators to see what went wrong and access the problematic views for troubleshooting. This improvement helps with report recovery and migration processes by providing visibility into issues that were previously hidden from users.
Original PR description
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in case we are in debug mode. The display of the error allows to open the incriminating views in a dialog, and see some basic information on them, as well as, obviously, the error message and type. opw-3735973 [1]: 62c167f87176674cbabad976d93eeb717f73df7a
Resolved issues and error corrections
Archived employee contracts will no longer appear in the contract menu, improving data organization and reducing clutter. Previously, archived contracts remained visible even though they were no longer active, which could cause confusion when managing current employment agreements.
Original PR description
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
The Sales report was incorrectly displaying inflated totals for subscription products when upsells were created. This fix removes upsell information from the Sales report to prevent duplicate counting, ensuring accurate revenue figures. Users will now see correct untaxed totals in the Sales report for subscription products.
Original PR description
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on the original subscription. As a result, the information is duplicated. Solution: --------- Do not include upsells in the sales report. Note: ----- With the fix, the value is 200 and not 170, because it is not possible to take upsell discounts into account in the sales report (we have to use the subscriptions report). opw-3646388 Forward-Port-Of: odoo/enterprise#58271 Forward-Port-Of: odoo/enterprise#57568
This update fixes an issue where switching to right-to-left (RTL) language mode would incorrectly reverse the email format display. Previously, emails would show as "domain@alias" instead of the correct "alias@domain" format. The fix ensures email addresses display correctly regardless of language direction, improving the user experience for RTL language users.
Original PR description
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
Forward-Port-Of: odoo/enterprise#58263
Forward-Port-Of: odoo/enterprise#58251This update fixes an issue where the accounting system failed to properly match invoice amounts during reconciliation when no partner was specified. The problem was caused by floating-point precision errors in currency calculations (e.g., -208.73 not matching 208.730000000000002). The fix uses a more reliable database query method to ensure accurate amount matching, improving the reliability of automated reconciliation processes.
Original PR description
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
A bug in the Belgian tax report validation was causing correct tax reports to be incorrectly flagged as invalid. This fix corrects the validation logic so that accurate tax reports are properly recognized and accepted by the system.
Original PR description
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at the bottom: `[44] < ([00] + [01] + [02] + [03] + [45] + [46] + [47] + [48] + [49]) * 200 if [88] > 99.999` opw-3767675 Note: confirmed by TSB on the ticket Forward-Port-Of: odoo/enterprise#58343
Fixed an issue where SMS template content was not appearing when sending messages from the Contacts form. The template body is now properly computed and displayed when users select an SMS template to send a message. This ensures users can see the full message content before sending.
Original PR description
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template…
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template (this will allow you to use this template from the contact form view). - Go to Contacts, select any, click on the gear icon and send an SMS using your new SMS template. Issue : the Body of the SMS template is not displayed. Cause of the issue: - The send SMS action generates an `sms.composer wizzard` that triggers a call of the `onchange` method to compute the values of the form view of the record from scratch. The body of the message is computed during the snapshot1 of the onchange of the `sms.composer` https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L1076 by the `_compute_body` method: https://github.com/odoo/odoo/blob/72c1a4f96a1219d98ce9b90ee54fd7297b9ab999/addons/sms/wizard/sms_composer.py#L167 To be processed correctly, this computation requires a `template_id` (field of the sms.composer model). This `template_id` information is present in the `self._context` of the onchange as a 'default_template_id'. However, since the template_id is not present in the form view of the sms.composer, it is not part of the `fields_spec` arguments of the onchange and this `default` value is not converted into a value before the snapshot1 at this step: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 Prior to Odoo 17.0, this was not a problem as the value was still used from the context the snapshot1. However, this value is now cleaned form the context during the snapshot1: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/api.py#L567 https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/tools/misc.py#L1010-L1014 As a result, there is no template_id during the call of the `_compute_body` and the body of the message stays empty. Fix: - In order to compute the body, correctly, we add the template_id as an invisible field of the `sms.composer` form view so that it becomes part of the `fields_spec` arguments of the onchange so that its default value 'default_template_id' is converted into a real value: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 that will be used as an argument of the snapshot1. opw-3733881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where searchbar text became invisible when using dark color themes. The text color now automatically adjusts based on the searchbar background color to ensure proper contrast and readability. This improves the user experience when customizing website themes.
Original PR description
Steps to reproduce the bug: - Open the homepage and enter edit mode. - Click on the "Theme" tab. - Select the 4th color from the theme options and choose "black". - Drag and drop a "Search" snippet onto the page. - Save the page to exit edit mode. - Enter text in the searchbar input. - Bug: The text is not visible because its color is the same as the background color of the input. This bug appeared since this commit [1] where the "bg-light" class was added to the searchbar input. This caused the text color of the input, which by default is the same as the body color, to become invisible when the background color of the body is dark. To fix this, we now adjust the text color of the input based on the background color of the input. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3751401
This fix resolves an issue where user-defined filters would become invalid and cause errors after their parent action was deleted. Previously, filters were not automatically removed when actions were deleted, leading to broken references. Now, all associated filters are properly cleaned up when an action is removed.
Original PR description
When deleting records from ir.action.action, the user-defined filters(ir.filters) will not be deleted automatically, thus causing an error. Steps to reproduce: - Create a User-defined Filter under any action - Remove that action - Go to User-defined Filter again -> There will be an error message pop out that says action record does not exist Cause The User-defined Filters will not be automatically removed when the parent action gets deleted Solution Remove all the User-defined Filters when deleting the parent action
This fix resolves an issue in the mass mailing editor where text color would revert to black when changing font size. Previously, a default black color was being applied to text elements, overriding user-selected colors. Now, custom text colors are properly preserved when users adjust font sizes, providing a better editing experience.
Original PR description
**Current behavior before PR:** When we apply a text color and change its font size, the text color defaults to black. This occurs because the default black color is applied to a span within `o_basic_theme.o_layout`. **Desired behavior after PR is merged:** Now, when applying text color and adjusting its font size, the color of the text remains unchanged. task-3770351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155715
This update fixes a bug in the email composer feature where different users could see inconsistent data when composing messages. The fix ensures that computed fields display the correct information regardless of which user is accessing the system, improving reliability and preventing confusion when multiple team members use the email composer simultaneously.
Original PR description
Avoid accessing inconsistent data based on the user
This fix resolves an issue where email addresses were displaying incorrectly when using right-to-left (RTL) language modes. Previously, the domain picker would reverse the email format from the correct "alias@domain" to "domain@alias". After this fix, emails now display in the correct format regardless of the language direction setting.
Original PR description
**Description of the issue/feature this PR addresses:** This PR resolves an issue where the domain picker was being unintentionally reverted in RTL mode, leading to a disruption in the email format. **Current behavior before PR:** Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. **Desired behavior after PR is merged:** Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task link: https://www.odoo.com/web#model=project.task&id=3624012 Task-3624012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156892 Forward-Port-Of: odoo/odoo#154834
Fixed a bug in the recruitment module where phone numbers were not being transferred when creating employees from signed job applications. Now when an employee is created, their phone number is automatically copied to their employee record, or their mobile number is used if the phone number is not available. This ensures complete contact information is preserved during the hiring process.
Original PR description
When an employee is created from a signed application, the phone number or the mobile number was not copied to the employee private information. Now, the phone number is copied and if not present, the mobile number is copied. Task: 3659409 Forward-Port-Of: odoo/odoo#156538 Forward-Port-Of: odoo/odoo#152888
This fix resolves an issue where setting a past end date on a leave allocation would prevent the system from properly calculating the number of days when other allocation details are updated. Now the day calculation will correctly update whenever the start date, end date, or accrual plan is changed, regardless of whether the end date is in the past or future.
Original PR description
Description of the issue/feature this PR addresses:
Create an allocation for an accrual plan in the past will prevent number_of_days computation
- Create an accrual plan to give 1 day per month
- Create an allocation with this plan
- Update date_from and/or accrual_plan_id
- number_of_days is updated
- Set date_to in the past (1)
- Update date_from and/or accrual_plan_id (1)
- Set date_to in the future (1)
- Update date_from and/or accrual plan
- number_of_days is updated
Current behavior before PR:
- (1) number_of_days is not updated
- number_of_days is computed from date_from to now
Desired behavior after PR is merged:
- number_of_days updated on date_from/accrual_plan_id/date_to change
opw-3764865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an image caching problem that occurred when displaying images from related records (like partner or user photos) in kanban and activity views. Previously, the system used an incorrect cache key that wasn't tied to the specific record being displayed, causing images to display incorrectly. This update ensures images are cached properly based on their source record.
Original PR description
The way we cache the image is not right when that image is not on the current record. For instance displaying a partner/user image. The unique key used is not related to that record. Introduced by https://github.com/odoo/odoo/pull/97544 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#157004
This update fixes two problems in how Odoo sorts records. First, it prevents unnecessary loss of cached data when sorting is performed. Second, it ensures that newly created records are not accidentally excluded from sorting operations. These fixes improve the reliability and performance of record sorting throughout the system.
Original PR description
BaseModel's sorted() has two problems: - It breaks the prefetch of self for no reason - When it is called without an argument, it filters out new records because the search() used in sorted() doesn't return new records. Keep the same prefetch as self to fix the first problem. We partially fix/support the second issue, we just avoid filtering out new records (but we don't actually sort them) Forward-Port-Of: odoo/odoo#157033 Forward-Port-Of: odoo/odoo#156729
This fix resolves an error that occurred when users deleted a company in Odoo. When a company was removed, the system would crash with an error message when trying to access the onboarding feature. The fix ensures that onboarding progress records are automatically cleaned up when their associated company is deleted, preventing the error and allowing users to continue working normally.
Original PR description
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open…
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open Accounting 7. You receive an error: > ValueError: Expected singleton: onboarding.progress(1, 2) ### Explanation: In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all. https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69 This is due to the fact that some onboardings are not related to a company while others are. After that, getting the `onboarding_state` will trigger an `ensure_one` check. In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it. ### Suggested fix: `ondelete` decorator would require the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade. opw-3762382 Forward-Port-Of: odoo/odoo#155407
This fix resolves an issue where invoices were appearing twice in the invoice analysis pivot view when a product had different costs set across multiple companies. The system was incorrectly counting the same invoice multiple times due to how product cost properties were stored per company. Now invoices are properly filtered to show only once, regardless of multi-company product cost configurations.
Original PR description
Steps to reproduce: - have two companies; Company A and Company B - create a product Product A and set a different cost in each company - create an invoice for Company A with Product A and post it - Go in invocie analysis > pivot view and set the y-axis as 'move' Issue: The invoice will be taken twice Issue: for Product A, there are two ir_property lines (one per cost/company) opw-3753395
This fix resolves an issue where a second invoice created from the same sales order was incorrectly marked as paid. The system was mistakenly using old payment transactions from the first invoice to determine payment status. Now the system correctly checks each invoice's actual payment status instead of relying on transaction history, ensuring customers can properly pay additional invoices.
Original PR description
Steps to reproduce the issue - set up the test provider - order something from the website and pay - create an invoice for the SO (invoice is paid) and confirm it - add an extra item to initial SO - create a second invoice - check the invoice on the portal ==> second invoice is automatically marked as paid because of the transactions on the SO The transactions that were used on the SO are filled in on the new invoice in the transaction_ids field. In the view in the portal the method 'get_portal_last_transaction' is called which finds the transaction for the older invoice and assumes its paid. We will now rely on the payment status of the invoice instead of the state of the last transaction. opw-3594556 Forward-Port-Of: odoo/odoo#156403 Forward-Port-Of: odoo/odoo#155045
This fix resolves an issue where payment methods would incorrectly remain from a previously selected journal when switching between journals. When creating a payment and switching from one journal to another and back, the payment method would not update properly. The fix ensures the journal ID is only computed during initial payment creation, not during subsequent field changes.
Original PR description
The goal of the `def new` override on `account.payment` is to have the `journal_id` computed when creating a payment in the form view. The problem is that it is also called by the onchange when a field is modified. This is causing a bug: - Go the the cash journal and change the name of its payment methods (so you can distinct them from the ones of the bank journal). - create a payment (do not save) - switch the journal to "Cash" then switch back to "Bank". -> the "Payment Method" is still one from the "Cash" journal. The fix is here is a hacky way of checking this is the call on the record creation. Forward-Port-Of: odoo/odoo#156832 Forward-Port-Of: odoo/odoo#155710
This fix ensures that when a live chat operator takes over from a chatbot, the operator's name and visitor information are properly displayed in the channel name. Previously, all channels were labeled only as "Chatbot," making it difficult for managers to identify and review individual chat sessions. This improvement helps live chat managers better organize and track conversations.
Original PR description
Description of the issue/feature this PR addresses: - Create a website - Create a chatbot with forward to operator --> Issue all mail.channel have 'Chatbot' in name field  @tde-banana-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156123 Forward-Port-Of: odoo/odoo#152223
Users assigned to specific websites can now successfully log in using the API (RPC). Previously, the system couldn't verify the correct website when logging in through the API, causing login failures even when using the correct domain. This fix enables the system to properly identify the website during API logins, allowing restricted users to authenticate successfully.
Original PR description
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if…
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if [`get_current_website`][2] returns the same website as `website_id`. The issue is that when login with RPC, `dispatch_rpc` is making a [`borrow_request`][3] which hides the `request` object from the RPC layer. This has the consequence that `get_current_website` is not able to retrieve the website based on the url of the request. Thus preventing a user to login via RPC even if the domain used corresponds to the website set in its `website_id` field. __Description of the fix:__ Add the possibility to retrieve the current website via `threading.current_thread().url` (which is set [here][4]). This way it is possible to know the current website even if `borrow_request` has been used. opw-3742591 [1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/addons/base/models/res_users.py#L779 [2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944 [3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361 [4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037 Forward-Port-Of: odoo/odoo#157309 Forward-Port-Of: odoo/odoo#154447
Non-administrator users were unable to access the Journal Items page in Accounting due to a permission restriction on a system view. This fix removes the unnecessary access barrier, allowing users without admin rights to view journal items as intended. This improves usability for accounting team members who don't have full system administration privileges.
Original PR description
Steps to reproduce: - Install Accounting - Connect with a user without "Administration: Settings" rights (e.g. Marc Demo) - Go to "Accounting / Accounting / Journals / Journal Items" Issue: An Access Error is raised when trying to access a "ir.ui.view" record that is restricted to "Administration/Settings" group. opw-3787114 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 corrects how product prices are displayed in the shopping cart when your store is configured to show prices with taxes included. Previously, cart prices were calculated differently than product page prices, causing incorrect amounts to be shown to customers. The fix ensures consistent price calculations across both the product page and shopping cart.
Original PR description
To reproduce: ============= - In the Settings: Product prices displayed on the website set as "Tax Included". - Created a test product (for example price 100$ tax 15%). - Created a price list with fixed price 15$ for all products - Pricelist configured as "Selectable" and set to "Show public price & discount to the customer". - on the product shop page, the price is 17.25$ instead of 115$ (which is the correct). - add product to cart and check the cart price, it's 17.25$ instead of 100$. Problem: ======== on the shop page the prices is calculated through combination. But in the cart, it's retrived directly from `sale.order.line`. Solution: ========= do same calculation in the cart as in the shop page through combination. opw-3771242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component to version 17.0.14 with multiple bug fixes and performance enhancements. Users will experience improved responsiveness when working with spreadsheets, fixes for data validation checkboxes, corrected automatic sum calculations, and better autofill functionality. These changes ensure the spreadsheet feature works more reliably across different browsers and scenarios.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6f6e1b9dd [REL] 17.0.14 https://github.com/odoo/o-spreadsheet/commit/540c525ed [FIX] header_positions: perfs of update…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6f6e1b9dd [REL] 17.0.14 https://github.com/odoo/o-spreadsheet/commit/540c525ed [FIX] header_positions: perfs of update style Task: 3797400 https://github.com/odoo/o-spreadsheet/commit/fdafd66c0 [FIX] automatic_sum: wrong behaviour with spreaded values Task: 3782971 https://github.com/odoo/o-spreadsheet/commit/8ac8ce53b [FIX] DataValidationCheckbox: Fix input positioning in FF Task: 3774645 https://github.com/odoo/o-spreadsheet/commit/4769c9ed4 [FIX] GridComposer: Reset the cell reference visibility on stop edition Task: 3736211 https://github.com/odoo/o-spreadsheet/commit/cd9bcee12 [FIX] data validation: checkbox not disabled in readonly Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/cb53fc249 [IMP] data validation: performance of icons Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/035f42e00 [PERF] evaluation: apply compute function Task: 3775636 https://github.com/odoo/o-spreadsheet/commit/70c51deb6 [FIX] autofill: allow to autofill a mix of number values and formulas Task: 3700733
This fix ensures that when creating a new journal with restricted mode enabled, the secure sequence ID is properly generated immediately. Previously, the sequence was only created when the journal was edited, which could cause issues if certain modules weren't installed. This resolves an inconsistency in how journals are initialized.
Original PR description
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a…
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a write() on the record. Even changing it's name on edit triggers the creation of the sequence. On runbot is correctly created because account_check_printing triggers a write() after the create of the account.journal. But this module is not a dependency from account (or any of it's dependencies) and if it is uninstalled, this behaviour occurs. **Current behavior before PR:** When creating an account.journal with restrict_mode_hash_table set to True we should generate the secure_sequence_id but it's not happing. It is only contemplated on the write() **Desired behavior after PR is merged:** When creating an account.journal with restrict_mode_hash_table set to True we generate the secure_sequence_id. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157134 Forward-Port-Of: odoo/odoo#155188
This update removes an unnecessary step when loading sale orders in the Point of Sale system that was causing the system to retrieve excessive customer data from the database. By eliminating this redundant process, the system will run faster and more efficiently, especially when dealing with large numbers of customers.
Original PR description
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return…
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return every single `res.partner` record because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785 This can cause SQL to overwork especially when computing the 'total_due' field. After doing so, we check if the partner has been loaded and we grab the id using `get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to load them. Since we are already checking and reloading the partner on the sale order using `_loadPartners`, using `load_new_partners()` earlier is redundant. Solution --> Remove the try-catch block that loads multiple `res.partner` records during the process of clicking on a sale order via POS. opw-3619941 Forward-Port-Of: odoo/odoo#157171 Forward-Port-Of: odoo/odoo#156836