Tuesday, November 5, 2024
24 changes
2 changes
Resolved issues and error corrections
Companies in countries without a dedicated accounting template will now receive the generic chart of accounts instead of being blocked by country matching rules. This helps new company setup work correctly in places such as Fiji while still allowing country-specific localizations to take precedence when available.
Original PR description
A previous fix[^1] prevents installing a wrong l10n if the country doesn't match. But it should still match if the template is not for a specific country. For instance, Fiji should instanciate the generic CoA. If a better one should be installed instead, the hook will be overridden when the module will be installed thanks to the `countries` flag of the l10n manifests. [^1]: 7f3a094a117477833b2814f0cfd3d574c6c22b53
Fixed timesheet reports so they show only tasks or subtasks that actually have recorded time. This prevents empty parent tasks from appearing and makes subtask entries easier to trace back to their origin.
Original PR description
Steps to reproduce: - Project app > New Project > New Task - On Task > Subtask tab > Add subtask > Save - On Subtask > Timesheets tab > Record a timesheet - On task > Print timesheets The report shows a line for Task with no timesheets in saas-17.2 and saas-17.4, while it is completely blank in 18.0 (Due to an extra condition added in https://github.com/odoo/odoo/pull/178397). We'd expect only tasks with recorded timesheets to be on the report, regardless of whether their parent tasks are there or not. Additionally, since subtasks can now appear without parent, the titles have been updated to make tarcking subtask origin easier. opw-4292481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
The subscription portal page now uses a clearer, more user-friendly title. This helps customers better understand where they are when viewing subscription information online.
Original PR description
Before this commit, the title on the subscription portal page wasn't clear. This commit makes the title more user-friendly and easier to understand. task:4226567
10 changes
Resolved issues and error corrections
This fixes an automated test for the Maintenance calendar by ensuring it is in the correct monthly view before moving a recurring event. The change helps prevent false test failures and supports smoother ongoing quality checks without changing user-facing functionality.
Original PR description
In this commit, we add a check step to ensure the view is Month view before to drag and drop the item or drag and drop will be directly executed ... and tour fails. 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
10 changes
Resolved issues and error corrections
This update fixes an issue where renewed subscriptions were incorrectly forecasting stock decreases. Now, the stock forecast accurately reflects only the new subscription created during the renewal process, ensuring more precise inventory management. This change improves forecast accuracy and reduces potential overstocking.
Original PR description
Steps to reproduce: - New product > Storable; Recurring; Edit 'On Hand Quantity' to 10 - New subscription > Add your product > Confirm - Create Invoice > Confirm > Back to sub - View forecast on order line > 1 reserved; 1 forecasted for next period (This is correct, the subscription is ongoing) - Renew > Confirm > View forecast - 1 reserved for original sub (OK); 2 forecasted for next period This is wrong because renewed subscriptions should no longer have recurring invoices, meaning there is no reason to forecast a stock decrease for them. i.e here it should only forecast 1 unit for the next period corresponding to our new subscription (Created by renew). Prior to 17.0 a storable product cannot also be recurring, so this issue is irrelevant there. opw-4239989
This fix prevents customers on Mexican and Chilean e-commerce sites from being blocked at order confirmation by a missing shipping method. Checkout now follows the normal delivery selection step, improving successful online order completion for affected localizations.
Original PR description
In Mexican (or Colombian) e-commerce websites, a customer may face an issue where they are unable to confirm an order because no delivery method is selected. ### Steps to reproduce - Install…
In Mexican (or Colombian) e-commerce websites, a customer may face an issue where they are unable to confirm an order because no delivery method is selected. ### Steps to reproduce - Install `l10n_mx_edi_website_sale` - Ensure the website is configured with a Mexican company - Enable 'Automatic Invoice' in website settings - As a public user, proceed through checkout and try to confirm the order The issue occurs if the user is prompted to fill in delivery information and hasn't previously provided an address. This can be consistently reproduced using a new incognito session. Upon attempting to confirm the order, the following error is shown: "No shipping method is selected." ### Cause The delivery information form (`/shop/address/submit`) normally redirects to `/shop/checkout`, where the user selects a delivery method. However, the `_get_extra_billing_info_route` hook can alter the redirect, bypassing the checkout step and causing the delivery method to remain unset. ### Fix The extra billing info flow is already handled in the checkout steps. Therefore, `_get_extra_billing_info_route` is no longer necessary. opw-4205135 opw-4222398
Users can now create link tracking records without being asked to enter a tracked URL immediately. This removes an unnecessary step during setup while still allowing the URL to be adjusted later if needed.
Original PR description
#### Purpose We should not ask users to provide a tracked URL, it's supposed to be something you change afterwards if you want an extension that looks good. #### After this PR Removed required attribute, so it will not asked user a Tracked URL on record creation. Task-4279725
Website editors can once again adjust the layout and content width of standard carousel sections. This restores useful design controls that were accidentally removed during a prior carousel redesign, helping teams fine-tune page presentation without workarounds.
Original PR description
In commit [1], the carousels have been redesigned. However, with it, the "Layout" and the "Content Width" options have been removed from some of them. They can therefore not be toggled to grid mode anymore and their container width cannot be changed, which could have been useful now that the arrows can be hidden. This commit restores these options for the `s_carousel` snippet. Note that the `s_carousel_intro` one redefined these options, which is why it has them. The other ones (i.e. `s_image_gallery`, `s_quotes_carousel` and `s_quotes_carousel_minimal`) do not need them. [1]: https://github.com/odoo/odoo/commit/3deb8050831c69ca1e32039622b322ffa38cc497#diff-934f432382bbc5c89d776f677d71ef50392d8652b2e9fa7bba3ff39475b842ae task-4263725
Brazilian webshop orders now correctly trigger Avatax tax calculation during checkout. This prevents payment-blocking errors caused by missing goods operation details, helping customers complete online purchases successfully.
Original PR description
With a BR Company Setup: Settings > Website, assign 'My Website' to BR Company Configure Avatax Brazil in General Settings > Taxes > Avatax Publish the Product "Regular Consumable Product" to be available in the website. Open the web shop as Public User Add "Regular Consumable Product" to cart Go to checkout Fill valid Brazilian customer info Pay Issue: Error will popup ``` odoo.http: Odoo could not fetch the taxes related to S00040. It is not possible identify the CFOP ``` This occurs because the sales order is missing the "Goods Operation Type" and the call to Avatax is not done opw-4239483
Users who run into an Amazon onboarding issue now see a clear error page instead of a generic internal server error. This helps them understand what went wrong and reduces confusion during setup.
Original PR description
When an onboarding error occurred, the error page failed to render and the user would see "Internal Server Error" instead of a more helpful error message. The server error had two causes: - The original onboarding error not being properly cast to a string. - The onboarding return route not passing the lang code to the QWeb context.
The label for a document project validation action was corrected so it accurately says “Remove Tag Draft” instead of implying the draft tag is added. This helps administrators identify the right action more easily and avoids confusion when reviewing server actions.
Original PR description
The issue: The child of the server action "Ask for Validation, Add Tag Draft" should be named "Remove Tag Draft." How to reproduce the issue: - Go to Server Actions: Search for “Ask for validation”. - Open “Add tag draft” child action opw-4281732
Folders in Trash no longer open or redirect when double-clicked. Users are instead informed why the action is unavailable, reducing confusion and unnecessary navigation.
Original PR description
Disable double-click action for folders in Trash to prevent unnecessary redirection and inform the user with a valid reason. Task-4231365
The spreadsheet navigation bar now uses the correct translated label for “Spreadsheet.” This improves the experience for users working in languages other than English by making the interface consistent with their selected language.
Original PR description
The term "Spreadsheet" isn't translated in the spreadsheet nav bar Task: 4300455
This fixes failing automated tests in the Hong Kong payroll accounting area after recent changes to leave allocation rules and payslip validation behavior. The change helps keep payroll accounting checks reliable without affecting normal business workflows.
Original PR description
In-use leave type allocation cannot be changed recently. Cause the unit test failed here. Also validate payslip common method is refactor into hr_payroll_account. However it is slightly different behavior than the original util method, which caused the unit test failed as well. runbot-101710
Shared appointment pages without a website now display formatted introduction text as intended. This prevents customers from seeing raw HTML code when switching appointment types, improving the booking experience.
Original PR description
Steps to reproduce: 1. Install only appointments without having a website. 2. Create or use already existing appointments and share them. 3. Go to the share URL 4. Here we will see a dropdown and the description text of the appointment, try to change the value on the dropdown and see the text. The issue arises because `replaceChildren` treats strings as plain text, so HTML in `message_intro` is displayed as text rather than rendered as HTML. To resolve this, we use DOMParser to convert the `message_intro` string into HTML elements. This allows `replaceChildren` to insert actual HTML nodes instead of plain text, preserving the intended formatting. This issue was introduce in this commit https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c. opw-4250366
This update resolves a confusing issue in the Odoo Web Studio where users weren't correctly controlling the visibility of certain fields based on group membership. Previously, toggling a group visibility setting had no effect. Now, the system properly handles 'not' group attributes, ensuring accurate field visibility and a consistent user experience.
Original PR description
Have a node that goes: ```xml <div groups="!module.some_group" /> ``` Before this commit, this case was not handled and that not-group was just ignored. This created confusion as the node, when the user was part of the group, would be invisible, the checkbox invisible would be ticked, and uniticking it had no effect. After this commit, we handle the case, with a second selector in the studio sidebar. opw-4273853
This update fixes an issue where the 'Last Evaluation' button in the employee module incorrectly displayed the current date instead of the last appraisal date. Now, the button accurately shows the date of the most recent completed appraisal or indicates an ongoing appraisal if one exists, ensuring accurate appraisal tracking.
Original PR description
The issue: When accessing the record of any employee in the employee module, we have the smart button "Last evaluation", and that button is considering the current date instead of the evaluation date of the most recent evaluation. How to reproduce the issue: -In the app employee on any employee, clic on the Request Appraisal button. -Confirm the appraisal. -Go back on the employee page. Explanation: The behavior of this smartbutton was changed in 17.2 (https://github.com/odoo/enterprise/commit/ab01d6cbb4e2add8b6736f92c036a537bea57005). After this fix for version 17.0, the behavior will be as follows: -If there is an ongoing appraisal, the smartbutton display "Ongoing Appraisal" with the number of ongoing appraisals. -If there is no ongoing appraisal, the smart button will display the date of the most recent completed appraisal, which corresponds to the date when that last appraisal was completed. opw-4180982
This update corrects a small bug in the way the system compares financial amounts within the asset management module. The previous logic incorrectly used '1' as the threshold for comparison, leading to inaccurate calculations. This fix ensures that amount comparisons are accurate, improving the reliability of asset tracking.
Original PR description
To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73159
This update fixes a bug preventing filter options in the Partner Ledger report (Kontoudtog) from being translated into Danish. The fix ensures that all report labels, including filter selections, are correctly localized for international users. This improves the user experience for Danish-speaking customers.
Original PR description
The problem: In the accounting reports, filter options were not being translated. Steps to reproduce: Install and change to the Danish language. Navigate to Accounting > Reporting > Partner ledger (Kontoudtog) Activate the filter "Only Show Unreconciled Entries" (Vis kun ikke udlignede posteringer) Generate the PDF report. Why it was happening: The array `extra_options` was built dynamically by concatenating raw python strings to it. Those raw strings will not be translated. The fix: Now, we create local variables for each string, using the syntax `<t t-set="label_raw_string">Raw String</t>` which makes the string label_raw_string translatable, then we append it to `extra_options`. opw-4213562
This update resolves a technical issue that prevented users from correctly calculating payslips when adding new worked days to draft payslips. The fix ensures that the system properly recomputes payslip amounts when editing, preventing a traceback error. This ensures accurate payroll processing for all employees.
Original PR description
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist. task-4191349 Forward-Port-Of: odoo/enterprise#71373
This update resolves an issue where the preparation display showed all orders, even after closing and reopening the session, leading to potential performance problems. Now, the display only shows currently active orders, improving the system's responsiveness and stability.
Original PR description
Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders. opw-4295258
This update fixes a potential issue where POS order tax information wasn't consistently matched, leading to inaccuracies in GST reports. By sorting tax IDs before comparison, the system now ensures accurate matching regardless of the original order, improving report reliability.
Original PR description
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs.
This update fixes an issue where rental order descriptions didn't automatically update when the rental start and end dates were changed in the cart. The system now recomputes the description after date modifications, ensuring accurate order details are displayed to the customer. This improves the user experience for rental orders.
Original PR description
Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting_period` Steps to reproduce: - Add any rental product to the cart. - On the cart page, modify the rental start and end dates. - The order description does not update to reflect the new dates. opw-4259443
This update fixes an error in the Pakistani Profit and Loss report that incorrectly displayed 'Other Income' as a negative value. The fix ensures that 'Other Income' is correctly added to the 'Gross Profit' section, accurately reflecting the company's financial performance. This resolves a discrepancy between the PK-specific report and the standard Profit & Loss report.
Original PR description
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the Year" section, which is not correct. On the other hand, if the normal "Profit and Loss" report is selected, the created journal entry is positive and its value is added to "Gross Profit" section, increasing "Net Profit" section, which is correct. opw-4185212 Forward-Port-Of: odoo/enterprise#72378