Daily updates from Odoo
Friday, July 26, 2024
7 changes · 17.0
Enhancements to existing features
eBay changed how they format product URLs in their system, which was breaking the ability to match products to the correct variants in Odoo. This update improves the matching logic to handle multiple URL formats and adds a backup method to fetch the correct variant information directly from eBay when needed. This ensures orders from eBay continue to be processed correctly despite these external changes.
Original PR description
eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we try a different way to match the url, and fallback on another eBay call to get the expected variant. opw-3934127 Forward-Port-Of: odoo/enterprise#66924
Resolved issues and error corrections
Marketing automation users were unable to set the Unique Field when configuring campaigns due to insufficient access permissions. This fix grants the necessary read access to field definitions, allowing users to properly configure their marketing campaigns without encountering access errors.
Original PR description
Current behaviour: --- Connected as Marc Demo, cannot set the Unique Field of any marketing campaign Steps to reproduce: --- 1. Go to Settings > Users > Marc Demo 2. At Marketing Automation, set User 3. Connect as Marc Demo 4. Go to Marketing Automation 5. Open any campaign 6. Try to set the Unique Field 7. Access Error Cause of the issue: --- unique_field_id is comodel of ir.model.fields Fix: --- Give group_marketing_automation_user the right to read ir.model.fields opw-4001919 Forward-Port-Of: odoo/enterprise#66690
This fix corrects how the system handles duplicate invoices in Peru's electronic invoicing system (SUNAT). Previously, when an invoice was rejected as a duplicate, the system would incorrectly mark it as successfully sent by retrieving an existing confirmation. Now, users will properly receive a rejection notification, prompting them to fix the invoice numbering issue instead of believing it was sent successfully.
Original PR description
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT. To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT. opw-3900393 Forward-Port-Of: odoo/enterprise#65520
This fix resolves a crash that occurred when users tried to create an asset from journal items belonging to different companies. Previously, the system would fail with an error when attempting this operation. Now users can safely create assets from multiple journal items regardless of which company they belong to.
Original PR description
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an…
When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.
Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset
Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
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 42, in call_button
action = 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 "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
'default_company_id': self.company_id.id,
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.
sentry-5613448397
Forward-Port-Of: odoo/enterprise#67301
Forward-Port-Of: odoo/enterprise#66806This fix resolves an issue where sale orders with special characters in their sequence numbers (like SO/2024/12/31/01) were not appearing as suggestions during bank reconciliation. Previously, the system would only match if the bank label exactly matched the sale order name, but now it properly compares both using the same formatting rules, making it easier for users to find and match the correct sale orders.
Original PR description
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them to names. With this commit, we'll compare names and tokens that are formatted the same way. opw-3964898
This update fixes how the planning gantt view displays grouped shifts by properly disabling summary rows that shouldn't be interactive. When shifts are grouped in the planning module, the system now correctly hides total rows and keeps only the main group-level rows visible, improving the visual clarity and usability of the gantt chart.
Original PR description
When shifts are group by in the planning, the open shift and total rows are not disabled. In this commit, we have disabled the total row and all rows except those at group level 0. task-3981814
This update adds missing translation files and terms to the Chile EDI point-of-sale and website sales modules. The website sales translations were also expanded to support other Latin American countries and languages, ensuring users in the region see proper localized text in their preferred language.
Original PR description
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338