Daily updates from Odoo
Monday, July 29, 2024
6 changes · 17.0
Resolved issues and error corrections
Fixed an issue where VAT Record Books exported from Spanish tax reports were displaying numbers as text instead of actual numbers. This fix allows users to perform calculations and operations directly on the exported spreadsheets, improving usability and reducing manual data conversion work.
Original PR description
With an ES Company Open Tax Report Select Report > Generic Tax Report Export "VAT Record Books" Issue: Numbers are exported as string, while the system should export as number, to let users execute operations on the resulting workbook opw-4029478
Users can now successfully move documents to parent workspaces. Previously, a technical issue prevented this action from working correctly. This fix resolves the underlying problem so users have full flexibility in organizing their documents across workspace hierarchies.
Original PR description
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
This fix resolves a problem where users couldn't navigate away from locked or read-only articles. When switching between articles, the system was attempting to rename read-only articles, which failed and prevented users from leaving. The fix prevents these unnecessary rename attempts for articles users don't have permission to edit.
Original PR description
This commit fixes an issue with locked/readonly empty articles. If a user opens an article which is locked/readonly for them, when switching articles the browser will try to update the article's name. This operation is of course not possible, but this leads to the user not able to leave said article. This is caused by the update method on the record which sets it as dirty so that it can be saved when possible. In order to fix, this when the user has no write access on the article or if it is locked, we return early so that the record doesn't set itself as dirty. task-4047722
Fixed a bug in the Follow-up Reports feature where the Save button would not work after changing the "Exclude from Follow-up" field. The field was automatically saving changes, leaving nothing for the Save button to process. This fix disables auto-save for this field, restoring normal save functionality and matching the behavior in other Odoo versions.
Original PR description
This bug is only present in v17.0.
### Steps to reproduce:
- Go in Accounting > Customers > Follow-up Reports
- Click on a customer
- Changing the "Exclude from Follow-up" field of a line
- The save button does not work anymore
### Cause:
The field "Exclude from Follow-up" is in autosave by default. So it is saved every time it is changed. When clicking on the save button there is nothing to save so nothing happens and the button stays there.
### Solution:
Add `options={'autosave': False}` in the field to prevent it from saving. This will create the same behavior as in all other versions.
This bug does not appear in 17.1 because a new condition called canSaveOnUpdate is added: https://github.com/odoo/odoo/blob/2db71d627fd2c9fc97d573df7993a953753bb8bd/addons/web/static/src/model/relational_model/record.js#L256
opw-4055350The GST Return Period filter has been updated to display both the current and previous month or quarter by default, instead of only showing the previous period. This change makes it easier for users to access and work with the most relevant GST return periods without having to manually adjust filters.
Original PR description
Before this **PR**: The default filter for the GST Return Period shows the previous month or quarter. After this **PR**: The default filter for the GST Return Period shows the current as well as the previous month or quarter. **task**-4014267
This fix corrects how state information is submitted in Brazilian electronic invoices. Previously, the system was sending state names instead of state codes, which caused some states like Minas Gerais to reject invoices. Now the correct state codes are sent according to the official specification, ensuring invoices are accepted by all Brazilian states.
Original PR description
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods