Daily updates from Odoo
Friday, November 8, 2024
48 changes · 18.0
Enhancements to existing features
User lookup by display name has been adjusted to avoid a slow database search pattern on very large user lists. This restores the previous behavior and can reduce searches from many seconds to milliseconds, improving responsiveness in user-related screens and operations.
Original PR description
After removal of _name_search(), the res.users `_search_display_name()` has been rewritten to use an `OR` to match either exactly the login or part of the name; this make the query very inefficient as it prevent PostgreSQL to use the index an any of the two fields.
This commit re-introduce the previous behavior: we first check for an exact users match on the login or (if none) we fallback to standard display name search (for `name`).
With a database will multiple millions of users:
Before:
```
In [1]: %time env["res.users"].search([('display_name', 'ilike', 'OdooBot')])
CPU times: user 2.03 ms, sys: 8 µs, total: 2.04 ms
Wall time: 16.8 s
```
After:
```
In [1]: %time env["res.users"].search([('display_name', 'ilike', 'OdooBot')])
CPU times: user 1.21 ms, sys: 1.87 ms, total: 3.08 ms
Wall time: 6.69 ms
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe wording shown when an administrator is asked for a password while editing another user's account has been clarified. This reduces confusion during sensitive account management actions and helps admins understand why the prompt appears.
Original PR description
Sometimes admins are asked the password when they modify the account of someone else. The wording shown is a bit confusing. This commit makes the wording more clear. Task-4295458
The time off settings now show a clearer warning when a negative balance limit is set incorrectly. This reduces confusion for users by replacing contradictory wording with a more understandable message.
Original PR description
Before this commit, the error message that the user receives once triggering the constraint on negative balances values was: "The negative amount must be greater than 0." which was a bit confusing by having side to side "negative" and "greater than 0" This commit rephrases that error message.
Resolved issues and error corrections
This fix corrects misleading location labels and help text shown when configuring stock and repair operation types. It makes the wording more consistent and avoids confusion for users working with repairs, inventory transfers, or manufacturing flows.
Original PR description
Followup to task: 4028900 Fixes the following issues: - The label of "Default Component Destination Location" was applied to all operation types, not just `repair_operation`. This resulted in…
Followup to task: 4028900 Fixes the following issues: - The label of "Default Component Destination Location" was applied to all operation types, not just `repair_operation`. This resulted in confusing labeling for all the other operation types when Repair was installed - The "help" of `default_location_src_id` and `default_location_dest_id` referred to stock pickings, but these fields are also used for MRP and Repair. So the help has been updated to be more generic to avoid confusion - Task: 4034713 removed the "Default" from the label of the default location fields for picking types, therefore we remove them from the repair ones for consistency - cleaned up the inheritance of the picking type form view in repair so that the `default_location_src_id` field isn't in the same view twice (or have inconsistent attributes) - reordered the Repair default locations to follow a more logic ordering --- 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 a newer version with fixes for pivot tables, formulas, chart display, and Excel export. Users should see more reliable spreadsheet calculations and clearer chart behavior, especially around errors, empty references, pie charts, and translated chart labels.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/5fa5fbb4a [REL] 18.0.3 Task: 0 https://github.com/odoo/o-spreadsheet/commit/09860796e [FIX] pivot: skip cells on…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/5fa5fbb4a [REL] 18.0.3 Task: 0 https://github.com/odoo/o-spreadsheet/commit/09860796e [FIX] pivot: skip cells on manipulated pivot array formulas Task: 4292134 https://github.com/odoo/o-spreadsheet/commit/03d7080d3 [FIX] functions: FILTER with strings and errors Task: 4307604 https://github.com/odoo/o-spreadsheet/commit/eb4c13091 [FIX] charts: do not show zero values in pie charts Task: 4277144 https://github.com/odoo/o-spreadsheet/commit/3eac11e86 [FIX] index: export chart translation terms Task: 3978443 https://github.com/odoo/o-spreadsheet/commit/262b1bc2a [FIX] tests: remove WAIT funtion Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/70f58fa2d [FIX] tests: bad separator in xlsx export Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/ec41486b9 [FIX] tests: remove async function export test Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/c78551c57 [FIX] xlsx: convert #REF at export to xlsx Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/bebac5f29 [FIX] parser: inconsistent handling of #REF Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/c53e76933 [FIX] charts: correct stacked checkbox label Task: 4251670 https://github.com/odoo/o-spreadsheet/commit/5ebba297c [REM] charts: clean createLineOrScatterChartRuntime Task: 0 https://github.com/odoo/o-spreadsheet/commit/d3a2181b7 [FIX] charts: fix trend line for datetime Task: 0 https://github.com/odoo/o-spreadsheet/commit/69a8602cd [FIX] chart: missing checkbox label for combo chart Task: 4283173 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes an error that could stop invoice PDFs from being generated in the Argentina and Chile localization modules. Users can now print affected invoices without the system failing due to an internal naming mismatch.
Original PR description
The function `_exclude_tax_group_from_tax_totals_summary` does not exist. It should be `_exclude_tax_groups_from_tax_totals_summary` instead. This is the same issue for the l10n_cl and l10n_ar module…
The function `_exclude_tax_group_from_tax_totals_summary` does not exist. It should be `_exclude_tax_groups_from_tax_totals_summary` instead.
This is the same issue for the l10n_cl and l10n_ar module since it's just a call to a non-existent function.
### Steps to reproduce:
- Install the l10n_ar module
- Create an invoice with the document type set to "Invoice C"
- Add a line that includes a tax
- Try to print using the "PDF without payment" button
### Traceback:
```
File "/Users/louis/Development/odoo_src/core/odoo/odoo/addons/base/models/ir_qweb.py", line 600, in _render
result = ''.join(rendering)
^^^^^^^^^^^^^^^^^^
File "<778>", line 107, in template_778
File "<778>", line 89, in template_778_content
File "<778>", line 77, in template_778_t_call_0
File "<1056>", line 2228, in template_1056
odoo.addons.base.models.ir_qweb.QWebException: Error while rendering the template AttributeError: 'account.tax' object has no attribute '_exclude_tax_group_from_tax_totals_summary' Template: l10n_ar.report_invoice_document
Path: /t/t/div[2]/div/div[4]/div[1]/div[1]/div/table/t[1]/t[2]
Node: <t t-set="currency" t-value="o.currency_id"/>
```
opw-4253265The loyalty card point update wizard now automatically shows the card's existing point balance. This helps users adjust loyalty points with the correct starting value and reduces the chance of manual errors.
Original PR description
Issue: -The old balance field in loyalty card point update wizard is not set by default Fix: -Added `card_id` in form view
This update improves automated checks for website shop features so they run faster and fail less often. It fixes several test flow issues around product search, autocomplete, gift cards, loyalty, and delivery, helping maintain stability without changing customer-facing behavior.
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
This update fixes a typo in the Expenses app. It is a minor cleanup that improves text clarity without changing business workflows or functionality.
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
This change fixes the setup of an automated Mail discussion walkthrough so it starts after other functional tours and opens at the correct place. This helps ensure the tour reliably shows the expected in-app guidance during testing and validation.
Original PR description
In this commit, we fix the sequence and the url of discuss_channel_tour tour with the aim to start in last position after all the functional and with the aim to see the baball on the app. task~4309858 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 fixes an automated test so it works correctly when only the Community edition is installed. It helps keep quality checks reliable and avoids false failures during validation, with no expected impact on users.
Original PR description
Fixes a test to work without enterprise installed. Runbot Error 105489
This fixes how import batch size limits are passed to the file handling component. It ensures the configured size is understood correctly, helping imports respect the intended limits and avoid incorrect batching behavior.
Original PR description
This commit fixes the parameters send to the BinaryFileManager. There was a typo `maxBatchSize` and not `maxSizePerBatch` also has the unit on the web interface is in mega we should multiply the unit by 1024 ^ 2 to have the correct value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated Studio walkthrough so it properly handles the export confirmation window. The change helps keep quality checks reliable without changing how business users work in Studio.
Original PR description
At the end of the tour, when we want to export all modifications, it opens a modal from v18.0. But, as it is not allowed to do action on element that's below a modal, the tour fails. In this commit, we click on export button to test the export feature and then close the modal before continuing the tour.
This update improves how ISO 20022 payment files are generated, especially for SEPA and Swiss payments. It prevents incorrect SEPA labels on non-SEPA payments, removes unnecessary transfer wording, and restores important batch payment validation so payment issues are caught earlier.
Original PR description
[FIX] account_iso20022: Don't report 'SEPA' as Service Level in ISO20022 files 'SEPA' used to be the default for SvcLvl files, which meant even non-SEPA files would have it set to 'SEPA', unless they…
[FIX] account_iso20022: Don't report 'SEPA' as Service Level in ISO20022 files 'SEPA' used to be the default for SvcLvl files, which meant even non-SEPA files would have it set to 'SEPA', unless they explicitly overrode the function defining the value of the node. This commit fixes this, by not setting any value to SvcLvl by default, and overriding for SEPA payments. ========================================================= [REF] account_iso20022: compute BIC tag depending on the payment method consistently The CdtrAgt node did not compute the tag of its BIC node in the same way as the DbtrAgt node, calling the dedicated helper. Because of that, it required a bit more payment method-specific code in SEPA, so that BIC becomes BICFI in the latest version. This commit removes that and calls the appropriate helper everywhere. ========================================================== [IMP] account_iso20022: Don't put 'SCT' in InstrId anymore Before this commit, each payment's InstrId always contained 'SCT' (unless a memo was set on the payment), standing for "SEPA Credit Transfer". For non-SEPA ISO20022, this did not make sense. Since this having this additional info in the field has not additional informative value anyway, we simply remove it. ========================================================== [FIX] account_iso20022: fix batch payments' error check 'posted' state does not exist on payments anymore. Anyway, this check was useless. Though, it prevented any of the error checks to run. Also, a condition had been mistakenly removed in the handling of payments with a too big amount. [IMP] account_iso20022: proper check on maximum amounts SEPA Credit Transfer documentation gives a maximum of 999,999,999.99 € to instructed amounts (https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf page 101). Swiss ISO 20022 uses 9,999,999,999.99 instead (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf, page 52). The check we ran before this commit was wrong. It checked 11 characters (coma included), while it's actually not included, for payments in EUR, and added another limit of 15 characters for other amounts. We relax it to put the proper restrictions when we know them, and not enforce another when we don't.
This fix updates spreadsheet chart tests so they match the latest trend line calculation behavior. It helps keep automated checks reliable after a calculation change, with no expected impact on everyday users.
Original PR description
Since o-spreadsheet/commit/9909fa98d data points are normalized to compute the trend line. Those 2 tests were computing a 2nd order polynomial trend line based on 2 data points only, which doesn't really makes sense. With only 2 points, the normalized labels become [0, 1]. The matrix is of the form x1 x2 x1^2 x2^2 it gives 0 1 0 1 with [0, 1] as the labels. This matrix is not invertible since the two lines are the same and the determinant is 0.
This update fixes several issues affecting payroll, rental sales, customer portal access, live chat messages, accounting reports, and inter-company stock validation. It improves reliability and user experience by preventing unnecessary payslip recalculations, removing access errors for portal users, restoring correct report layout, and ensuring business workflows continue without blocking errors.
The map view now removes an unnecessary gap between each group title and its list of records. This makes grouped map results easier to scan and gives the interface a cleaner, more polished appearance.
Original PR description
Before this commit: There is an excessive gap between the group title and the list of records. After this commit: The excessive space between the group title and the list of records has been removed. Task-4295965
The Sign app now avoids an error that could occur after choosing an option from the Tools dropdown and then scrolling. This keeps document preparation smoother and prevents users from being interrupted by a crash.
Original PR description
Before this fix, clicking any item in the dropdown under "Tools" caused a traceback when scrolling vertically or horizontally. This commit ensures that we check if the canvas is rendered before proceeding with the code, preventing the error. task-4212762
Miscellaneous changes
Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------
Original PR description
Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------  After: -------  Forward-Port-Of: odoo/odoo#186267 Forward-Port-Of: odoo/odoo#183506
In a multi-company DB, mentioning a user with less allowed companies would result to "Access to unauthorized or invalid companies." Steps to reproduce: - Create 2 companies "YourCompany" and "TestCompany" - Set Mitchell Admin allowed in both companies - Set Marc Demo allowed to only "TestCompany" - Set Marc Demo User Notification Preferences to "Handle in Odoo" - Check both companies on Mitchell Admin - Open a contact record and log a note with `@Marc Demo` mention => Dialog with `Ac
Original PR description
In a multi-company DB, mentioning a user with less allowed companies would result to "Access to unauthorized or invalid companies." Steps to reproduce: - Create 2 companies "YourCompany" and…
In a multi-company DB, mentioning a user with less allowed companies would result to "Access to unauthorized or invalid companies." Steps to reproduce: - Create 2 companies "YourCompany" and "TestCompany" - Set Mitchell Admin allowed in both companies - Set Marc Demo allowed to only "TestCompany" - Set Marc Demo User Notification Preferences to "Handle in Odoo" - Check both companies on Mitchell Admin - Open a contact record and log a note with `@Marc Demo` mention => Dialog with `Access to unauthorized or invalid companies.` This happens because the sending of bus notification related to inbox messages is made from the recipient, in this case Marc Demo. The context data still refer to Mitchell Admin, so `allowed_company_ids` still contain the 2 companies. Because of this, any search like `ResUsers.search(id,=,DemoUserId)` raises an exception from allowed_companies containing invalid companies for Marc Demo. This commit fixes the issue by overwriting the allowed companies in context to the user recipient that will receive the Inbox message. This overwrite only applies in the `.with_user()` scope. opw-4231529 Fix is similar to https://github.com/odoo/odoo/pull/46554 Forward-Port-Of: odoo/odoo#185583
With commit [1], `qweb.has_template` was replaced with its owl equivalent. Later, commit [2] further refactored this and consequently broke the possibility to use custom templates based on search type for website search. [1]: https://github.com/odoo/odoo/commit/123ba4ffccd6fc3895a18f3503690ba1593e3023 [2]: https://github.com/odoo/odoo/commit/21ecc7400f2211773713781c619f066a5fb37963 Forward-Port-Of: odoo/odoo#184404
Original PR description
With commit [1], `qweb.has_template` was replaced with its owl equivalent. Later, commit [2] further refactored this and consequently broke the possibility to use custom templates based on search type for website search. [1]: https://github.com/odoo/odoo/commit/123ba4ffccd6fc3895a18f3503690ba1593e3023 [2]: https://github.com/odoo/odoo/commit/21ecc7400f2211773713781c619f066a5fb37963 Forward-Port-Of: odoo/odoo#184404
The lang switching wasn't working properly. The lang bundle was not reloaded when the lang was changed. This commit fixes the issue by adding lang attribute on html element. opw-4246677 Forward-Port-Of: odoo/odoo#186647
Original PR description
The lang switching wasn't working properly. The lang bundle was not reloaded when the lang was changed. This commit fixes the issue by adding lang attribute on html element. opw-4246677 Forward-Port-Of: odoo/odoo#186647
[FIX] sale_stock: correct delivery color The issue: In the Sale order list view, the help message for Delivery Status states: - Red: Late - Orange: To process today - Green: On time However, in practice, the `delivery_status` color does not reflect the delivery timing. Steps to reproduce - Enable `delivery_status` in the `sale_order` list view. https://github.com/odoo/odoo/commit/470b756297f308f7b2a81f9d45c60d6d9655c647 introduced `delivery_status`for `sale_order` with tag colors
Original PR description
[FIX] sale_stock: correct delivery color The issue: In the Sale order list view, the help message for Delivery Status states: - Red: Late - Orange: To process today - Green: On time However, in practice, the `delivery_status` color does not reflect the delivery timing. Steps to reproduce - Enable `delivery_status` in the `sale_order` list view. https://github.com/odoo/odoo/commit/470b756297f308f7b2a81f9d45c60d6d9655c647 introduced `delivery_status`for `sale_order` with tag colors based on delivery timing. However, https://github.com/odoo/odoo/commit/ab53ea9db8dc2ab9791d9d813b727a748c5ff8c6 modified the color computation for `delivery_status` to no longer depend on delivery timing. opw-4280651 Forward-Port-Of: odoo/odoo#186004
This is an extension of this PR: https://github.com/odoo/odoo/pull/184742 It adds a unit test which checks the popout window through multiple records. It also checks that both attachment view and chatter popout controls are working fine. task-4275364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186536
Original PR description
This is an extension of this PR: https://github.com/odoo/odoo/pull/184742 It adds a unit test which checks the popout window through multiple records. It also checks that both attachment view and chatter popout controls are working fine. task-4275364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186536
Inside `_stock_account_get_anglo_saxon_price_unit` we are retrieving the posted cogs linked to the account.moves. To do that, currently we are retrieving every cogs and then calling `filtered` on the result. This can lead to a huge number of cogs to fetch in large databases. As this filtered call can easily be turned into a search_domain, we replace it by a search call. That way the number of cogs retrieved is way smaller. This has the effect of greatly reducing the memory footprint of the me
Original PR description
Inside `_stock_account_get_anglo_saxon_price_unit` we are retrieving the posted cogs linked to the account.moves. To do that, currently we are retrieving every cogs and then calling `filtered` on the result. This can lead to a huge number of cogs to fetch in large databases. As this filtered call can easily be turned into a search_domain, we replace it by a search call. That way the number of cogs retrieved is way smaller. This has the effect of greatly reducing the memory footprint of the method, as fetching all the fields on a large number of cogs quickly filled up the memory prior to this commit. #### Benchmark In a customer database with 5M account.move.lines, the peak memory consumption of the method when posting an invoice of 5 000 lines goes `1.5 GB -> 250 MB` according to memray --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186443
When we do not activate demo data, name of the administrator is Administrator and not Mitchell Admin. Because of that, test fails. This fix checks the username of administrator and generates assert texts based on that. [broken build errors](https://runbot.odoo.com/web#id=105350&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186555
Original PR description
When we do not activate demo data, name of the administrator is Administrator and not Mitchell Admin. Because of that, test fails. This fix checks the username of administrator and generates assert texts based on that. [broken build errors](https://runbot.odoo.com/web#id=105350&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186555
Steps: - Create a loyalty program with reward_type product - add a tag in product_tag field which is linked to multiple products Issue: - Description is not updated Cause: - The compute_reward_description is not called when tag is updated Fix: - added product_tag in depends for the _compute_reward_description opw-4039914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186151 Forward-Port-Of: odoo/od
Original PR description
Steps: - Create a loyalty program with reward_type product - add a tag in product_tag field which is linked to multiple products Issue: - Description is not updated Cause: - The compute_reward_description is not called when tag is updated Fix: - added product_tag in depends for the _compute_reward_description opw-4039914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186151 Forward-Port-Of: odoo/odoo#174135
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer columns image have the same size, which is bigger than the inner ones. This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in
Original PR description
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer…
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer columns image have the same size, which is bigger than the inner ones. This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in the columns content having different sizes depending on their position. Moreover, this was not a good solution because if we added more columns (by duplicating them) such that they go on multiple lines, the last one of the first line would not be correctly aligned to the content, because it is not the last column so it would keep its right padding. This would also result in the columns being shifted compared to the first line. This commit fixes that by removing the rules added by commit [1], as the columns were already aligned without them. The row margins are then set so they compensate the grid item padding, for the case when we are in grid mode, to avoid overflow. Note that if the padding is under 15px, the columns are not aligned anymore, but this is the compromise to have identical columns. [1]: https://github.com/odoo/odoo/commit/fb55f688f6be2211ebeea4ba431a06230c40fb6b opw-4172256 Forward-Port-Of: odoo/odoo#186613 Forward-Port-Of: odoo/odoo#182951
Currently when checking if an account.move has downpayments we need to call `filtered` on `self.invoice_line_ids.sale_line_ids`. This can be pretty heavy, especially in `_stock_account_get_anglo_saxon_price_unit` as this method will be called for each account.move.line linked to the invoice being posted. This commit introduces a small method `_get_anglo_saxon_price_ctx` that can be overriden to add data to the context that will be used in `_stock_account_get_anglo_saxon_price_unit`. This i
Original PR description
Currently when checking if an account.move has downpayments we need to call `filtered` on `self.invoice_line_ids.sale_line_ids`. This can be pretty heavy, especially in `_stock_account_get_anglo_saxon_price_unit` as this method will be called for each account.move.line linked to the invoice being posted. This commit introduces a small method `_get_anglo_saxon_price_ctx` that can be overriden to add data to the context that will be used in `_stock_account_get_anglo_saxon_price_unit`. This is done in `sale_stock` to avoid the computation of downpayments for each account.move.line. #### Benchmark Customer database posting an invoice with 5000 lines and 1190 linked sale.orders, products in FIFO. Timing of `_stock_account_get_anglo_saxon_price_unit`: 10min -> 2min30. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186486 Forward-Port-Of: odoo/odoo#184254
test_duration_expected_when_done was undeterministically failing, if the test ran at specific times, the difference in minutes between button_start and button_finish functions was rounded incorrectly. having time frozen should solve this behavior. build error in question: [Runbot error](https://runbot.odoo.com/web#id=76232&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
test_duration_expected_when_done was undeterministically failing, if the test ran at specific times, the difference in minutes between button_start and button_finish functions was rounded incorrectly. having time frozen should solve this behavior. build error in question: [Runbot error](https://runbot.odoo.com/web#id=76232&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185026
Since the unique name constraint only works for the active language, it's possible to have more than one tax with the same name in another language. If that's the case, a `ValueError: Expected singleton` error will occur while retrieving the fields in `unique_tax_name_key`. Found in upg-2077316. Forward-Port-Of: odoo/odoo#183111
Original PR description
Since the unique name constraint only works for the active language, it's possible to have more than one tax with the same name in another language. If that's the case, a `ValueError: Expected singleton` error will occur while retrieving the fields in `unique_tax_name_key`. Found in upg-2077316. Forward-Port-Of: odoo/odoo#183111
To be compliant with belgium we need to fix the reference of the order in the qr code payment. If we have 12 digits at the end of the reference, it considers it as a structured reference but isn't. So we also add the tracking number at the end of the reference. opw-4285530 Forward-Port-Of: odoo/odoo#186560
Original PR description
To be compliant with belgium we need to fix the reference of the order in the qr code payment. If we have 12 digits at the end of the reference, it considers it as a structured reference but isn't. So we also add the tracking number at the end of the reference. opw-4285530 Forward-Port-Of: odoo/odoo#186560
before this commit, for obfuscating data in the res.partner model, the display_name field is used, which is non stored field and thus in the log, an error/warning is shown as follows while running obfuscate command odoo.cli.obfuscate: Invalid fields: res_partner.display_name the invalid warning is raised as the field is not a stored field and thus removing it from the obfuscation even though, the res.partner name field is obfuscated, the same data is remaining in the complete_name
Original PR description
before this commit, for obfuscating data in the res.partner model, the display_name field is used, which is non stored field and thus in the log, an error/warning is shown as follows while running obfuscate command odoo.cli.obfuscate: Invalid fields: res_partner.display_name the invalid warning is raised as the field is not a stored field and thus removing it from the obfuscation even though, the res.partner name field is obfuscated, the same data is remaining in the complete_name field, so adding this field to obfuscating field list after this commit, the log will not show the invalid field warning and complete name also will be obfuscated --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186583
**Steps to reproduce the bug:** - Create two storable products, “P1” and “P2”. - Set “P1” to be tracked by Serial Number - Update P1 with SN1. - Create a repair order: - Set P1 with SN1. - Save. - Edit and update the product to P2. - Save. - Print the order. **Problem:** The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is no
Original PR description
**Steps to reproduce the bug:** - Create two storable products, “P1” and “P2”. - Set “P1” to be tracked by Serial Number - Update P1 with SN1. - Create a repair order: - Set P1 with SN1. - Save. - Edit and update the product to P2. - Save. - Print the order. **Problem:** The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is not considered in the write of the repair order, even though the `onchange` sets the “lot_id” field to False: https://github.com/odoo/odoo/blob/16.0/addons/repair/models/repair.py#L208-L212 **opw-4281176** Forward-Port-Of: odoo/odoo#186180 Forward-Port-Of: odoo/odoo#185552
Wrong closed parentheses in html_escape causes one of the OdooBot random responses to be rendered incorrectly.  Forward-Port-Of: odoo/odoo#186655
Original PR description
Wrong closed parentheses in html_escape causes one of the OdooBot random responses to be rendered incorrectly.  Forward-Port-Of: odoo/odoo#186655
The problem can be reproduced in two ways - by finding a view that integrates a many2one on `ir.model.fields` used without no_create - manually add the field via studio on any view. I found a view with the problem: `marketing_campaign_view_form` which uses the field `unique_field_id` which is defined as such: ```py unique_field_id = fields.Many2one( ir.model.fields', string='Unique Field', compute='_compute_unique_field_id', readonly=False, store=True) ``` To ge
Original PR description
The problem can be reproduced in two ways - by finding a view that integrates a many2one on `ir.model.fields` used without no_create - manually add the field via studio on any view. I found a view…
The problem can be reproduced in two ways
- by finding a view that integrates a many2one on `ir.model.fields` used without no_create
- manually add the field via studio on any view.
I found a view with the problem: `marketing_campaign_view_form` which uses the field `unique_field_id` which is defined as such:
```py
unique_field_id = fields.Many2one(
ir.model.fields', string='Unique Field',
compute='_compute_unique_field_id', readonly=False, store=True)
```
To get there:
- Install `marketing_automation`.
- Open the app
- You arrive in the campaigns view
- Create a new record
- Write the name of a field that doesn't exist, like `dkfjl`.
- A dropdown asks you to “Create `dkfjl`”.
- Click on it
- Crash
```
File “/home/achraf/src/160/odoo/odoo/addons/base/models/ir_model.py”, line 916, in create
if not vals.get('model'):
AssertionError: missing model name for {'field_description': 'dfasf'}
```
This commit removes the assertion to use `model` returned by `super().create`
so that the web client catches the error and proposes to create the
record with not one field name but all the required fields
opw-4116187
Forward-Port-Of: odoo/odoo#186598
Forward-Port-Of: odoo/odoo#186295When using Odoo with a read-only replica, it is necessary for the replica to be online, otherwise read-only requests will fail. This commit implements a simple failover mechanism: if a RO cursor cannot be acquired, we fall back to the RW cursor. We also deactivate the RO feature by setting `_db_readonly` to `None`. It will have the effect of deactivating the RO feature for the subsequent requests until Odoo is restarted or the worker is recycled. In the context of the Postgres replication,
Original PR description
When using Odoo with a read-only replica, it is necessary for the replica to be online, otherwise read-only requests will fail. This commit implements a simple failover mechanism: if a RO cursor…
When using Odoo with a read-only replica, it is necessary for the replica to be online, otherwise read-only requests will fail. This commit implements a simple failover mechanism: if a RO cursor cannot be acquired, we fall back to the RW cursor. We also deactivate the RO feature by setting `_db_readonly` to `None`. It will have the effect of deactivating the RO feature for the subsequent requests until Odoo is restarted or the worker is recycled. In the context of the Postgres replication, such behavior is useful since synchronous replication doesn't guarantee that the replica is actually up-to-date in some edge cases. The most common case being the unexpected restart of the replica: there is a short period of time during which the replica accepts incoming requests but is still catching up with the master. Delaying the use of the replica should help reducing the race conditions in such cases. 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#186014
Issue: When multiple companies are set up, if you are working in a company with a different l10n_sa configuration and attempt to send an EDI document for another company, the retrieved API URL may be incorrect depending on the other company's configuration. Steps to reproduce: 1. Create Company A and set `l10n_sa_api_mode` to production. 2. Create Company B and set `l10n_sa_api_mode` to sandbox. 3. Navigate to Company B (keeping Company A selected). 4. Create an invoice for Company A or
Original PR description
Issue: When multiple companies are set up, if you are working in a company with a different l10n_sa configuration and attempt to send an EDI document for another company, the retrieved API URL may be incorrect depending on the other company's configuration. Steps to reproduce: 1. Create Company A and set `l10n_sa_api_mode` to production. 2. Create Company B and set `l10n_sa_api_mode` to sandbox. 3. Navigate to Company B (keeping Company A selected). 4. Create an invoice for Company A or attempt to send the EDI. The API URL retrieved will be for Company B, while it should be for Company A. New behavior: The API URL is now correctly retrieved using the company linked to the journal. Additionally, we now follow the same access as in lines 440 and 539 to fetch the SA environment. opw-4253449 Forward-Port-Of: odoo/odoo#186266
before this commit: ============== - The configuration popup did not indicate which combinations were unavailable. - Able to select archived products in combo configuration popup.  after this commit: ============== - Disabled attribute values that are part of archived combinations in the product configuration popup. - Disabled archived products in the combo configuration popup. - Restricte
Original PR description
before this commit: ============== - The configuration popup did not indicate which combinations were unavailable. - Able to select archived products in combo configuration popup.  after this commit: ============== - Disabled attribute values that are part of archived combinations in the product configuration popup. - Disabled archived products in the combo configuration popup. - Restricted the creation of combo product if any selected products are archived  Task - 4231315 Forward-Port-Of: odoo/odoo#181754
Store the partner one by one is very costly. Since all the partner return by _mail_get_partners will end up in the store, we can store them all at once This improve the time for get_today_call_activities from 25000ms to around 700ms for one of the worse case (thousands of partners to fetch) Forward-Port-Of: odoo/enterprise#68118
Original PR description
Store the partner one by one is very costly. Since all the partner return by _mail_get_partners will end up in the store, we can store them all at once This improve the time for get_today_call_activities from 25000ms to around 700ms for one of the worse case (thousands of partners to fetch) Forward-Port-Of: odoo/enterprise#68118
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corres
Original PR description
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when…
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corresponding subscription. Steps to reproduce on runbot: install partner_commission set up a subscription with a referrer and a commission plan create invoice for the subscription try to register the payment for the invoice error raised regarding a max function with no args Notes: looking to investigate further why the subscription dates are not passed from the subscription to the order lines to the invoice lines in 17.0+ field name is changed from `subscription_end_date` to `deferred_end_date` (same for `start` date), will have to adjust in fw ports opw-4240937 Forward-Port-Of: odoo/enterprise#73465 Forward-Port-Of: odoo/enterprise#73428
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660 Forward-Port-Of: odoo/enterprise#73510 Forward-Port-Of: odoo/enterpri
Original PR description
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660 Forward-Port-Of: odoo/enterprise#73510 Forward-Port-Of: odoo/enterprise#72248
### Steps to reproduce: - Go in Accounting > Reporting > Tax Report - Select "Group By: Tax > Account" - A warning should appear on the tax lines ### Cause: In the consistency check the net value retrieved is an empty string so the calculation is done with a net_value of 0 and an error is detected. ### Solution: If the net_value retrieved is not valid, the consistency check is not done. opw-4263695 Forward-Port-Of: odoo/enterprise#73319
Original PR description
### Steps to reproduce: - Go in Accounting > Reporting > Tax Report - Select "Group By: Tax > Account" - A warning should appear on the tax lines ### Cause: In the consistency check the net value retrieved is an empty string so the calculation is done with a net_value of 0 and an error is detected. ### Solution: If the net_value retrieved is not valid, the consistency check is not done. opw-4263695 Forward-Port-Of: odoo/enterprise#73319
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled. However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron. This often resulted in a situation wher
Original PR description
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook…
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled.
However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron.
This often resulted in a situation where only the first subscription was ready for the hook, while the others are not, resulting in only the first delivery created.
---
Test result before fix:
```
2024-11-06 15:41:52,210 35880 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_cron_product_multiple_delivery_creation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 501, in test_cron_product_multiple_delivery_creation
self.assertTrue(bool(move_1))
AssertionError: False is not true
```
OPW-4166852
Forward-Port-Of: odoo/enterprise#73466
Forward-Port-Of: odoo/enterprise#73397When the value to store into a generic id was zero (which can typically happen when doing a non-relational groupby), None was stored into the generic id instead. On groupby lines, this lead the unfold of that line to behave weirdly and not show the proper results. The reason was that, in Python, doing 0 == False gives True. So, when doing 0 in (False, None), we ended up with a True result. Forward-Port-Of: odoo/enterprise#72808
Original PR description
When the value to store into a generic id was zero (which can typically happen when doing a non-relational groupby), None was stored into the generic id instead. On groupby lines, this lead the unfold of that line to behave weirdly and not show the proper results. The reason was that, in Python, doing 0 == False gives True. So, when doing 0 in (False, None), we ended up with a True result. Forward-Port-Of: odoo/enterprise#72808
The issue: When duplicating a quality check, the name and control_date fields were copied, resulting in duplicated values. How to reproduce the issue: -Create a quality check -Pass the quality check -Duplicate the quality check Explanation: The name and control_date fields were duplicated during the copy process, preventing the create method from assigning the next sequence number. opw-4197697 Forward-Port-Of: odoo/enterprise#71372
Original PR description
The issue: When duplicating a quality check, the name and control_date fields were copied, resulting in duplicated values. How to reproduce the issue: -Create a quality check -Pass the quality check -Duplicate the quality check Explanation: The name and control_date fields were duplicated during the copy process, preventing the create method from assigning the next sequence number. opw-4197697 Forward-Port-Of: odoo/enterprise#71372
With this PR, `filtered` will be removed from `_get_out_of_fiscal_year_reversed_moves` method and added to the domain for improve performance. Previous PR: https://github.com/odoo/enterprise/pull/66824 task-3915664 Forward-Port-Of: odoo/enterprise#73483 Forward-Port-Of: odoo/enterprise#73309
Original PR description
With this PR, `filtered` will be removed from `_get_out_of_fiscal_year_reversed_moves` method and added to the domain for improve performance. Previous PR: https://github.com/odoo/enterprise/pull/66824 task-3915664 Forward-Port-Of: odoo/enterprise#73483 Forward-Port-Of: odoo/enterprise#73309
This issue is coming from importing a CSV File in the 'account.bank.statement.line' model was caught by a sentry. Because if the CSV file does not have two columns, which are 'debit' and 'credit', that time getting error is 'amount' is not in the list. step to reproduce- - Install the Accounting. - Go to Dashboard > click on import statement button of Bank card - Upload the statement ([bank statement](https://drive.google.com/file/d/1s_a3Ym27QKRDh63BwPb-3P4g4kjmbH2l/view?usp=drive_link))
Original PR description
This issue is coming from importing a CSV File in the 'account.bank.statement.line' model was caught by a sentry. Because if the CSV file does not have two columns, which are 'debit' and 'credit', that time getting error is 'amount' is not in the list. step to reproduce- - Install the Accounting. - Go to Dashboard > click on import statement button of Bank card - Upload the statement ([bank statement](https://drive.google.com/file/d/1s_a3Ym27QKRDh63BwPb-3P4g4kjmbH2l/view?usp=drive_link)) - After, click on Test button - Error will be generated.  Sentry: -3931578971 Forward-Port-Of: odoo/enterprise#37315