Friday, January 10, 2025
20 changes · saas-17.2
Resolved issues and error corrections
The Peruvian electronic invoicing PDF now shows withholding amounts with the company currency symbol instead of the invoice currency symbol. This prevents confusion when invoices are issued in foreign currencies but the withholding amount must be displayed in PEN.
Original PR description
Scenario: - Install l10n_pe_edi and switch to "PE Company" - Create a product with "Withhold Percentage" 20% - Create an invoice with operation type "[1001] Operation Subject to Detraction", the created product and USD currency. - Print the invoice as PDF => The "Withholding amount" in the PDF is correctly shown in the company currency, but the currency symbol is the one of the invoice ($) Issue: Amount is always in the company currency, and currency is the invoice currency that might be different. Fix: currency_id gotten from account.move()._l10n_pe_edi_get_spot is only used in this location where the amount should always be the company currency: so we modify it to be the company currency. opw-4292774 opw-4338728
The website project form now translates the "Email" label in the chatter message when a task is created. This improves localization consistency for users working in languages other than English.
Original PR description
- add translation for `Email` in chatter message when task create from website form. task-4295363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github
Original PR description
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax,…
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github.com/odoo/enterprise/blame/16.0/account_reports/models/account_generic_tax_report.py#L406 , so we essentially don't add the base amounts of the tax lines whose identification key has already been treated. This is important for taxes with multiple tax repartition lines. In our case, a line is generated by the query for both the invoice and the expense entry. This is because the query groups on display_type: the expense line has display_type = 'product', while the invoice has 'tax'. This grouping was introduced here https://github.com/odoo/enterprise/commit/67f841ee36cb5a8ef95ae3dd3859239a4d10b99d to avoid counting the base amounts of the cash rounding lines as additional base amounts. We fix this by slightly tweaking the query, in order for rounding lines to be considered as having a base amount of 0. opw-3890736 Forward-Port-Of: odoo/enterprise#76801 Forward-Port-Of: odoo/enterprise#76536
Accountants that start a new DB in Odoo may want to fetch more than 3 months of historic for CODAs (i.e. bank statements). So we're raising this to 1 year so that it's enough time to fetch every transaction needed for an annual closing. Although this may seem like a lot to import, and we may timeout, it's not really a problem because after each imported CODA, we commit it. So next time the user syncs the CODAs, we'll continue where we left off, and we'll import only the CODAs whose date is a
Original PR description
Accountants that start a new DB in Odoo may want to fetch more than 3 months of historic for CODAs (i.e. bank statements). So we're raising this to 1 year so that it's enough time to fetch every transaction needed for an annual closing. Although this may seem like a lot to import, and we may timeout, it's not really a problem because after each imported CODA, we commit it. So next time the user syncs the CODAs, we'll continue where we left off, and we'll import only the CODAs whose date is after the last imported one. task-id: none Forward-Port-Of: odoo/enterprise#76824
When a tag has both a very long category and a very long tag name, the delete icon becomes misaligned due to text overflow. This causes the clickable area for the icon to shift away from where the icon is visually displayed. As a result, users might think they cannot delete the tag because clicking directly on the icon does not trigger the delete action. To fix this, we can apply `max-width: 2ch` to the delete icon. Since the icon will always be one character's width, giving them 2ch width wi
Original PR description
When a tag has both a very long category and a very long tag name, the delete icon becomes misaligned due to text overflow. This causes the clickable area for the icon to shift away from where the…
When a tag has both a very long category and a very long tag name, the delete icon becomes misaligned due to text overflow. This causes the clickable area for the icon to shift away from where the icon is visually displayed. As a result, users might think they cannot delete the tag because clicking directly on the icon does not trigger the delete action. To fix this, we can apply `max-width: 2ch` to the delete icon. Since the icon will always be one character's width, giving them 2ch width will be enough to properly display it without taking more space than needed, and ensures that the icon remains properly aligned with the tag, regardless of text length. This ch unit corresponds to be Equal to the “0” (ZERO, U+0030) glyph found in the font used to render it. Before the fix: <img width="296" alt="image" src="https://github.com/user-attachments/assets/f3f45666-0c21-4334-823a-a2afacd5ebe2" /> After the fix: <img width="292" alt="image" src="https://github.com/user-attachments/assets/7deb8253-bcd3-4469-9c5b-8a135591d331" /> FW-bot up to 18.0 opw-4403905 Forward-Port-Of: odoo/enterprise#75690
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76716
Original PR description
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76716
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Original PR description
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality checks are filtered using “search_default_lot_id = active_id”, which means only quality checks linked to th
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality checks are filtered using “search_default_lot_id = active_id”,
which means only quality checks linked to the “search_default_lot_id”
are displayed. However, in this usecase, the "lot_id” is not set.
Instead, the "finished_lot_id" is used, causing the quality checks to be
hidden unless the filter is removed.
Solution:
the domain is properly prepared so no longer needs this filter: https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L23-L27
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L20-L21
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_mrp_workorder/models/stock_lot.py#L10-L13
opw-4361358
Forward-Port-Of: odoo/enterprise#76376…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by
Original PR description
…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by simply returning early when the asset's residual amount is zero. A test is also added to cover this use case. opw-4411877 Forward-Port-Of: odoo/enterprise#76733 Forward-Port-Of: odoo/enterprise#76555
The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail. In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested
Original PR description
The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail. In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested on pre- production) opw-4438259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193000
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb. While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it. Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(s
Original PR description
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb. While technically it was always…
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb.
While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it.
Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(self._info, DictionaryObject)` as a type narrowing and trusts the developer, thus does not report the type mismatch... and the assertion ends up blowing in the user's face at runtime with a simple
>>> r = pypdf.PdfReader(some_pdf_document)
>>> w = pypdf.PdfWriter()
>>> w.clone_reader_document_root(r)
>>> w.add_metadata({"/foo": "bar"})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "lib/python3.12/site-packages/pypdf/_writer.py", line 1622, in add_metadata
assert isinstance(self._info, DictionaryObject)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
This is rather inconsiderate, so monkeypatch `add_metadata` to handle the case where `_info` exists and is `None`.
Most of the credit goes to juwu for uncovering the issue.
opw-4372052
opw-4426881
Fixes #185673
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#193086**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory
Original PR description
**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory 5. Click the (i) in the orderpoint line for the product -> see the global vis. days are counted 2x **Cause of the issue:** Like the issue solved by 38d8e77 In some instances the `_get_lead_days()` must be called a second time to capture some additional lead time (in this case because we have > 1-step manufacturing). **Fix:** Use the context added in the referenced similar commit to ignore the global days in the second call. opw-4410790 Forward-Port-Of: odoo/odoo#190808
The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI. Steps to reproduce the bug * create child company CHILD 1, with an invoice $100 * Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity) * make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal * click reconcile fr
Original PR description
The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI. Steps to reproduce the bug * create child company CHILD 1, with an invoice $100 * Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity) * make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal * click reconcile from the dashboard, on CHILD 2 bank journal => you get an access error because Odoo is trying to match invoice from CHILD 1 and bank transaction from CHILD 2 ticket-4384481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192507
User of a branch company may change accounts configuration product categories, but currently this settings is ignored, as accounts are fetched from the main company instead Steps to reproduce: - Create a branch company - Open a product category [CATEG] (i.e. Office Furniture) and set - 'Inventory valuation': 'Automated' - 'Stock Input Account': [Account] - Assign product category [CATEG] to a product [PROD] - Create a Vendor bill with [PROD] and Save - Check Journal items tab
Original PR description
User of a branch company may change accounts configuration product categories, but currently this settings is ignored, as accounts are fetched from the main company instead Steps to reproduce: - Create a branch company - Open a product category [CATEG] (i.e. Office Furniture) and set - 'Inventory valuation': 'Automated' - 'Stock Input Account': [Account] - Assign product category [CATEG] to a product [PROD] - Create a Vendor bill with [PROD] and Save - Check Journal items tab Issue: Product line account is not [Account] but it is taken from the main company settings This occurs due to a fix [1] done to have `stock_account` in sync with the base method in `account`. However, the forced company in base method was changed in a refactor [2] [1] https://github.com/odoo/odoo/commit/0b07210fe1f1c451eb648deff74c3ab37c8c09bd [2] https://github.com/odoo/odoo/commit/d8d47f9ff8554f4b39487fd2f13c153c7d6f958d opw-4297203 Forward-Port-Of: odoo/odoo#191349
__Current behavior before commit:__ In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore. Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`. In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should
Original PR description
__Current behavior before commit:__ In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore. Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`. In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should use. Ultimately leading to this error: ``` psycopg2.errors.AmbiguousColumn: column reference "end_type" is ambiguous LINE 22: ... WHEN cal.recurrency AND end_type =... ``` __Description of the fix:__ Remove the ambiguity by explicitly specifying `rrule`, the alias of the `calendar_recurrence` table. opw-4406814 [1]: https://github.com/odoo/odoo/commit/a27afdb [2]: https://github.com/odoo/odoo/commit/f6df418 Forward-Port-Of: odoo/odoo#192946
This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. runbot-error: 111437 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#192831
Original PR description
This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. runbot-error: 111437 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#192831
**Steps to reproduce:** - Install account_accountant, sale_management and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create a payment term: * Description on the Invoice: [anything] * Display terms on invoice: [checked] * Terms: [add many lines] - Create a SO: * Customer: [any] * Payment Terms: [the created payment term] * Order lines: [anything] - Confirm the SO - Create an invoice from the SO - Confirm the invoice - Generate the invoice **Issue:
Original PR description
**Steps to reproduce:** - Install account_accountant, sale_management and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create a payment term: * Description on the Invoice: [anything] * Display terms on invoice: [checked] * Terms: [add many lines] - Create a SO: * Customer: [any] * Payment Terms: [the created payment term] * Order lines: [anything] - Confirm the SO - Create an invoice from the SO - Confirm the invoice - Generate the invoice **Issue:** The description of the payment term is displayed on the invoice but the terms are not displayed as it is the case in any other localization. **Cause:** "report_invoice" is replaced by the Arabic/English invoice in l10n_gcc_invoice module. However, the logic to display the terms has not been added in the template for Arabic/English invoice. opw-4291232 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188456
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.5.3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193192
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.5.3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193192
Before this commit: When a user duplicates a server action, the new action retains the exact same name as the original. After this commit: Duplicated server actions are assigned a name with the suffix "(copy)" to differentiate them from the original action. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190383
Original PR description
Before this commit: When a user duplicates a server action, the new action retains the exact same name as the original. After this commit: Duplicated server actions are assigned a name with the suffix "(copy)" to differentiate them from the original action. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190383
**Specifications:** When the domain is specified, helper in crm helper should display an extra line, which explains that any email sent to alias@domain will create a lead. **Technical reason:** A code was added in `crm.lead` which checks for the company, but in data file company was already specified as `False`. Hence, the missing line. **After this PR:** If the custom email domain is set, crm helper will display an extra line. Task-4377574 Forward-Port-Of: odoo/odoo#190936
Original PR description
**Specifications:** When the domain is specified, helper in crm helper should display an extra line, which explains that any email sent to alias@domain will create a lead. **Technical reason:** A code was added in `crm.lead` which checks for the company, but in data file company was already specified as `False`. Hence, the missing line. **After this PR:** If the custom email domain is set, crm helper will display an extra line. Task-4377574 Forward-Port-Of: odoo/odoo#190936