Saturday, August 31, 2024
6 changes · 17.0
Resolved issues and error corrections
This fix lets Odoo safely close or remove a website widget even if it has not finished loading. It reduces the chance of unexpected page errors in edge cases, improving reliability without changing normal user workflows.
Original PR description
When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets. No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues. [1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a Found while working on task-3930204
This update prevents upgrade failures for several country-specific accounting localizations by clearing outdated carryover settings on existing tax report records. Businesses using these localizations can update their databases more reliably without manual cleanup.
Original PR description
Reproduce: 1) Make a database before this PR: #176489 2) change to current version. 3) start database with `-u all` This will fail _check_carryover_target constrain when api.constrains checks for the data, carryover_target was not nullified because it was not in the group of values to be updated . So nullify carryover_target using eval="False" for exisiting records that were changed in #176489. 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
The Malta localization tax report now displays the country name correctly as "Malta" instead of the typo "Matla". This keeps report labels professional and consistent for users working with Maltese accounting reports.
Original PR description
Problem: The account tax report was displaying "Matla" instead of "Malta" Purpose: Fix the type to stay consistent with naming conventions opw-4134520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bills created from email aliases now keep common document attachments such as Word and text files. This prevents supporting documents from being lost when suppliers email bills, helping accounting teams review and process invoices more reliably.
Original PR description
Set up email alias for Vendor Bill journal Send email with docx attachment to alias Bill is created Issue: No attachment is present This commit will extend 827b536942a67e91d4283ebd2bf50db5141f0abe to allow more formats opw-4092311 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
This fix stops users from quickly creating field service tasks from timesheets when no customer is assigned. It helps prevent invalid task records and avoids errors caused by missing required customer information.
Original PR description
This commit's purpose is to prevent the creation of a task with quick create with the 'withTaskHour' widget if the project is an fsm one. This is done to prevent the creation of fsm task without a partner set (the field is required).
This update corrects a test that verifies portal users can create and edit knowledge articles. The test was passing incorrectly because it wasn't properly checking access permissions. The fix ensures the test now correctly validates that portal users have the right permissions to perform these actions.
Original PR description
Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.