Wednesday, September 4, 2024
25 changes · 17.0
Resolved issues and error corrections
French invoice PDFs now keep the information table properly formatted when a separate customer address column is shown. This prevents broken-looking invoices when billing a child contact with a different address from the main company.
Original PR description
Version: 17.0+ Issue: When the Customer Address column is included in the report pdf, the table format breaks. This column is added when the `partner_id.commercial_partner_id` is different than the `partner_id` of the invoice or invoice refund. Purpose of this PR: To restore the format of the information table when the Customer Address column is included. Similar to #176209 Steps to Reproduce on Runbot: 1) Install l10n_fr and switch to FR Company 2) Configure contacts a French company to have a child contact with a different address. 3) Create invoice with the child contact as the customer. 4) Print invoice and the informations table will be formatted incorrectly. opw-4122930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoicing managers can now create a bank account from Settings without needing broader Administration/Settings permissions. This prevents an access error during onboarding and lets authorized finance users complete the setup smoothly.
Original PR description
Steps to reproduce: 1. Login with a user with invoicing manager permission, but not settings one. 2. Go to Settings > Add a Bank account. 3. Fill the data, and click on "Create". Current behavior: Access Error, due to the lack of the Administration/Settings permission Expected behavior: No error The solution is to put sudo on the operation. @Tecnativa TT50693
Importing a custom module with an incompatible version will still show users the appropriate error message, but it will no longer create an unnecessary system error log. This reduces noise for support and monitoring teams without changing the user-facing validation.
Original PR description
Currently, a log error is generated when the user tries to import a module that is not the same as the current Odoo version. Stack Trace: ``` ValueError: Invalid version '17.0.1.0.0'. Modules should…
Currently, a log error is generated when the user tries to import a module that is not the same as the current Odoo version.
Stack Trace:
```
ValueError: Invalid version '17.0.1.0.0'. Modules should have a version in format `x.y`, `x.y.z`, `saas~17.2.x.y` or `saas~17.2.x.y.z`.
File "addons/base_import_module/models/ir_module.py", line 253, in _import_zipfile
self.sudo()._import_module(mod_name, path, force=force, with_demo=with_demo)
File "addons/base_import_module/models/ir_module.py", line 81, in _import_module
values['latest_version'] = adapt_version(terp['version'])
File "odoo/modules/module.py", line 423, in adapt_version
raise ValueError(f"Invalid version {base_version!r}. Modules should have a version in format `x.y`, `x.y.z`,"
```
The error was caught on log because at [1] `_logger.exception()` was used, and this log error was not
useful because after the printing, the log `UserError` was raised, which shows the user what's wrong with its custom module.
This commit removes the logger exception because the `UserError` shows
what is wrong with the custom modules.
[1]-https://github.com/odoo/odoo/blob/b95edd874ce904ef231c295790a003992db002e3/addons/base_import_module/models/ir_module.py#L255-L258
sentry-4931285432Fixes an error that could interrupt administrators when restoring several archived views at once. This makes view management more reliable and prevents a technical traceback from appearing during normal maintenance tasks.
Original PR description
When the user tries to unarchive the multiple views, a traceback will appear. Steps to reproduce the error: - Install 'website' - Go to Settings > Technical > Views - Open archived views > unarchive…
When the user tries to unarchive the multiple views,
a traceback will appear.
Steps to reproduce the error:
- Install 'website'
- Go to Settings > Technical > Views
- Open archived views > unarchive multiple views
Traceback:
```
ValueError: Expected singleton: ir.ui.view(534, 535, 537)
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "odoo/models.py", line 5771, in action_unarchive
return self.filtered(lambda record: not record[self._active_name]).toggle_active()
File "odoo/models.py", line 5759, in toggle_active
(self - active_recs)[self._active_name] = True
File "odoo/models.py", line 6619, in __setitem__
return self._fields[key].__set__(self, value)
File "odoo/fields.py", line 1376, in __set__
records.write({self.name: write_value})
File "addons/website/models/theme_models.py", line 366, in write
return super().write(vals)
File "addons/website/models/ir_ui_view.py", line 95, in write
return super(View, self).write(vals)
File "odoo/addons/base/models/ir_ui_view.py", line 529, in write
self._validate_fields(['arch_db'])
File "odoo/models.py", line 1484, in _validate_fields
check(self)
File "odoo/addons/base/models/ir_ui_view.py", line 371, in _check_xml
view=self.key or self.id,
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5856, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/9be0c5348bfeb338bcba95b2a9c01e0d7dd14306/odoo/addons/base/models/ir_ui_view.py#L379 Here, self is used in place of view.
So it will lead to the above traceback.
sentry-5604174783
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents decorative text highlights from being incorrectly saved into website pages after delayed editor updates. Users can now switch between mobile and desktop views without highlights becoming misplaced or outdated, improving page editing reliability.
Original PR description
Steps to reproduce the bug: - Turn on the Cookies from setting for the website. - Go to front end, click on editor, go to theme tab. - Click on any Font Family, and select add a google font. - After adding, save. - Add a "Title" block, go to "mobile view", and add a text highlight. - Save the page. - Bug: If you switch between mobile and desktop views, the highlights are not updated (because the SVGs are fixed and get added to the view of the page). The bug occurred because some options, like the popup, trigger a resize after a delay before the page is saved. This causes the highlights to be added back to the DOM after the "TextHighlight" widget has been destroyed. To fix this, we prevent adding highlights if the "TextHighlight" widget has been destroyed. opw-4081390
This fix updates the SMS mailing report list view so hidden columns are handled in the correct way. It helps prevent display issues in the reporting interface and keeps the screen behavior consistent for users.
Original PR description
-Probably miss by script since https://github.com/odoo/odoo/commit/332c117f60a36f723c450f61ce2e0e7181d66c21 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
Percent pie widgets created in Studio no longer show a duplicate field name in list views. This makes list screens cleaner and easier for users to read without changing the underlying data.
Original PR description
Specification: When creating a percent pie widget in the list view using Studio, the field's name has been added after percent pie, which is not user-friendly. Expected behavior: The duplicate label should not be visible in the list view. Task-3942207
The mail activity menu now restores visual highlighting on activity text in the top bar. This helps users recognize they can click the text to filter activities by time period, improving navigation and reducing confusion.
Original PR description
Adding back the activity text highlight in the systray to make sure users understand the text is actually clickable and they can filter their activities on a specific time frame. Related commit: odoo/odoo@6b72bde3a7d3d3d9a12490431b5192ddb5230d9c Task-4141680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when users tried to edit invoice report templates in Studio on databases with no invoice records. The reports now handle missing tax totals safely, allowing Studio editing to continue instead of showing a crash.
Original PR description
Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record. Steps to reproduce: - Install an 'account' and 'web_studio'…
Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record.
Steps to reproduce:
- Install an 'account' and 'web_studio' module (Without demo data).
- Navigate to invoicing / Customers / Invoices and open a web studio mode.
- Open reports and click on the 'Invoice' or 'Invoices without Payment' reports.
- Click on 'EDIT SOURCES'.
See Traceback:-
```
TypeError: 'bool' object is not subscriptable
File "<744>", line 200, in template_744
File "<744>", line 13, in template_744_content
QWebException: Error while render the template
TypeError: 'bool' object is not subscriptable
Template: ir.ui.view(744,)
Path: /t/t
Node: <t t-foreach="tax_totals[\'subtotals\']" t-as="subtotal"/>
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 652, in save_report
report_html = self._render_report(report, record_id)
File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 597, in _render_report
return request.env['ir.actions.report'].with_context(studio=True)._render_qweb_html(report, [record_id] if record_id else [], {"studio": True})
File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_actions_report.py", line 24, in _render_qweb_html
return super(IrActionsReport, self)._render_qweb_html(report_ref, docids, data)
File "odoo/addons/base/models/ir_actions_report.py", line 927, in _render_qweb_html
return self._render_template(report.report_name, data), 'html'
File "odoo/addons/base/models/ir_actions_report.py", line 654, in _render_template
return view_obj._render_template(template, values).encode()
File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_ui_view.py", line 1302, in _render_template
return super(View, self)._render_template(template, values)
File "odoo/addons/base/models/ir_ui_view.py", line 2024, in _render_template
return self.env['ir.qweb']._render(template, values)
File "odoo/tools/profiler.py", line 302, in _tracked_method_render
return method_render(self, template, values, **options)
File "odoo/addons/base/models/ir_qweb.py", line 594, in _render
result = ''.join(rendering)
File "<748>", line 42, in template_748
File "<748>", line 31, in template_748_content
File "<747>", line 90, in template_747
File "<747>", line 72, in template_747_content
File "<747>", line 60, in template_747_t_call_0
File "<742>", line 2412, in template_742
File "<742>", line 2394, in template_742_content
File "<742>", line 1650, in template_742_t_call_0
File "<744>", line 208, in template_744
```
The issue occurs when the system tries to access a boolean value which is stored in 'Tax_totals' in the 'document_tax_totals' template [1] and this a boolean value is passed into 'tax_totals' from this line [2] because record is not available.
link [1]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/views/report_invoice.xml#L200-L201
link [2]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/models/account_move.py#L1348
To resolve the issue, Add a condition that checks whether the 'Tax_totals' is available before call the 'document_tax_totals' template.
sentry-4499699758
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes Chilean invoice reports so discount amounts and discount percentages appear under the correct column headings. It prevents confusion when customers or staff review invoice discounts, improving document accuracy.
Original PR description
The discount percentage and discount amount values were not in the correct positions. To fix this, I placed the Discount Amount after the Discount Percentage ("td_discount") to make the table header…
The discount percentage and discount amount values were not in the correct positions.
To fix this, I placed the Discount Amount after the Discount Percentage ("td_discount") to make the table header and table data consistent. OWP-4112378
-->
Description of the issue/feature this PR addresses:
The Discount Percentage value and the Discount Amount value are not in the correct positions. The Discount Amount was placed after the unit price ("td_priceunit"), and its value was displayed after the Discount Percentage ("td_discount"). As a result, the values were swapped.
Current behavior before PR:
The Discount Amount and Percentage are mixed up.
Desired behavior after PR is merged:
The Discount Amount data should appear under the "Discount Amount" table header, and the Discount Percentage data should appear under the "Discount Percentage" header.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes Chilean invoice reports so discount percentages and discount amounts appear under the correct column headings. It prevents customer-facing invoice confusion by ensuring discount information is clearly and accurately displayed.
Original PR description
The discount percentage and discount amount values were not in the correct positions. To fix this, I placed the Discount Amount after the Discount Percentage ("td_discount") to make the table header…
The discount percentage and discount amount values were not in the correct positions.
To fix this, I placed the Discount Amount after the Discount Percentage ("td_discount") to make the table header and table data consistent. OWP-4112378
-->
Description of the issue/feature this PR addresses:
The Discount Percentage value and the Discount Amount value are not in the correct positions. The Discount Amount was placed after the unit price ("td_priceunit"), and its value was displayed after the Discount Percentage ("td_discount"). As a result, the values were swapped.
Current behavior before PR:
The Discount Amount and Percentage are mixed up.
Desired behavior after PR is merged:
The Discount Amount data should appear under the "Discount Amount" table header, and the Discount Percentage data should appear under the "Discount Percentage" header.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEmployee names that are too long were being cut off in the appraisal form view. This fix extends the employee name field to use the full available width, ensuring all employee names display completely regardless of length.
Original PR description
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637
Employee names that are too long were being cut off in the appraisal form view. This fix extends the employee name field to use the full available width, ensuring that all employee names display completely without being cropped.
Original PR description
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637
Code cleanup and technical improvements
This update moves a technical error handler (TaxClosingNonPostedDependingMovesError) from the account_reports module to the core account module. This change improves the system's ability to handle batch move confirmations by ensuring the error can be properly caught in both locations where it's now needed.
Original PR description
We need TaxClosingNonPostedDependingMovesError inside account because it is now also used there to catch it when confirming batch of moves.
Miscellaneous changes
A mail activity template in the hr modules has the summary "Compute out Delais" which doesn't mean anything in english. This commit replaces that with something more meaningful. task-4088643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176011
Original PR description
A mail activity template in the hr modules has the summary "Compute out Delais" which doesn't mean anything in english. This commit replaces that with something more meaningful. task-4088643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176011
This is no longer necessary with the introduction of: https://github.com/odoo/odoo/pull/144652 Forward-Port-Of: odoo/odoo#145284
Original PR description
This is no longer necessary with the introduction of: https://github.com/odoo/odoo/pull/144652 Forward-Port-Of: odoo/odoo#145284
Issue ----- 1. Create a short meeting (e.g. 5 minutes), view it in the Calendar week view. 2. The text of the meeting is not visible. Cause ----- Before the refactor ed9a9d024adf9749ed5844ec3af35a0dae910828, the timeGridEventMinHeight had a value of 15, which allows short events to have a larger height when displayed. https://github.com/odoo/odoo/blob/ebce7719b624136da2b26a73acf8930538c7a38c/addons/web/static/lib/fullcalendar/timegrid/main.js#L806 , view it in the Calendar week view. 2. The text of the meeting is not visible. Cause ----- Before the refactor ed9a9d024adf9749ed5844ec3af35a0dae910828, the timeGridEventMinHeight had a value of 15, which allows short events to have a larger height when displayed. https://github.com/odoo/odoo/blob/ebce7719b624136da2b26a73acf8930538c7a38c/addons/web/static/lib/fullcalendar/timegrid/main.js#L806  opw-4116031 Forward-Port-Of: odoo/odoo#178804
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to "[CONS_0002] Simple Pen"  3. Start a new POS session with the "Shop" POS. 4. Add two Whiteboard Pens, and claim the reward. 5. Pay for the order with bank payment, and start a new order. 6. Start a refund
Original PR description
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to…
Steps to reproduce (from empty runbot): 1. Install pos_loyalty 2. Edit the existing active program named "Loyalty Program" 2a. Set "Program Type" to "Buy X Get Y" 2b. Change the existing reward to "[CONS_0002] Simple Pen"  3. Start a new POS session with the "Shop" POS. 4. Add two Whiteboard Pens, and claim the reward. 5. Pay for the order with bank payment, and start a new order. 6. Start a refund of the last order, refund the 2 Whiteboard Pens and the 1 Simple Pen.  7. Continue the refund, and back at the main POS screen, now add two more Whiteboard Pens. 8. Notice that no reward is claimable 8a. It becomes claimable if you add two more Whiteboard Pens, for a total of 4.  Before this commit, `pointsForPrograms` would calculate based on every order line present in the POS. However, this could lead to situations where lines that shouldn't be counted do get counted. For instance, a refund line should not be counted, as it would add a negative amount to the total amount. After this commit, only non refund lines are used in `pointsForPrograms`, which are defined as lines that do not have a `refunded_orderline_id` set. opw-4080144 Forward-Port-Of: odoo/odoo#177312
This PR contains several fixes involving the "select all" feature in list view. Task~4150362 Forward-Port-Of: odoo/odoo#178772
Original PR description
This PR contains several fixes involving the "select all" feature in list view. Task~4150362 Forward-Port-Of: odoo/odoo#178772
It is necessary to wrap the tab names in _lt to make them translatable into the various languages offered by Odoo. Before these changes, the tab names are always in English. After these changes, when translations are added to the terms, they will appear translated into the selected language. cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177724
Original PR description
It is necessary to wrap the tab names in _lt to make them translatable into the various languages offered by Odoo. Before these changes, the tab names are always in English. After these changes, when translations are added to the terms, they will appear translated into the selected language. cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177724
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we ca
Original PR description
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records accurately. opw-4001226 enterprise pr : https://github.com/odoo/enterprise/pull/66388 Forward-Port-Of: odoo/odoo#173667
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list does not convert it to list. 4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss
Original PR description
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of…
Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list does not convert it to list. 4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss of the other content. 5. Copy/pasting one list over another bullets does not get transformed. 6. When copying a checklist from Google Docs, the check options are pasted as images. Desired behavior after PR is merged: 1. When we attempt to paste an H1 element onto a P element, the H1 element will remain as an H1 element. 2. When pasting from GDocs, nested UL or OL are contained within an LI element with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list gets converted to list. 4. Pasting content with a list and other tags should no longer result in the loss of content. 5. Copy/pasting one list over another bullets get transformed. 6. Check options copied as image from Google Docs will no longer be pasted as images; instead the images should be removed and class `o_checklist` should be add to the closest list. task-2956048 Co-authored-by: Deependra Solanki <deso@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115019
Currently, an error occurs when creating foreign taxes for 'Austria'. Steps to produce: - Installing the 'account' module. - Go to Invoicing / Configuration / Accounting / Fiscal Positions. - Create a Fiscal Position, Set the Country as 'Austria', and enter an 'FR23334175221'(For example) as 'Foreign Tax ID'. - And Create the taxes for this country. Stack Trace: ``` KeyError: 'children_tax_ids' File "odoo/http.py", line 2374, in __call__ response = request._serve_db()
Original PR description
Currently, an error occurs when creating foreign taxes for 'Austria'. Steps to produce: - Installing the 'account' module. - Go to Invoicing / Configuration / Accounting / Fiscal Positions. - Create…
Currently, an error occurs when creating foreign taxes for 'Austria'.
Steps to produce:
- Installing the 'account' module.
- Go to Invoicing / Configuration / Accounting / Fiscal Positions.
- Create a Fiscal Position, Set the Country as 'Austria', and enter an 'FR23334175221'(For example) as 'Foreign Tax ID'.
- And Create the taxes for this country.
Stack Trace:
```
KeyError: 'children_tax_ids'
File "odoo/http.py", line 2374, in __call__
response = request._serve_db()
File "odoo/http.py", line 1904, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1967, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1934, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2178, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 755, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/account/models/partner.py", line 289, in action_create_foreign_taxes
self.env["account.chart.template"]._instantiate_foreign_taxes(self.country_id, self.company_id)
File "addons/account/models/chart_template.py", line 929, in _instantiate_foreign_taxes
children_taxes = tax_data['children_tax_ids'].split(',')
```
An error occurs when the system tries to get a 'children_tax_ids' key from tax data at [1] while foreign tax creation, But it is not available.
link [1]: https://github.com/odoo/odoo/blob/4c79aceb3a6c08453f9ec66131e1bc525eae140c/addons/account/models/chart_template.py#L936
To resolve the issue, make small changes into tax data where 'amount_type' = 'percent' instead of 'amount_type' ='group'.
Sentry-5730875398
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#178058**Current behavior before PR:** - Pressing Enter after selecting all columns in a row would break the table format. **Desired behavior after PR is merged:** - Now, when the Enter key is pressed, all the contents of the anchor `<td>` will be removed first, and then the Enter process within that `<td>` will be executed. task-3557503 Forward-Port-Of: odoo/odoo#139312
Original PR description
**Current behavior before PR:** - Pressing Enter after selecting all columns in a row would break the table format. **Desired behavior after PR is merged:** - Now, when the Enter key is pressed, all the contents of the anchor `<td>` will be removed first, and then the Enter process within that `<td>` will be executed. task-3557503 Forward-Port-Of: odoo/odoo#139312
### Steps to reproduce: - Enable workorders in the settings - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes - Create and confirm an MO for 5 units of P - Set a producing quantity of 2 - Validate the MO and create a back order ### Issues: On each of the operations of the MO: 1) The quantity displayed is 0 2) The expected duration is the expected duration corresponding to the full initial demand e.g. 50 minutes Note: Issues 1 is pre
Original PR description
### Steps to reproduce: - Enable workorders in the settings - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes - Create and confirm an MO for 5 units of P -…
### Steps to reproduce: - Enable workorders in the settings - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes - Create and confirm an MO for 5 units of P - Set a producing quantity of 2 - Validate the MO and create a back order ### Issues: On each of the operations of the MO: 1) The quantity displayed is 0 2) The expected duration is the expected duration corresponding to the full initial demand e.g. 50 minutes Note: Issues 1 is present even if the produced qty match the full demand of the MO. ### Cause of the issues: 1) The quantity displayed on the operations is the 'qty_remaining' independantly of the state of the MO. However, once the MO is done, this qty is set to 0 because the product have been produced. 2) The expected duration is a computed field that is not updated once the opeartion is done: https://github.com/odoo/odoo/blob/45154cfdb044aea85ad72bb36348af7b77afd844/addons/mrp/models/mrp_workorder.py#L329-L333 However, finishing the operation will change the state to 'done' before the MO is backordered and the `qty_production` updated. In addition, the `_get_duration_expected` relied solely on the qty_production rather than also relying on the actual 'qty_produced': https://github.com/odoo/odoo/blob/45154cfdb044aea85ad72bb36348af7b77afd844/addons/mrp/models/mrp_workorder.py#L786 ### Fix: 1) Since we can not show different columns for each operation depending on their state, we rely on the state of the MO to determine which qty is the most relevant: the qty_remaining or the qty_produced 2) We update the expected duration depending on the qty_produced in case it was not manually set (which can be determined by comparing its current value with the expected value before the workorder is set as done) opw-3873108 opw-4010550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171771