Tuesday, September 24, 2024
21 changes · 17.0
Enhancements to existing features
The carryover target line name in account report popups is now displayed in bold text for better readability. This makes it easier for users to quickly identify which line the carryover amount is associated with when reviewing financial reports.
Original PR description
For readability; so that the name of the line the carryover is made is more distinguishable from the text around it.
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
Documentation and clarification updates
This pull request updates contributor license information for the user tanghulu0608 by changing the email address associated with their CLA. This is an administrative/legal housekeeping change and does not affect Odoo product functionality for users.
Original PR description
Description of the issue/feature this PR addresses: Change email for tanghulu0608. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Steps to reproduce:** - On a fresh install, grant to any contact portal access. **Current behavior:** The newly created user has in its signature the following text: ``` -- Portal User Template ``` **Expected behavior:** No text **Explanation:** This is because there's no explicit signature set on the user "Portal User Template", which is the template used to create the portal users, and thus, the `compute_signature` method is triggered following the "name" dependenc
Original PR description
**Steps to reproduce:** - On a fresh install, grant to any contact portal access. **Current behavior:** The newly created user has in its signature the following text: ``` -- Portal User Template ``` **Expected behavior:** No text **Explanation:** This is because there's no explicit signature set on the user "Portal User Template", which is the template used to create the portal users, and thus, the `compute_signature` method is triggered following the "name" dependency, assigning that one. And this is even worst, as you may remove that content from the user, but on the next update, it will be rewritten again, as the record is noupdate=0 and the name is always rewritten, triggering again the signature computation. **Solution:** Indicate explicitly an empty signature on the XML record definition to avoid the triggering of `_compute_signature`. @Tecnativa Forward-Port-Of: odoo/odoo#181167
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
Steps to reproduce the bug: - Create a storable product “P1”: - vendors: -Azure interior, code: Vendor 1 - Deco Addict, code: Vendor 2 - Create a purchase order: - product P1 - Vendor: Azure interior > Description P1 [Vendor 1] - Create an Alternative PO: - Vendor: Deco Addict - Copy products: True Problem: The description of POL is incorrect: P1 [Vendor 1] instead of P1 [Vendor 2] opw-4133933 Forward-Port-Of: odoo/odoo#179487
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- vendors:
-Azure interior, code: Vendor 1
- Deco Addict, code: Vendor 2
- Create a purchase order:
- product P1
- Vendor: Azure interior
> Description P1 [Vendor 1]
- Create an Alternative PO:
- Vendor: Deco Addict
- Copy products: True
Problem:
The description of POL is incorrect: P1 [Vendor 1] instead of P1 [Vendor 2]
opw-4133933
Forward-Port-Of: odoo/odoo#179487Steps to reproduce the issue : - Open web editor - Drag and drop the Tab building block - Rename the first tab "email@gmail.com" or "example.com" - Switch to the second tab and switch back to the first one. Issue: The content of the first tab don't appears anymore when switching tabs. In 17.2 and above the same problem appears with the tel protocol, so '123' is converted to tel://123. Cause: The href attribute of the tab link is incorrectly converted to a mail protocol (mailto:email
Original PR description
Steps to reproduce the issue : - Open web editor - Drag and drop the Tab building block - Rename the first tab "email@gmail.com" or "example.com" - Switch to the second tab and switch back to the…
Steps to reproduce the issue : - Open web editor - Drag and drop the Tab building block - Rename the first tab "email@gmail.com" or "example.com" - Switch to the second tab and switch back to the first one. Issue: The content of the first tab don't appears anymore when switching tabs. In 17.2 and above the same problem appears with the tel protocol, so '123' is converted to tel://123. Cause: The href attribute of the tab link is incorrectly converted to a mail protocol (mailto:email@gmail.com), an http protocol (https://example.com/) or since 17.2, a tel protocol due to the deduceURLfromLabel() function introduced in [1]. This commit addresses the issue by disabling the conversion of URL, mail, and tel protocols when an anchor tag includes a role="tab" attribute, ensuring that the tab functionality remains intact. Only anchor links (href="#...") are allowed for tabs. [1]: https://github.com/odoo/odoo/commit/a903a3114b335fcd9c69b1c74a68838f2cef3e36 opw-4165676 Forward-Port-Of: odoo/odoo#179931
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL
Original PR description
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive:…
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL the received quantity went from 10 to 20 rather than 0 ### Note: Starting from 17.2, the Inter-company transit location is the default location destination of the return rather than (Partner/Vendor). It also changed its reference to `stock_location_inter_company` so that the fix should be adapted in that version. ### Cause of the Issue: Currently, the qty_received is computed with respect to moves linkes to the POL. However, a move is flagged as a return only if the usage of its destination supplier (dropshipping and subcontracting flow excluded): https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/stock_move.py#L247-L249 and if it is not flagged a return, its quantity is counted positively rather than negatively in the received quantity: https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/purchase.py#L348-L370 opw-4190647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180846
This issue was already fixed in c9e94bc78, but it's not working properly. The explanation on that commit is correct, however the resulting CSS from that SCSS is not a valid one: ```css .o_Message_content *:not(li):nottable(li div)[align="left"][width="100%"] { float: none; } ``` The result is actually weird, which may be due to an issue in the SCSS compiler. In any case, this commit fixes the SCSS, so that it's compiled like this: ```css .o_Message_content table[align="left"][
Original PR description
This issue was already fixed in c9e94bc78, but it's not working properly. The explanation on that commit is correct, however the resulting CSS from that SCSS is not a valid one: ```css…
This issue was already fixed in c9e94bc78, but it's not working properly. The explanation on that commit is correct, however the resulting CSS from that SCSS is not a valid one:
```css
.o_Message_content *:not(li):nottable(li div)[align="left"][width="100%"] {
float: none;
}
```
The result is actually weird, which may be due to an issue in the SCSS compiler.
In any case, this commit fixes the SCSS, so that it's compiled like this:
```css
.o_Message_content table[align="left"][width="100%"] {
float: none;
}
```
Which actually makes more sense, IMHO.
---
Here's a screenshot of runbot:
<img width="1686" alt="Screenshot 2024-09-23 at 3 46 27 PM" src="https://github.com/user-attachments/assets/1dbf2ea6-e918-4d51-b15c-6ad7c493af1c">
---
@nle-odoo @alexkuhn : I ping you as I see you worked on https://github.com/odoo/odoo/pull/101295, so you probably remember this issue
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#181099This update adds a new test.txt file as an initial test change. It appears to be a minor repository-only addition with no expected effect on business workflows or customer-facing features.
Original PR description
First commit add file test.txt
### before this PR When creating a new company, a new resource calendar is created by copying the default calendar of the current company. However, if the calendar of the current company contains the same periods (e.g. Saturday Afternoon) with different date_from and date_to, duplication error will raise, by the constrain `_check_attendance()` which calls the `_check_overlap()`. See https://github.com/odoo/odoo/blob/013a0391d5de84fda02d542760471f4c296b7f2b/addons/resource/models/resource.py#L36
Original PR description
### before this PR When creating a new company, a new resource calendar is created by copying the default calendar of the current company. However, if the calendar of the current company contains the same periods (e.g. Saturday Afternoon) with different date_from and date_to, duplication error will raise, by the constrain `_check_attendance()` which calls the `_check_overlap()`. See https://github.com/odoo/odoo/blob/013a0391d5de84fda02d542760471f4c296b7f2b/addons/resource/models/resource.py#L362-L383 Here is a sample of the default calendar of the current company that caused error when creating a new company  ### What this PR does copying resource calendar should respect date_from and date_to to pass constraint --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149697
Forward-Port-Of: odoo/odoo#180836
Original PR description
Forward-Port-Of: odoo/odoo#180836
Open POS Session Add a product with tax Checkout and Pay order Close POS Session Check generated move Now create an invoice, with same product and tax Confirm Open Tax Reports Two entries will be present, with correct amounts Activate 'Group by: Account>Tax' option Issue: Base line amount is not correct This occurs because in the tax details query we group by display_type of the lines. When POS creates closing session move, lines will not have the proper display_type assigned, s
Original PR description
Open POS Session Add a product with tax Checkout and Pay order Close POS Session Check generated move Now create an invoice, with same product and tax Confirm Open Tax Reports Two entries will be present, with correct amounts Activate 'Group by: Account>Tax' option Issue: Base line amount is not correct This occurs because in the tax details query we group by display_type of the lines. When POS creates closing session move, lines will not have the proper display_type assigned, so for example, tax lines will have display_type 'product'. opw-4125791 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 Forward-Port-Of: odoo/odoo#180864
Steps to Reproduce =================== - Open the event page. - Switch on the country filter. - select the online event from that. - The filter is applied but in a dropdown, it is still showing the All countries. After this commit ================== This PR addresses the issue and now when we select the online filter online event will be there in a dropdown also. Task-4058244 Forward-Port-Of: odoo/odoo#180912 Forward-Port-Of: odoo/odoo#174629
Original PR description
Steps to Reproduce =================== - Open the event page. - Switch on the country filter. - select the online event from that. - The filter is applied but in a dropdown, it is still showing the All countries. After this commit ================== This PR addresses the issue and now when we select the online filter online event will be there in a dropdown also. Task-4058244 Forward-Port-Of: odoo/odoo#180912 Forward-Port-Of: odoo/odoo#174629
When the Customer archives the product and opens the BOM overview, a traceback will appear. Steps to reproduce the error: - Go to Mrp > Configuration > Settings > Enable By-Products - Create a new BOM > Select Product A > Select By-product in By-products > Save - Archive Product A > Return to BOM - Open BOM overview Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5975, in ensure_one _id, = self._ids ValueError: Expected
Original PR description
When the Customer archives the product and opens the BOM overview, a traceback will appear. Steps to reproduce the error: - Go to Mrp > Configuration > Settings > Enable By-Products - Create a new…
When the Customer archives the product and opens the BOM overview,
a traceback will appear.
Steps to reproduce the error:
- Go to Mrp > Configuration > Settings > Enable By-Products
- Create a new BOM > Select Product A > Select By-product in By-products > Save
- Archive Product A > Return to BOM
- Open BOM overview
Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5975, in ensure_one
_id, = self._ids
ValueError: Expected singleton: product.product()
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2187, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/mrp/report/mrp_report_bom_structure.py", line 16, in get_html
res = self._get_report_data(bom_id=bom_id, searchQty=searchQty, searchVariant=searchVariant)
File "addons/mrp/report/mrp_report_bom_structure.py", line 119, in _get_report_data
lines = self._get_bom_data(bom, warehouse, product=product, line_qty=bom_quantity, level=0)
File "addons/mrp/report/mrp_report_bom_structure.py", line 315, in _get_bom_data
byproducts, byproduct_cost_portion = self._get_byproducts_lines(product, bom, current_quantity, level + 1, bom_report_line['bom_cost'], index)
File "addons/mrp/report/mrp_report_bom_structure.py", line 421, in _get_byproducts_lines
if byproduct._skip_byproduct_line(product):
File "addons/mrp/models/mrp_bom.py", line 740, in _skip_byproduct_line
return not product._match_all_variant_values(self.bom_product_template_attribute_value_ids)
File "addons/mrp/models/product.py", line 342, in _match_all_variant_values
self.ensure_one()
File "odoo/models.py", line 5978, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/b0684bd80f31a808521cf5229b9ac8a621e39afc/addons/mrp/models/mrp_bom.py#L600 When Customer archives the product and opens the BOM overview,
Here, ```product``` will be empty,
So, it will lead to the above traceback.
sentry-5844550626
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#180594Problem: The expiration date were showing on confirmed sale orders in the customer portal. Purpose: The expiration date should only show if the order is still a quotation in the customer portal. Steps to Reproduce on Runbot: 1. Install Sale 2. Create a quotation with an expiration date and confirm 3. View the sale order in the customer portal view and observe that the expiration date is still displayed opw-3926689 --- I confirm I have signed the CLA and read the PR guidelines at
Original PR description
Problem: The expiration date were showing on confirmed sale orders in the customer portal. Purpose: The expiration date should only show if the order is still a quotation in the customer portal. Steps to Reproduce on Runbot: 1. Install Sale 2. Create a quotation with an expiration date and confirm 3. View the sale order in the customer portal view and observe that the expiration date is still displayed opw-3926689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180383