Daily updates from Odoo
Friday, November 8, 2024
84 changes
12 changes
Miscellaneous changes
Description of the issue/feature this PR addresses: Link to task: [#4218972](https://www.odoo.com/web#model=project.task&id=4218972) This change fixes english and arabic labels & translations in the l10n_sa_invoice module Current behavior before PR: Some labels are inaccurate or do not match the saudi arabia ZATCA invoice template. Desired behavior after PR is merged: Labels are more accurate and match the saudi arabia ZATCA invoice template. --- I confirm I have signed the CL
Original PR description
Description of the issue/feature this PR addresses: Link to task: [#4218972](https://www.odoo.com/web#model=project.task&id=4218972) This change fixes english and arabic labels & translations in the l10n_sa_invoice module Current behavior before PR: Some labels are inaccurate or do not match the saudi arabia ZATCA invoice template. Desired behavior after PR is merged: Labels are more accurate and match the saudi arabia ZATCA invoice template. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186096 Forward-Port-Of: odoo/odoo#184060
Steps to reproduce: 1. Take any snippet and select any custom gradient color. 2. Reopen the background color - The selected custom gradient color is not retained as expected. Before version 16, we used wysiwyg, which called the start function to set selected colors easily. In version 17, we switched to OwlJS. Now, color picker always setting the default color as selected color. Therefore, it displays the default color instead of the selected color.  After this PR, the selected color will be set in the start function by replacing the default color, and updating RGBA values accordingly.  Task-3631963 Forward-Port-Of: odoo/odoo#166961
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
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#186295before 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
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
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
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
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
Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points). That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one. Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&
Original PR description
Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points). That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one. Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#186110
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186580
Original PR description
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186580
23 changes
Enhancements to existing features
This update adapts automated tests to a changed messaging initialization route. It helps keep accounting and studio test coverage aligned with the platform so future releases remain reliable without changing user-facing behavior.
Original PR description
https://github.com/odoo/odoo/pull/179352
The bank account synchronization area has had its automated tests updated to use Odoo's newer testing approach. This helps keep quality checks maintainable and reliable without changing day-to-day user functionality.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666
The VoIP and OnSIP VoIP test suites were updated to use Odoo's newer testing framework. This is an internal quality improvement that helps keep the modules maintainable without changing the user-facing VoIP experience.
Original PR description
Purpose of this PR is to convert remove QUnit tests which rely on `mail/test_utils` to hoot. Part of task-3818666
This update modernizes how Odoo enforces key data rules and database indexes across many business modules. It helps improve data consistency and reliability behind the scenes, with little expected day-to-day impact for users.
Original PR description
Replace virtual constraints. odoo/odoo#175783
Resolved issues and error corrections
The spreadsheet document tests were adjusted to match a recent change in how chart trend lines are calculated. This prevents unreliable test failures for an unrealistic chart setup and helps keep spreadsheet chart functionality stable.
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.
Features or functions removed from Odoo
This change removes remaining support for an already-removed comparison menu in manufacturing work orders and cohort analysis views. It simplifies the affected screens behind the scenes and keeps Enterprise modules aligned with the main Odoo interface changes.
Original PR description
The comparison menu is removed in https://github.com/odoo/odoo/pull/186454. Here we simplify a bit the component MrpDisplay and the cohort view to no longer accept a prop "comparison" (unused in the case of MrpDisplay). Note that we do not thoroughly refactor the cohort view since there are ongoing discussions on refactor it using the spreadsheet library. Task ID: 4307873
Code cleanup and technical improvements
This update reorganizes Point of Sale component files into clearer dedicated folders across related POS add-ons. It does not introduce new business functionality, but it should make future maintenance and updates easier for development teams.
Original PR description
Reorganization of all `components` files into a specific folder. Task-id: 4290514
Miscellaneous changes
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
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 Forward-Port-Of: odoo/enterprise#70839
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 Forward-Port-Of: odoo/enterprise#70839
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:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **So
Original PR description
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **Solution:** There were a function for the default (_default_mod_349_invoice_type) and an onchange on partner (_onchange_partner_id_set_347_invoice_type). Both of them were checking different conditions. The fix is merging these 2 methods by converting the field into a computed stored field where both conditions are handled. opw-4194030 Forward-Port-Of: odoo/enterprise#72958
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario Forward-Port-Of: odoo/enterprise#72345
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario Forward-Port-Of: odoo/enterprise#72345
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
In this commit : - we add the pseudo selector :not(:visible) to invisible elements with the aim to remove _legacyVisible from findTrigger method in tour_step_automatic.js. - we also add "hover" action to make the element of the next step visible instead of using tricks to make it visible. Forward-Port-Of: odoo/enterprise#73479
Original PR description
In this commit : - we add the pseudo selector :not(:visible) to invisible elements with the aim to remove _legacyVisible from findTrigger method in tour_step_automatic.js. - we also add "hover" action to make the element of the next step visible instead of using tricks to make it visible. Forward-Port-Of: odoo/enterprise#73479
Prior to this commit, the alert displayed in planning for shifts-switch, time off conflict and shifts conflict was too big, leaving a lot of empty space within the div. This commit sets some bootstrap classes to fix the issue. Task: 4224786 Forward-Port-Of: odoo/enterprise#72289
Original PR description
Prior to this commit, the alert displayed in planning for shifts-switch, time off conflict and shifts conflict was too big, leaving a lot of empty space within the div. This commit sets some bootstrap classes to fix the issue. Task: 4224786 Forward-Port-Of: odoo/enterprise#72289
Install "l10n_uk" Accounting / Reporting / Statement Reports / Tax Return Actions / Send to HMRC Issue: Traceback will raise ``` ValueError: Invalid field l10n_uk.vat.obligation.currency_table_period_key in leaf ('currency_table_period_key', '=', '18A1') ``` It occurs after e598fcb48b5e4f0126406a4008f175a88528ba85 replaced occurrences of `period_key` with `currency_table_period_key` opw-4283511 Forward-Port-Of: odoo/enterprise#73481
Original PR description
Install "l10n_uk"
Accounting / Reporting / Statement Reports / Tax Return
Actions / Send to HMRC
Issue: Traceback will raise
```
ValueError: Invalid field l10n_uk.vat.obligation.currency_table_period_key in leaf ('currency_table_period_key', '=', '18A1')
```
It occurs after e598fcb48b5e4f0126406a4008f175a88528ba85 replaced occurrences of `period_key` with `currency_table_period_key`
opw-4283511
Forward-Port-Of: odoo/enterprise#73481### 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
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
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
Reproduce: 1/ Create documents and assign a company an admin (`group_erp_manager`) doesn't have access to 2/ As that admin, open the Documents app 3/ Go to "Home" and expect an Access Error There was a mismatch between `user_permission`'s search and compute methods for admins. We also take the opportunity to fix the SHARED (and clean COMPANY) search panel `CategoryDomain`s as odoobot's ownership wasn't used to make documents visible in COMPANY (therefore not in SHARED) on its ow
Original PR description
Reproduce: 1/ Create documents and assign a company an admin (`group_erp_manager`) doesn't have access to 2/ As that admin, open the Documents app 3/ Go to "Home" and expect an Access Error There was a mismatch between `user_permission`'s search and compute methods for admins. We also take the opportunity to fix the SHARED (and clean COMPANY) search panel `CategoryDomain`s as odoobot's ownership wasn't used to make documents visible in COMPANY (therefore not in SHARED) on its own. A test is added. Task-4241620 Forward-Port-Of: odoo/enterprise#71462
With this PR, `filtered` will be removed from `_get_out_of_fiscal_year_reversed_moves` method and added to the domain for improve performance, and also some minor changes will be made in `_l10n_in_get_fiscal_year_start_date`. 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, and also some minor changes will be made in `_l10n_in_get_fiscal_year_start_date`. 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
Before this commit, the attachment_view_move_line component was not adapted to the new changes done in the mail_popout_service. This commit solves this problem. task-4275364 Forward-Port-Of: odoo/enterprise#73386
Original PR description
Before this commit, the attachment_view_move_line component was not adapted to the new changes done in the mail_popout_service. This commit solves this problem. task-4275364 Forward-Port-Of: odoo/enterprise#73386
42 changes
Enhancements to existing features
The 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
The 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 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.
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
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
7 changes
Resolved issues and error corrections
This update resolves an issue where users were receiving an error when modifying the unit amount field on non-timesheet analytic account lines with large numbers (over 6 digits). The change now correctly validates the unit amount field only for timesheet lines, preventing this error and improving data entry reliability.
Original PR description
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet. closes odoo/odoo#174964
This update ensures that the 'Extra Quotations' setting in the project management interface takes up the full screen width, regardless of the screen size. Previously, this setting was limited in its display space, which has now been corrected for a more consistent and user-friendly experience.
Original PR description
Before this commit, the `Extra Quotations` setting displayed in the form view of `project.project` model does not take the maximal width available on larger screen. This commit makes sure the width of that setting takes all available space as the other settings. task-4294845
This update resolves an issue preventing users from applying sign actions to documents. The fix ensures that users with appropriate access to both the document and the sign process can successfully initiate the signing workflow. Additionally, new testing has been added to prevent duplicate attachment creation.
Original PR description
[FIX] documents{_sign}: fix access error applying sign action How to reproduce: - Install documents_sign and log as admin - In documents, create an action (Workspace: Finance, Create: PDF to Sign) -…
[FIX] documents{_sign}: fix access error applying sign action
How to reproduce:
- Install documents_sign and log as admin
- In documents, create an action (Workspace: Finance, Create: PDF to Sign)
- Then upload a pdf in the workspace Finance
- Log as Marc Demo
- In documents, select the PDF uploaded as admin
- Click on the action created
You get the error: "Sorry, you are not allowed to access this document." while the expected behavior is that users who have access to the document and to Sign should be able to use the action. We solve that in this commit.
We also add a test checking that applying an action to sign a pdf document not owned by the user that perform the action, doesn't duplicate the attachment if the attachment is owned by the document (res_id and res_model pointing to the document; the ownership is transferred to the sign.template created) and duplicate it otherwise.
Technical note: the error was caused by the trick used in the override of sign_template.create in documents_sign which was setting the res_model to False and res_id to 0 for attachment linked to document to allow the super method to link that attachment to the created sign_template (by releasing the ownership of the attachment from the document). But as ir_attachment prevents to link an attachment with res_id = 0 to a record if it is not done by the owner of that
attachment, there was an error. We remove that tricks by defining a method that determine if sign_template can take the ownership of the attachment or not which we override in document_sign and make it return True when the attachment is owned by a document.
Task-4000988
Forward-Port-Of: odoo/enterprise#65206This update resolves an issue where completion certificate reports displayed dates based on the user's local timezone, leading to potential inconsistencies. The fix ensures all dates are recorded in UTC, guaranteeing accurate and reliable reporting regardless of user location. This improves data integrity and simplifies certificate generation.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. In the Sign app, send a request for a signature. 2. Complete the signature and submit the request. 3. Observe the completion certificate that is generated. **Issue:** The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies. **Solution:** replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone. task-4014378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the account reports module where zero values were incorrectly interpreted as True, leading to inaccurate data when performing group-by operations. The fix ensures that zero values are handled correctly, preventing unexpected behavior and improving the reliability of report data. This resolves a potential issue with data discrepancies.
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
This update corrects a bug in the bank statement import process. The issue occurred when the CSV file didn't include the required 'debit' and 'credit' columns, leading to an error. This fix ensures the import function now handles CSV files with the correct format, preventing import failures.
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
This pull request reverts a previous change that was causing issues with the mail-chatter dropzone feature in the documents module. The change was rolled back to restore the previous, stable behavior. This ensures consistent functionality for users.
Original PR description
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619