Wednesday, June 12, 2024
14 changes · 17.0
Resolved issues and error corrections
Odoo now records malformed XML or PDF invoice attachments as informational log entries instead of warnings or errors. This keeps administrators informed without causing automated tests or monitoring to fail for non-critical attachment issues, while users still receive upload feedback.
Original PR description
Previously, when the attempting to decode a pdf or xml file as EDI attachment, if an xml or pdf file was malformed, we would log a warning (for pdf) or error (for xml). There are tests in which we…
Previously, when the attempting to decode a pdf or xml file as EDI attachment, if an xml or pdf file was malformed, we would log a warning (for pdf) or error (for xml). There are tests in which we post messages to the chatter with an XML file with embedded PDF which is actually a generated report. These tests don't actually generate a valid PDF because wkhtmltopdf isn't available in those tests, but these tests also do not particularly care that the PDF is valid. Similarly, there are tests that post messages with xml attachments that don't contain valid xml but they also do not care that the xml in valid in those flows. The linked enterprise PR adds an override of _message_post that will attempt to decode posted attachments so that it can take some action based on their contents. While this works perfectly fine and doesn't break any behaviour, as the decoding methods will simply return an empty list when the attachments are malformed, because they log warnings or errors, it causes tests/runbot to fail. The information that an invalid xml or pdf was uploaded is not particularly useful or urgent information for the server admin, and users already get a notification when uploading a malformed file. As such, this commit changes these warning/exception logs to simple info logs. This means this information remains available but isn't given disporoportionate importance in the logs, and doesn't cause tests that work perfecly fine to fail. task-3731034
Accounting XML imports now add a chatter note when an import fails, helping users see that something went wrong and where to find details. This restores helpful feedback that can reduce confusion and unnecessary support requests.
Original PR description
Before c02d8b177f04d6a7f9311d8cb621bb5fe02e70e6, an error occuring during the import was logged in the chatter. This commit restores this behaviour, as it is highly helpful to have the error message (it could probably avoid customers to open tickets in some cases). Ticket link: https://www.odoo.com/web#model=project.task&id=3874857 opw-3874857
Creating or discarding a new journal from a vendor payment could previously trigger an error and interrupt the user. The payment flow now falls back to the default company when no journal is selected, keeping payment entry stable.
Original PR description
This traceback arises when the user tries to create a new journal from the payment. To reproduce this issue: 1) Install `accounting` 2) Create a new payment from `Accounting/vendors/payments` 3) save…
This traceback arises when the user tries to create a new journal from the payment.
To reproduce this issue:
1) Install `accounting`
2) Create a new payment from `Accounting/vendors/payments`
3) save the record and now remove the `journal` or make the `journal` field empty
5) A traceback arises.
Error:-
```
KeyError: ('res.company', <function Company.__accessible_branches at 0x7fabdfc69c60>, (1,), False, 2)
File "odoo/tools/cache.py", line 99, in lookup
r = d[key]
File "<decorator-gen-8>", line 2, in __getitem__
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5941, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.company()
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, 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 1824, 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 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, 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 "addons/web/models/models.py", line 1074, in onchange
todo = [
File "addons/web/models/models.py", line 1077, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1190, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6664, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "addons/mail/models/mail_thread.py", line 416, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/account/models/account_payment.py", line 369, in _compute_reconciliation_status
liquidity_lines, counterpart_lines, writeoff_lines = pay._seek_for_lines()
File "addons/account/models/account_payment.py", line 192, in _seek_for_lines
if line.account_id in self._get_valid_liquidity_accounts():
File "addons/account/models/account_payment.py", line 211, in _get_valid_liquidity_accounts
accessible_branches = journal_comp.with_company(journal_comp)._accessible_branches()
File "odoo/addons/base/models/res_company.py", line 420, in _accessible_branches
return self.browse(self.__accessible_branches())
File "<decorator-gen-107>", line 2, in __accessible_branches
File "odoo/tools/cache.py", line 104, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/res_company.py", line 402, in __accessible_branches
self.ensure_one()
File "odoo/models.py", line 5944, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
When the user removes the journal, the company ID is taken from the journal, which leads to a traceback from the line below.
https://github.com/odoo/odoo/blob/53d6d795ddf6cc9e470bfeb48bb31bc728acedbe/addons/account/models/account_payment.py#L207-L208
After applying this commit, resolve this issue by taking the default company,
when there is no journal.
sentry-5054332731Fixed an issue in the Documents module where the delete button (X) for tags was hidden when tag names were very long. The fix adjusts how the tag table is displayed so that long tag names don't cause the table to expand and hide the delete button, improving usability when working with documents that have lengthy tags.
Original PR description
By default, tables automatically adjust their width to accommodate the content of their cells, That causes table row to grow in size and make "X" button invisible. Here I'm constraining table layout so it doesn't matter how long the content of columns is [Reproduce] - Install documents - Add tag with a very long name - Go to all Documents, Select a document, Add the tag on a doc - BUG: "X" button is not visible* opw-3937326 BEFORE / AFTER https://github.com/odoo/enterprise/assets/33809926/5f2fc861-cd68-4478-8b8b-b8843b7d4944 Forward-Port-Of: odoo/enterprise#63279
Miscellaneous changes
Since Commit 4c58d82c7e582c11eb967b6ed7c918a6da3ebd23 refactored `test_delivery_ui`, the check for the `payment_custom` module was moved to individual tests, however, the new `setUpClass` function now uses code that requires `payment_custom` and fails when the server tries to run tests. Solution: Move the initialization of `transfer_provider` to the individual tests instead of within the setup function. opw-3957075 Forward-Port-Of: odoo/odoo#168792
Original PR description
Since Commit 4c58d82c7e582c11eb967b6ed7c918a6da3ebd23 refactored `test_delivery_ui`, the check for the `payment_custom` module was moved to individual tests, however, the new `setUpClass` function now uses code that requires `payment_custom` and fails when the server tries to run tests. Solution: Move the initialization of `transfer_provider` to the individual tests instead of within the setup function. opw-3957075 Forward-Port-Of: odoo/odoo#168792
Add CLA for adriana saiz --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167398 Forward-Port-Of: odoo/odoo#160303
Original PR description
Add CLA for adriana saiz --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167398 Forward-Port-Of: odoo/odoo#160303
The project sharing search view is inheriting the wrong base search view (instead of inheriting `view_task_search_form_project_base`, it should be inheriting `view_task_search_form_base`), which causes some fields and filters to be visible in project sharing when they shouldn't. This commit makes those fields and filters invisible for portal users. Task-3978479 Forward-Port-Of: odoo/odoo#168523
Original PR description
The project sharing search view is inheriting the wrong base search view (instead of inheriting `view_task_search_form_project_base`, it should be inheriting `view_task_search_form_base`), which causes some fields and filters to be visible in project sharing when they shouldn't. This commit makes those fields and filters invisible for portal users. Task-3978479 Forward-Port-Of: odoo/odoo#168523
This traceback occurs when the user tries to update a `fiscal position` record by giving either only `from` or `to` value to `zip` range. To reproduce this issue:- 1) Install `Accounting` 2) Create a new `fiscal position` from `Accounting/Configuration` without `Detect Automatically` 3) Now update the record by enabling `Detect Automatically` 4) Select any country and give only the `from` value for `Zip Range` 5) Save the record Error:- ``` TypeError: object of type 'bool'
Original PR description
This traceback occurs when the user tries to update a `fiscal position` record by giving either only `from` or `to` value to `zip` range. To reproduce this issue:- 1) Install `Accounting` 2) Create a…
This traceback occurs when the user tries to update a `fiscal position` record by giving either only `from` or `to` value to `zip` range. To reproduce this issue:- 1) Install `Accounting` 2) Create a new `fiscal position` from `Accounting/Configuration` without `Detect Automatically` 3) Now update the record by enabling `Detect Automatically` 4) Select any country and give only the `from` value for `Zip Range` 5) Save the record Error:- ``` TypeError: object of type 'bool' has no len() ``` When the user updates the `fiscal position` with only `from or to` It triggers `_convert_zip_values` method with one from both. This leads to traceback, as `max()` is used between from and to. https://github.com/odoo/odoo/blob/eb04acf011838d9c8206bedd1908f7a991eb77e3/addons/account/models/partner.py#L143-L144 After applying this commit will resolve this issue by making the code more robust with an additional check. sentry-5284424770 Forward-Port-Of: odoo/odoo#168636 Forward-Port-Of: odoo/odoo#165712
opw-3863382 Forward-Port-Of: odoo/odoo#168755
Original PR description
opw-3863382 Forward-Port-Of: odoo/odoo#168755
Steps to reproduce: - Install "Time Off" and `l10n_be` - "Time Off" -> "Reporting" -> "by Type" - Unselect the company with the time off Issues: All the time off will be shown, company selection will not be taken into account. This is due to a missing security rules. opw-3954393 Forward-Port-Of: odoo/odoo#168516
Original PR description
Steps to reproduce: - Install "Time Off" and `l10n_be` - "Time Off" -> "Reporting" -> "by Type" - Unselect the company with the time off Issues: All the time off will be shown, company selection will not be taken into account. This is due to a missing security rules. opw-3954393 Forward-Port-Of: odoo/odoo#168516
This traceback arises when the user tries to remove the Batch Limit value and test the imported file. To reproduce this issue: 1) Import a file with large data in any module 2) You see the Batch limit at the left side pannel 3) Remove the default "Batch Limit" value 4) Test the file 5) A traceback will encountered Error:- ``` TypeError: '<' not supported between instances of 'int' and 'str' ``` when the user removes the default batch limit its value will be an empty string.
Original PR description
This traceback arises when the user tries to remove the Batch Limit value and test the imported file. To reproduce this issue: 1) Import a file with large data in any module 2) You see the Batch…
This traceback arises when the user tries to remove the Batch Limit value and test the imported file.
To reproduce this issue:
1) Import a file with large data in any module
2) You see the Batch limit at the left side pannel
3) Remove the default "Batch Limit" value
4) Test the file
5) A traceback will encountered
Error:-
```
TypeError: '<' not supported between instances of 'int' and 'str'
```
when the user removes the default batch limit its value will be an empty string.
You can see in [1] that parseFloat('') is "NaN" so it directly assigns the limit as the value which is an empty string.
[1]
https://github.com/odoo/odoo/blob/2c40a55232fb501dd70b64f7ddbdc4244f365139/addons/base_import/static/src/import_data_sidepanel/import_data_sidepanel.js#L34-L36
which leads to a traceback when a comparison is done between int and str.
https://github.com/odoo/odoo/blob/106c343027e3bab1c94c414f30e914cf673cceec/odoo/models.py#L1318-L1319
After applying this commit will resolve the issue of getting an int value instead of a str.
sentry-5298904064
Forward-Port-Of: odoo/odoo#167323**Steps to reproduce:** - Install Sales & Accounting - Create a second company with a different currency (e.g. AED) than the first one (e.g. USD) - Configure the rounding factor of the currency of the second company to 1.000000 - Configure the default company of the current user to the second company - Switch to the second company - In Accounting settings, set "Rounding Method" to "Round Globally" - Switch to the first company - Create a SO: * Customer: [any] * Order Lines: [any li
Original PR description
**Steps to reproduce:** - Install Sales & Accounting - Create a second company with a different currency (e.g. AED) than the first one (e.g. USD) - Configure the rounding factor of the currency of…
**Steps to reproduce:** - Install Sales & Accounting - Create a second company with a different currency (e.g. AED) than the first one (e.g. USD) - Configure the rounding factor of the currency of the second company to 1.000000 - Configure the default company of the current user to the second company - Switch to the second company - In Accounting settings, set "Rounding Method" to "Round Globally" - Switch to the first company - Create a SO: * Customer: [any] * Order Lines: [any line with a tax] - Save the SO - Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part - Save the SO **Issue:** In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details. **Cause:** After save, the taxes are recomputed on the SO lines after a "flush_all" triggered by "call_kw" method. The computed values are rounded depending on the rounding factor of the currency of the current company (i.e. self.env.company). However, "allowed_company_ids" being absent in the context, the current company cannot be computed correctly and a fallback is made on the default company of the current user. Unfortunately, the default company of the current user is different than the real current company, leading to a different currency having a different rounding factor. In this case, the tax values are rounded to the unity, which is not correct. **Solution:** Specify the company configured on the SO line when computing its taxes. opw-3814058 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168811 Forward-Port-Of: odoo/odoo#168723
This commit implements two changes to prevent search engines from crawling and indexing content on websites marked as neutralized: - Robots.txt update: The robots.txt field in the website database is updated with a rule disallowing all crawling (User-agent: * \n Disallow: /). - Robots meta tag injection: An XPath expression is used to inject a robots meta tag with content="noindex, nofollow" within the web.neutralize_banner view's <head> section. These combined changes ensure a strong sig
Original PR description
This commit implements two changes to prevent search engines from crawling and indexing content on websites marked as neutralized: - Robots.txt update: The robots.txt field in the website database is updated with a rule disallowing all crawling (User-agent: * \n Disallow: /). - Robots meta tag injection: An XPath expression is used to inject a robots meta tag with content="noindex, nofollow" within the web.neutralize_banner view's <head> section. These combined changes ensure a strong signal to search engines to not index neutralized databases. task-3895772 Forward-Port-Of: odoo/odoo#167963
Steps to reproduce ================== - Install mrp - Enable debug mode - Go to products - Open the "Acoustics Bloc Screens" form - Click on the "Forecasted" smart button - Click on the debug icon > "View access rights" A traceback occurs when evaluating the domain Cause of the issue ================== ir.actions.client is supposed to be a string but is an id in this case. `ir.model.search([["model", "=", action.res_model]])` returns nothing. [0] --- [0]: https://gith
Original PR description
Steps to reproduce ================== - Install mrp - Enable debug mode - Go to products - Open the "Acoustics Bloc Screens" form - Click on the "Forecasted" smart button - Click on the debug icon > "View access rights" A traceback occurs when evaluating the domain Cause of the issue ================== ir.actions.client is supposed to be a string but is an id in this case. `ir.model.search([["model", "=", action.res_model]])` returns nothing. [0] --- [0]: https://github.com/odoo/odoo/blob/c07181b20bf4f06b783136ffdb3b7a304be6b136/addons/web/static/src/webclient/actions/debug_items.js#L147 opw-3955762 Forward-Port-Of: odoo/odoo#168498