Tuesday, October 1, 2024
18 changes · 18.0
Resolved issues and error corrections
Website editors can now drag blocks near the bottom of a long page and have the page scroll as expected. This restores smoother page editing when building longer website pages.
Original PR description
Steps to reproduce the bug: - In website edit mode. - Add enough blocks to the page so that a vertical scrollbar appears. - Drag a block and move it to the bottom of the page to scroll down. - Bug:…
Steps to reproduce the bug: - In website edit mode. - Add enough blocks to the page so that a vertical scrollbar appears. - Drag a block and move it to the bottom of the page to scroll down. - Bug: The page does not scroll. This bug was introduced because the scroll element is now the `<html>` instead of the "#wrapwrap" element (Since this commit [1]). The issue arises because "getBoundingClientRect()" gives the distance from the top of the element to the viewport, excluding the scroll position, while the `<html>` element accounts for scrollTop to define its Y position. In this commit, we also fixed the "dragStart" function, which didn't return the HTML element as the scroll element when it was the drag and drop container. The issue is that the "closestScrollableY" function don't consider an element with "overflow: visible" as scrollable. At first, we tried to modify "closestScrollableY" to consider an element with "overflow: visible" as scrollable, but this caused several errors in the "drag and drop" QUnit tests and we couldn't find the cause. This needs further investigation. To fix the issue, we updated the "dragStart" function to check if the "drag and drop" container is the "ownerDocument.scrollingElement". If it is, we use that element as the scrollable element for the "drag and drop". [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e task-4190506
Opening the Dashboard app no longer triggers an access error for newly created non-admin users. This ensures users without administrator rights can access dashboards as expected in a fresh database.
Original PR description
Steps to reproduce - install a fresh database, without any demo data - create a new user which shouldn't have admin rights - connect as this new user - open the Dashboard app => Access Error The `ir.model` cannot be read by anyone, except admin users. Task: 4224689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resetting a payment to draft now also resets its linked journal entry, and deleting a payment removes the linked journal entry too. This prevents orphaned accounting entries and keeps payment records synchronized with the accounting ledger.
Original PR description
Reset to Draft and Payment deletion should impact the linked Journal Entry as well, or we'll just leave a bunch of created entries that will be lost in Accounting. Reset it to draft => Reset to Draft the Journal entry as well, no error message. Delete the payment => Delete the Journal entry We also revert the suppression of the synchronisation of the payment to move. And in the _get_trigger_fields_to_synchronize we remove is_internal_transfer since the field is no longer there. (https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892) task: https://github.com/odoo-dev/odoo/commit/4215217583c566cc5188d71dcbbd7b1cd860b3ae --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes issues in the website page properties dialog so users can clone or delete pages successfully. It also makes redirect options appear immediately when editing a page URL, reducing confusion during website page setup.
Original PR description
Moved out of https://github.com/odoo/odoo/pull/181224
Purchase quotation accept and decline actions now consistently use the same secure portal flow, whether users click from an email or the portal sidebar. This prevents sidebar actions from failing and makes the confirmation feedback clearer for users.
Original PR description
There is two ways of confirming/declining a reception mail through the portal. Either by clicking on the sidebar or clicking on the button in the mail. While it works correctly when going through the mail link, as it goes through the controller that checks the access rights before preparing the order if the access token is good. However this didn't happen when using the buttons from the portal sidebar, as we don't go through the controller in this case. Unified both ways to always go to the controller. Also changed the feedback for accepted/declined quotations, so that's more visible for the user. Task-4207380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sale orders created from completed repair orders now carry over the actual quantity completed in the repair. This ensures customers and staff see accurate delivered quantities when confirming those sale orders.
Original PR description
Steps to reproduce: - Create a repair order. - Add a stock move to it with any quantity. - Confirm, start and end the repair order. Make sure that quantity done is positive. - Generate a sale order from the repair order. - Confirm the sale order. Expected result: `qty_delivered` of the generated sale order line should be the same as the quantity done of the move in the repair order. Current result: `qty_delivered` is zero. 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 ensures tax totals stay accurate when a currency's rounding settings have been changed. It also corrects price-included reverse charge tax calculations, reducing small invoice discrepancies that could affect accounting totals.
Original PR description
The test was computing: 20000 * 2.82 / 1.1726 = 48098.24 48098.24 * 0.21 ~= 10100.63 When splitting to tax repartition lines, we get 10100.65 because of the rounding set on the currency. The error is computed as 10100.63 - 10100.65 = -0.02 so 2 x -0.01 to distribute. Before this commit, we had the time to fix only one rounding error so: 10100.65 - 0.01 = 10100.64 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how tax totals appear on invoice PDFs and corrects related tax total handling for Hungary. It also makes global rounding the default for Mexican localization, helping invoices follow local expectations more consistently.
Original PR description
[FIX] account: Fix wrong condition to display tax_totals on PDF [IMP] l10n_mx: round_globally in mexico by default Now the round globally is fully managed, let's enforce it in Mexico. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Using the Manufacture button from a Bill of Materials overview now creates a manufacturing order without incorrectly moving serial-numbered products into an in-progress state. This keeps the workflow consistent with creating a manufacturing order manually and then selecting the same Bill of Materials.
Original PR description
The Manufacture button added in the BoM Overview prepares a new manufacturing order using the bom. However for serial products this has a drawback of changing the state to 'in progress'. This is not the case when creating a new manufacturing order and then selecting the same bom. The origin is within '_onchange_producing / _set_qty_producing' and the way the record is initialized: - from 'Manufacturing orders / New' all fields have their default values - from 'BoM Overview / Manufacture' the bom_id and related fields are set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how expected working hours are recalculated when overtime records are updated. It helps keep attendance and overtime figures accurate for employees and payroll-related reviews.
Original PR description
Expected hours were not recomputed properly on the _update_overtime method
Copying previous weeks in Planning now handles open shifts without errors, including shifts spanning multiple days. Shifts outside an employee's normal schedule are copied as open shifts unless the employee is fully flexible, making schedule duplication more predictable.
Original PR description
Before this commit, when the user copy shifts of the previous weeks and in that previous week he has an open shift, he will have a traceback will be raised because we check if the resource of the shift is flexible or not to be able to correctly compute the allocated hours of the splits generated with the split to split. The problem is an open shift has no resource so it is no needed to check if the resource is flexible. This commit checks if the shift is an open shift or not before checking if the resource is flexible or not. This commit also fixes another when we try to copy previous an open shift planned during 2 days, the allocate hours is computed based on the company schedule instead of the real time span between the date end and date start as we do in the `_compute_allocated_hours` method. task-4207839
This update corrects tax total display on Ecuador withholding PDFs and stabilizes Mexico electronic invoicing tests so they are no longer affected by date changes or recent merges. It also makes global rounding the default for Mexico, improving consistency with local invoicing requirements.
Original PR description
[FIX] l10n_ec_edi: Fix wrong condition to display tax totals in PDF [FIX] l10n_mx_edi: Fix broken test after merge: The fix has been added by https://github.com/odoo/enterprise/commit/d5da2b62263f85fbce0f2548085c066cbbf10371 At the same time, this commit has been merged: https://github.com/odoo/enterprise/commit/00cc171c6e122118af72d84bb26ff083c086dff4 Now those tests are skipped on runbot. Let's fix them. [FIX] l10n_mx_edi: Remove date related stuff from MX test files Now we move to october, the test is failing on runbot... [IMP] l10n_mx: round_globally in mexico by default Now the round globally is fully managed, let's enforce it in Mexico.
Fixes issues in Odoo Studio where editing Kanban cards after adding a card menu could target the wrong part of the card. It also places ribbon elements correctly so card layouts remain visually intact, making customization safer and more predictable for users.
Original PR description
Before this commit there were two issues: - add a menu on a card - try to remove or add a field elsewhere in the card => the xpath of the last operation was always wrong. This was because the normlalise function got confused and refused to actually add the menu template before the card template. - web_ribbon was appended to the card => this cause the style to be broken. Albeit the ribbon widget makes sense at the top of the card template, it should not break the style in those proportions. So, a small fix is done in studio to add the ribbon at the top of the card, but we strongly recommend a fix that will enable to put it anywhere as a direct child of the relevant view node. task-4207793
The accounting reports quarter filter now calculates periods based on actual calendar quarters instead of counting three-month ranges from the current date. This helps users see accurate quarterly report data and reduces the risk of misleading financial analysis.
Original PR description
The quarter filter was not properly calculating the quarters. It was taking periods of 3 months not based on quarter but based on the current date. The months are now properly calculated based on the quarter.
Portal users can now search or group helpdesk tickets by related sales orders without running into an access rights error. This removes an unnecessary restriction so customers have a smoother self-service support experience.
Original PR description
Prior to the fix, portal users would get an access rights error whenever they would group or search sale order. That was because the ``sale_order_id`` field was only given access to sale and accounting users. That was the case since the helpdesk app was first created. All users, including portal, have access to the ``sale_order_line`` field, thus the restriction on the ``sale_order_id`` field are not anymore necessary. We "fix" the access right error by basically removing the group restriction on the ``sale_order_id`` field in the helpdesk.ticket model. task-4207628
This update fixes issues in sales commissions where switching a commission plan from achievement-based to target-based could behave incorrectly after returning it to draft. It also ensures subscription sales based on recurring revenue are reflected in the user’s commission view, improving confidence in commission tracking.
Original PR description
- When you select based on achievement save, then draft again and change it into based on achievement to based on targets - When I try commission plan based on MRR and try to sell sub, I don't see my commission in "my commission"
This update fixes issues in Documents where users could hit an access error when creating shortcuts to shared files located in folders they cannot edit. It also improves how the app opens to the correct folder or section at startup, making navigation more reliable.
Original PR description
In this PR, we fix the creation of shortcuts in My drive when the target are in non-writable folders. In a second commit, we fix and test the initial data folder_id passed to open the side panel on the right folder or section at the app's initialization. Task-4216195
Duplicating a financial report now creates a clearer copy with “(copy)” added to the name and includes the related budget lines. This helps users create new financial budgets from existing reports without manually rebuilding the structure.
Original PR description
Enable the copy of a financial report. Right now, when duplicating a financial report (or several at the same time), only the name is copied (same name, not even a "(copy)" after. We want to improve it by adding this "(copy)" in the title, and also copy the budget lines. This will enable a user to not start from scratch every time he wants to create a new financial budget. task-4207202