Monday, July 29, 2024
9 changes
2 changes
Resolved issues and error corrections
Fixed an issue where opening certain partner links in a new browser tab could show the record the user was already viewing instead of the intended linked partner. This ensures duplicate Tax ID links and similar record links take users to the correct destination, reducing confusion and navigation errors.
Original PR description
Currently, links created with the `Many2OneField` component won't work properly if opened in a new tab. ### Steps to reproduce * create two partners with the same Tax ID * each partner should display a link to the other partner, indicating a duplicate Tax ID. * open one of those links in a new tab When the link is opened in a new tab, it displays the record you were originally viewing instead of the intended partner. opw-4050312
This update fixes several issues affecting everyday Odoo workflows, including loyalty orders, vendor bill purchase order selection, email sender handling, manufacturing work orders, and localized accounting reports. It improves reliability and compliance behavior across point of sale, purchasing, email, manufacturing, and country-specific accounting features.
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
1 change
Resolved issues and error corrections
Removing HMRC authentication credentials now affects the user selected by the administrator, not the currently logged-in user. This prevents accidental removal of another user's UK tax reporting credentials and makes multi-user credential management more reliable.
Original PR description
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do…
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do the operation on the selected user rather than the environment user. Issue: Step to reproduce: - install`l10n_uk_reports` - create 2 user or more - for each user, fill their hmrc token values - select a user different from the current environment user - remove their credential with the button "Remove Authentication Credentials" Current behavior: - The selected user's credential is not removed, but the environment user one got removed Expected behavior: - the selected user's credential should be the one that is removed, and the environment user should not be removed. Why it happens: - In `_clean_tokens` function, it clears the credential of the environment user by default. Solution: - change the signature of _clean_tokens function to have `user` required argument and clean that user's token instead of `env.user` opw-4041604
6 changes
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