Friday, January 10, 2025
34 changes · 18.0
Enhancements to existing features
Adds automated checks to confirm that sales orders created from imported purchase orders include all expected details. This helps reduce the risk of missing or incorrect order information when businesses exchange orders electronically.
Original PR description
This commit add order edi test cases to check imported sale order from purchase order have all the details properly filled out to ensure everything is working. task-4206350
Resolved issues and error corrections
Calendar events created through modules such as Appointments will no longer automatically create follow-up activities when those modules do not need them. This avoids clutter and unnecessary work items for users when meetings are booked.
Original PR description
Some modules (i.e., Appointment) uses calendar.event, but they don't want to create an activity every time a user books a meeting. This PR indroduce a helper function, which return a list of models, in which we don't want to create activities. Task-4243603
Miscellaneous changes
Partial Revert of 2f7bc1e606809b9a65d357c08fea26b364d81941 The fix applied in 17.0 when forward porting it reintroduced a function that was previously removed. [Mentioned diff](https://github.com/odoo/odoo/commit/b25e8e2cfefcf2af9af7a7cbe04110ac35f81f3d#diff-60accb44cf04ef4bd2a178a0dfefeb9facdf3724caf4ba080ffa63d8b08c807eR35:~:text=%2B-,def%20_get_pricelist_price_before_discount(self)%3A,-36) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
Partial Revert of 2f7bc1e606809b9a65d357c08fea26b364d81941 The fix applied in 17.0 when forward porting it reintroduced a function that was previously removed. [Mentioned diff](https://github.com/odoo/odoo/commit/b25e8e2cfefcf2af9af7a7cbe04110ac35f81f3d#diff-60accb44cf04ef4bd2a178a0dfefeb9facdf3724caf4ba080ffa63d8b08c807eR35:~:text=%2B-,def%20_get_pricelist_price_before_discount(self)%3A,-36) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193176
This fixes an issue where the current user could appear twice in user selection dropdowns when search results reached the limit. Users now see the expected person once, in the correct position, reducing confusion when assigning or selecting users.
Original PR description
Steps: - Login as Mitchell Admin - Create 8 user (B, C, D, E, F, G, H, I) to reach search limit - Rename Mitchell Admin to Admin Mitchell to be the first result - Open a user dropdown (employee form) Actual result: - Admin Mitchell appears twice Expected result: - Admin Mitchell appears at first position - Admin Mitchell appears only once opw-4430590
This fix makes an automated recruitment website form test wait for the page element it needs before continuing. It reduces false failures in Odoo's test pipeline, helping keep recruitment website changes safer to release.
Original PR description
In this commit, we prefer to use selector in trigger instead of use native in run function. This is better to ensure trigger is in DOM when the run is activated. The findTrigger method in tour engine is based on MutationObserver while run function in a step definition is launched once the trigger has been found. This is why it can cause the following error during the tour. runbot-error-id~106439 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 makes an automated project to-do test more reliable by checking that tasks appear in the activity view without unnecessarily clicking them. It helps reduce false test failures and supports smoother maintenance of the project to-do feature.
Original PR description
Before this commit, the test running the `project_task_activities_split` tour could failed because a step clicks on a task displayed in the activity view instead of just checking if the task expected is present on the view. This commit removes the click event on that step to just check if we found the node with the trigger defined in that step to be sure the task is on the activity view. By doing that, the next step checking if another task is also there in the activity. Closes #192995
This update makes the Indonesian point-of-sale test setup more focused so it consistently finds the intended test product. It reduces random test failures, helping maintain confidence in future updates without affecting everyday users.
Original PR description
This fixes the indeterminate test failures where the Test Product isn't found in the product list. Related: https://github.com/odoo/enterprise/pull/76517
Long links in Social posts are now shortened with an ellipsis instead of overflowing outside kanban cards. This keeps post previews tidy and easier to read for users reviewing social content.
Original PR description
Before this commit: Post including long links were not truncated and will extend beyond the kanban card. This happen as the display CSS property is set to `inline` by default due to the <field> tag being transformed into a <span> tag in the HTML. <div> default display is `block` while <span> are `inline`. After this commit: The link truncate as intended with "..." Before:  After:  opw-4446906
Printed check reports now format the payee address correctly for top, middle, and bottom check layouts. This improves the appearance and readability of checks generated from payments, reducing the risk of poorly formatted printed documents.
Original PR description
Issue: ------ When printing the reports which are Print Check(Top, Middle and Bottom), the address of that particular report is not being formatted properly which makes the printed report poor…
Issue: ------ When printing the reports which are Print Check(Top, Middle and Bottom), the address of that particular report is not being formatted properly which makes the printed report poor formatted/ugly. There are three types/formats of report which are Print Check(Top, Middle and Bottom) none of them are getting printed properly(address). View Ref: [Link](https://github.com/odoo/enterprise/blob/saas-17.4/l10n_us_check_printing/report/print_check.xml#L17) **Note:** Not the blank reports like Print Blank Check(Top, Middle and Bottom). Solution: ----------- Add an adequate width to the addresses class i.e; `ckus_payee_addr`. Steps to reproduce:- -------------------- 1. Create a demo db in version 18.0 with `l10n_us_check_printing` module installed. 2. Create a payment record and confirm it. 3. Try printing that payment with any of (top/middle/bottom) Print Check reports. 4. check with the address which would've broken. Reference Screenshots: **Without Fix:**  **With Fix:**  OPW - 4454079 UPG - 2408700
Steps to reproduce: 1. Create a task, and a subtask 3. Open the subtask 4. From the gear icon, click "Convert to Task/Sub-Task" 5. Remove the parent task and click "Convert Task" 6. Go to the project dashboard > the subtask is not shown. Why? The above reproducing steps lead to the subtask having the `display_in_project` stored as `False`, hence it's not visible on the dashboard page. This is because `_compute_project_id` interrupted the computation flow of `display_in_project` by a cal
Original PR description
Steps to reproduce: 1. Create a task, and a subtask 3. Open the subtask 4. From the gear icon, click "Convert to Task/Sub-Task" 5. Remove the parent task and click "Convert Task" 6. Go to the project dashboard > the subtask is not shown. Why? The above reproducing steps lead to the subtask having the `display_in_project` stored as `False`, hence it's not visible on the dashboard page. This is because `_compute_project_id` interrupted the computation flow of `display_in_project` by a call to `remove_to_compute` [1]. Fix: In the `write` method, explicitly set `display_in_project` to `True` if the parent_id has been removed. [1]: https://github.com/odoo/odoo/blob/9dec8329523d4966243c6491e7e556e643af6cdf/addons/project/models/project_task.py#L337 opw-4384222 Forward-Port-Of: odoo/odoo#191530
**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
**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
**Current behavior before PR:** prior to this PR fa-plane icon does not displayed after user comes online/offline/away while on leave without any reload. **Desired behavior after PR is merged:** now fa-plane icon is displayed with respective color of im_status without any reload task-4237384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193120 Forward-Port-Of: odoo/odoo#184471
Original PR description
**Current behavior before PR:** prior to this PR fa-plane icon does not displayed after user comes online/offline/away while on leave without any reload. **Desired behavior after PR is merged:** now fa-plane icon is displayed with respective color of im_status without any reload task-4237384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193120 Forward-Port-Of: odoo/odoo#184471
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
**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
Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#191801 Forward-Port-Of: odoo/odoo#180283
Original PR description
Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#191801 Forward-Port-Of: odoo/odoo#180283
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_
Original PR description
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list…
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_default_stage_id`, which is the first stage in sequence, regardless of its company. We then change the company of the project to match the stage's company, which overrides the stage set at creation. Change ----- If the project has a company set a creation, use the first stage without a company or with the same company as the project. This is done even if the user doesn't have multiple companies selected, since the `search` on `project.project.stage` can return a stage from another company than the one selected. opw-4290711 Forward-Port-Of: odoo/odoo#192865 Forward-Port-Of: odoo/odoo#187635
Previously, when refunding a product with a serial number, the serial number was not being properly set in the refund order. This caused issues in inventory management as the POS transfer was not automatically validated. After this commit, the serial number of the refunded product is correctly assigned in the refund order and the POS transfer is automatically validated. opw-4387411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
Previously, when refunding a product with a serial number, the serial number was not being properly set in the refund order. This caused issues in inventory management as the POS transfer was not automatically validated. After this commit, the serial number of the refunded product is correctly assigned in the refund order and the POS transfer is automatically validated. opw-4387411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191147
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
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
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#193086The 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#193091 Forward-Port-Of: odoo/odoo#193000
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
Currently, an error is generated when the user tries to uninstall ``account`` module after installing ``account_inter_company_rules`` module. Steps to reproduce: --- - Install ``account_inter_company_rules`` module - Uninstall ``account`` module Traceback: --- ``KeyError: 'res.company.intercompany_purchase_journal_id'`` When we uninstall the account module, we set all associated fields related to 'account' (e.g., chart_template) to 'False'. Change: --- Force a recomputation by
Original PR description
Currently, an error is generated when the user tries to uninstall ``account`` module after installing ``account_inter_company_rules`` module. Steps to reproduce: --- - Install ``account_inter_company_rules`` module - Uninstall ``account`` module Traceback: --- ``KeyError: 'res.company.intercompany_purchase_journal_id'`` When we uninstall the account module, we set all associated fields related to 'account' (e.g., chart_template) to 'False'. Change: --- Force a recomputation by flushing the records. sentry-6054886854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191154
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
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priorit
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priority before this commit: partner email > parent partner email > partner DTE email > parent partner DTE email ### Solution: Change the order to display the DTE email if possible: Order of priority after this commit: partner DTE email > parent partner DTE email > partner email > parent partner email opw-4288781 Forward-Port-Of: odoo/enterprise#76600 Forward-Port-Of: odoo/enterprise#75917
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 th
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 Forward-Port-Of: odoo/enterprise#76334
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
Original PR description
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forw
Original PR description
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forward-Port-Of: odoo/enterprise#76660 Forward-Port-Of: odoo/enterprise#76524
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in th
Original PR description
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in the Helpdesk Team configuration. task-4224818 Forward-Port-Of: odoo/enterprise#71516
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