Tuesday, September 24, 2024
7 changes · 17.0
Resolved issues and error corrections
Peruvian invoice labels now include the applicable tax percentage, such as showing IGV with 18%. This makes invoice PDFs clearer and more complete for customers and accounting teams.
Original PR description
The taxes on Peru localization no not have the percentage added by default on the invoice_label field. Currently, the tax name is simply IGV (for the 18% tax) which makes the invoice PDF feel incomplete. This Pr adds the percentage on the invoice label. task: 4114767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website search dropdown has been adjusted so product prices remain fully visible even when category names are long or header text is enlarged. This improves the shopping experience by preventing important pricing information from being cut off during product searches.
Original PR description
Steps to reproduce the issue: - Change the header menu layout to "Sales 2." - Increase the font size of the header (e.g., set it to 20). - In the backend, add a long product category (e.g., "very long category's name") to a product like "Customizable Table". Issue: When searching for the product in the search bar, the price is not displayed in full. However, after deleting the product category, the price is shown correctly, even with the large font size. This commit resolves the issue by adjusting the layout to ensure the price is fully visible, regardless of the font size or category length. opw-4077768
Spanish SII electronic reporting now handles invoices whose positive and negative lines cancel out when they use 0% tax. This prevents valid zero-total invoices from being blocked during processing.
Original PR description
**Current behavior:** An invoice with offsetting lines (total == 0.00) with 0% tax will prevent the invoice from being processed by the SII Llevanza de libros registro (ES). **Expected behavior:**…
**Current behavior:** An invoice with offsetting lines (total == 0.00) with 0% tax will prevent the invoice from being processed by the SII Llevanza de libros registro (ES). **Expected behavior:** The invoice can be processed. **Steps to reproduce:** 1. Create an invoice from a Spanish company to, e.g., a Belgian company 2. Create 2 invoice lines for the same product, one for positive 10 euros, the other for negative 10 euros 3. Add the `0% EU S (Services)` tax to both invoice lines 4. Confirm the invoice, then try to process the document 5. Observe the error about not having a tax scope set, even though the scope is set in the tax settings **Cause of the issue:** When an invoice in in this state, it goes through the `_l10n_es_edi_get_invoices_tax_details_info()` method without a value for the `TipoDesglose` EDI node, causing the exception. **Fix:** If there are taxes present but no values for the `TipoDesglose` node filled at the end of the method, add them (respectively, based on the tax type) with a value == 0. opw-4083107
The employee leave module now avoids defining the same shared employee behavior in two places. This reduces internal duplication and helps make future maintenance safer without changing the user experience.
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file
This fix prevents an error from appearing when staff reprint a point-of-sale receipt for an existing order. It helps keep checkout and post-sale service workflows smooth by making receipt reprints work reliably.
Original PR description
Before this commit, attempting to reprint a receipt for an order would result in an "Invalid props" error. opw-4191019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents inactive users from being re-added to discussion channels during automatic subscription updates. It avoids upgrade-blocking errors and keeps channel membership focused on active users only.
Original PR description
Description of the issue/feature this PR addresses: - While automatically subscribing new users to the discussion channel, we encounter a unique constraint violation…
Description of the issue/feature this PR addresses: - While automatically subscribing new users to the discussion channel, we encounter a unique constraint violation `discuss_channel_member_partner_unique`. This happens because, when determining the `new_member`, we retrieve all users (both active and inactive 'channel.group_ids.users.partner_id'). [ref](https://github.com/odoo/odoo/blob/eac6b58a68948a2cdc0b97e7c62c92ff6270fd7a/addons/mail/models/discuss/discuss_channel.py#L330-L334) However, when checking for already subscribed members, inactive users are ignored due to the `channel_partner_ids` computation. As a result, an inactive user who is already subscribed is incorrectly considered a `new_member`. Current behavior before PR: - Upgrade process got blocked if the inactive user already exists as member of the channe Desired behavior after PR is merged: - Adding inactive user to the discuss channel is pointless so we ensure only active user OPW- 4169746 UPG- 2020544 TGB- 1531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now detects duplicate grouping requests in an internal reporting/data aggregation path and returns a more relevant error instead of failing unclearly. This helps administrators and developers diagnose rare reporting issues, such as duplicated date groupings in pivot-style views, with less confusion.
Original PR description
[FIX] core: relevant error when duplicate groupby spec Since https://github.com/odoo/odoo/pull/103510/files#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bR1863, `groupby` of `_read_group` doesn't handle no-unique groupby_spec (`groupby=['date:month', 'date:month]`). This is because the `groupby_terms` deduplicate the `groupby` by its dict nature. We cannot easily fix this in `_read_group`, instead we raise a corresponding error. The `read_group` (public method) can already handle duplicate groupby specifications, unless when one of then is implicit and the other one is explicit as `groupby=['date', 'date:month]`. This was rarely requested from the pivot view and fixed in https://github.com/odoo/odoo/pull/143792