Daily updates from Odoo
Friday, February 7, 2025
87 changes
15 changes
Resolved issues and error corrections
Clicking an applicant from the recruitment documents list no longer causes an error. This keeps navigation from job position documents to applicant records working reliably for recruitment users.
Original PR description
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on…
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, many2one_reference was changed from a simple integer to either 0 if unset, or a object containing resId and displayName keys. Fix: Get the id with .resId and this should not happen, but test if the record is set with "if(res_id && ...)" in case res_id was 0. Note: without the fix, the added test fails by opening the view if res_id was 0, and if not the next click would fail with: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean opw-4384139 PR note: the test could be run without mails models, but then we would need to mock a lot of models for services (like `mail.ChatHub`) or a method like `prepareRegistry` [from studio](https://github.com/odoo/enterprise/blob/f5b7b53963829b351446e9b6f71e00f21291bc58/web_studio/static/tests/view_editor_tests_utils.js#L123-L153) that would remove all unnecessary services for the test.
Miscellaneous changes
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196835
Original PR description
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196835
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
Original PR description
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear o
Original PR description
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On…
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear on the XML file of an electronic invoice. Steps to reproduce: 1. Install Uruguay - Electronic Invoice module 2. Create EDI invoice, add special character to the description of the product you are using. Example used for testing (copy-paste it): 219179120011 3. Validate the invoice 4. Print and send it 5. Check "DscItem" field on the XML file created. Here is a one minute [video](https://drive.google.com/file/d/18JcnKCbaq7cH_NVyPol4CWXHdqZAxAdo/view) reproducing the error on runbot. Desired behavior after PR is merged: These characters are cleaned up at the xml level on cleanup_xml_node method to avoid them to appear and prevent errors when validating the XML on localizations web services. Related PR on v16 regarding the same issue in another context: https://github.com/odoo/odoo/pull/154509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193047
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196182
Original PR description
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196182
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the increase in delay (delivery lead time in the 'Purchase' tab on Product form). **Expected behavior:** The `qty_forecast` and `qty_to_order` fields update to reflect moves which should be captured according to JiT forecasting. **Steps to reproduce:** 1. Create some productA with a vendor
Original PR description
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the…
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the increase in delay (delivery lead time in the 'Purchase' tab on Product form). **Expected behavior:** The `qty_forecast` and `qty_to_order` fields update to reflect moves which should be captured according to JiT forecasting. **Steps to reproduce:** 1. Create some productA with a vendor that has some lead time 2. Create a sale order for that product, edit the sale order `commitment_date` field (Sale Order -> Other Info -> Delivery Date) to some future date such that the delay would not necessitate any replenishment at the current date (i.e., today + delay + 1 day) 3. Create an orderpoint for the productA, see that the `qty_to_order` is 0 -> this makes sense 4. Increase the delay for the vendor on productA enough that a purchase order would be required to fulfill the sale order on time 5. Go back to the replenishment report -> qty to order still 0 **Cause of the issue:** `qty_to_order` is stored and computed, in this sequence none of its dependencies are modified and so it remains 0 after `delay` on the supplier info record is changed. **Fix:** Add `product_id.seller_ids.delay` to the dependency list of `_compute_qty` and `_compute_qty_to_order`. opw-4333016 Forward-Port-Of: odoo/odoo#195657 Forward-Port-Of: odoo/odoo#189427
Behavior Before the Commit: Whenever you change the account type of a Cash and Bank account to a different type, please ensure that the Reconcile option is set to True. However, if you later switch the account type back to Cash and Bank, the Reconcile option will remain True and will not automatically revert to False. Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile method. Behavior After the commit: Reconcile will be changed to false o
Original PR description
Behavior Before the Commit:
Whenever you change the account type of a Cash and Bank account to a different type,
please ensure that the Reconcile option is set to True. However, if you later switch
the account type back to Cash and Bank, the Reconcile option will remain True and
will not automatically revert to False.
Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile
method.
Behavior After the commit:
Reconcile will be changed to false on changing the account type to Cash and Bank.
opw-4450088: https://www.odoo.com/odoo/my-support-tasks/4450088
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194358### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory > Configuration > Warehouse Management > Locations - Create 2 warehouse locations: WH/LOC1, WH/LOC2 - Go to the barcode app and proceed with the scans: 1. Scan the internal transfer picking type 2. Scan WH/STOCK as a source location 3. Scan the package name (PK) 4. Scan WH/LOC1 as
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory >…
### Steps to reproduce:
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable prodcut
- Update the on hand quantity:
- 10 units in package PK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans:
1. Scan the internal transfer picking type
2. Scan WH/STOCK as a source location
3. Scan the package name (PK)
4. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Try to validate the picking
#### > Invalid operation: You cannot move the same package content more than once in the same transfer or split the same package into two location.
### Cause of the issue:
As both pickings were treated via the barcode app, they generated picked move lines related to the package. Both of these move lines have updated the reserved quantity of the stock.quant present in stock:
- WH/STOCK, quantity: 10, reserved_quantity: 20.
When you try to validate the second picking, you will launch an `_action_done` of its move line that will create a new quant in WH/LOC2 and update the quant in stock:
- WH/STOCK, quantity: 0, reserved_quantity: 10.
- WH/LOC2, quantity: 10, reserved_quantity: 0.
The error is raised just after since 2 quants with either a quantity or reserved quantity are found:
https://github.com/odoo/odoo/blob/6349fb0362d881672616bb4b800bd32be82f9a5f/addons/stock/models/stock_move.py#L1910-L1917
### Fix:
Since the check is made in order to check the consistency of result packages moved by the current validation the "reserved_quantity" should not matter.
opw-4456484
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193214This commit : - adds missing VAT 0% export (goods) tax - correct erroneous fiscal position - reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration Task: 4453629 Forward-Port-Of: odoo/odoo#196738
Original PR description
This commit : - adds missing VAT 0% export (goods) tax - correct erroneous fiscal position - reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration Task: 4453629 Forward-Port-Of: odoo/odoo#196738
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a
Original PR description
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a CN and then change the journal on the CN wizard, the visibility and requirement of the fields should be adjusted as expected for the journal type selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192728
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#188171
Original PR description
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#188171
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreak
Original PR description
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreakable()` function has been updated to ensure that nav items (tabs) are treated as non-splittable elements. This prevents the tab from being split when the Enter key is pressed. Additionally, a test case has been added to cover the scenarios outlined in [commit]( https://github.com/odoo/odoo/commit/439e491608bab07f3f001d38b7774040a4b18980) as well to ensure the fix is effective. task-4316648 Forward-Port-Of: odoo/odoo#196159 Forward-Port-Of: odoo/odoo#193239
Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194191
Original PR description
Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194191
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current b
Original PR description
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current behavior before PR Before this commit, when we were in debug mode, we couldn't access Kiosk mode (white screen with message in console). This was because the props were not fully declared, and, in debug mode, we validated the props here : https://github.com/odoo/odoo/blob/c3e7ee585a58fc07c11d07677d1d64dbd357d6b7/addons/web/static/lib/owl/owl.js#L5715-L5717 As the components are only used in one place each, I've updated the props declaration to match the usage. Forward-Port-Of: odoo/odoo#189412
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#192586
Original PR description
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#192586
35 changes
Enhancements to existing features
Test coverage across several Odoo Enterprise apps was updated to match a change in how scheduled jobs are run directly. This keeps automated validation reliable and helps prevent regressions without changing day-to-day user workflows.
Original PR description
We need to adapt the calls to `method_direct_trigger` in tests. The method creates a new cursor now, so we need to be in test mode. task-4433571 odoo/odoo#193740
Subscription reminders now skip contracts that are not yet close enough to needing action. This reduces daily background processing for subscriptions where no reminder or closure is needed, improving efficiency without changing customer-facing behavior.
Original PR description
Before this commit, once the next_invoice_date was passed, the cron would process it everyday even if no reminder was necessary and the sub should not be closed. This commit ensure no contract is processed too soon. We decided to look for the minimal auto_close_limit value available and no contract is processed while his next_invoice_date + min_auto_close_limit is still in the future. This should reduce the amount of contract processed for "nothing". Once the auto_close_limit is passed, the contracts are still processed as they could be automatically closed before the 14 days delay is passed. task: 4295613
Belgian CODA bank statement imports now place note information directly in the transaction details. This makes payment information easier to review and helps users reconcile bank transactions with clearer context.
Original PR description
In this commit we will move the information that is placed in the note field in transaction details. task-4496857
This change updates an internal automated test to reflect recent behavior where related scheduled messages are removed when a record is deleted. It helps keep the document accounting test suite accurate and reduces false test failures, with no direct impact on end users.
Original PR description
Purpose: -------- In [this commit](https://github.com/odoo/odoo/commit/f9161cb), the messages scheduled on a record are now unlinked when unlinking this record (for models that inherit from `mail.thread`). This commit increases the query count in the test_move_document_unlink test accordingly. Task-4531402 [1]: https://github.com/odoo/odoo/commit/f9161cb7c132e97d78edef4a2a785f2bc3170b80
New automated tests verify that planning slot templates are visible only to the right types of users. This helps ensure project users, managers, portal users, and public users get the correct level of access and reduces the risk of unintended shift visibility.
Original PR description
This commit adds test cases to validate planning slot template visibility
based on user roles and project access:
1) Project user:
- Project user can access only specific planning slot template
2) Project manager:
Can access all planning slot templates
Moved in the planning module
3) Public and portal users:
Cannot access any shifts.
task: 4480509This update removes an obsolete styling reference from the Helpdesk portal templates. It has no expected impact on user workflows, but keeps the codebase cleaner and easier to maintain.
Original PR description
The SCSS for the `o_portal_contact_img` class was removed in a previous commit. As this class is no longer being used, it is safe to remove it from the codebase. Reff Commit- https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 task-3970088
Resolved issues and error corrections
This fix removes leftover references to a previously removed mobile field in several business workflows. It helps prevent errors or inconsistencies when using delivery integrations and Belgian reporting features after the earlier cleanup.
Original PR description
Missed few places during removal of mobile field See - https://github.com/odoo/enterprise/pull/75203 Task-4555229
The appraisal module’s sample scenario data was updated to match a recent change in how employees are linked to appraisal goals. This prevents setup or automated validation errors and helps ensure appraisal demo data loads correctly.
Original PR description
The commit https://github.com/odoo/enterprise/commit/dd90f66a536539 Changed the `employee_id` field to Many2Many but the change was not reflected in `hr_appraisal_scenario` data. This commit changes the data file to match the new field. Runbot Error: https://runbot.odoo.com/odoo/action-573/115164
Code cleanup and technical improvements
The way campaign activities are ordered in the marketing automation form has been simplified without changing the intended display behavior. This makes the underlying logic easier to maintain and adapt in future updates, reducing long-term maintenance risk.
Original PR description
The marketing campaign form view displays child activities sorted topologically, based on ancestry. However, the current implementation of the sorting algorithm is recursive, rendering it unclear and hard to read. This commit implements an easier-to-read sorting algorithm, which should be easier to port to new framework versions. task-3390523
This draft consolidates employee-related work order accounting into the manufacturing accounting area and removes unused work order code. It should make manufacturing cost reporting and valuation logic easier to maintain, with supporting test updates to protect existing behavior.
Miscellaneous changes
Currently the caret build with cutom groupby map could not work as there was a typo made during this commit: https://github.com/odoo/enterprise/commit/f8f7196030c257e3343b0725b5a0b3779d57c8ac task-4555964 Forward-Port-Of: odoo/enterprise#78725
Original PR description
Currently the caret build with cutom groupby map could not work as there was a typo made during this commit: https://github.com/odoo/enterprise/commit/f8f7196030c257e3343b0725b5a0b3779d57c8ac task-4555964 Forward-Port-Of: odoo/enterprise#78725
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team. Forward-Port-Of: odoo/enterprise#78760
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing
Original PR description
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the…
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton. This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner. To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets. ## Reference opw-4444078 Forward-Port-Of: odoo/enterprise#78765 Forward-Port-Of: odoo/enterprise#78087
*: l10n_cl_edi_pos, l10n_de_pos_res_cert, pos_preparation_display, l10n_it_pos, pos_restaurant_preparation_display, pos_settle_due Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime. Forward-Port-Of: odoo/enterprise#77915 Forward-Port-Of: odoo/enterprise#77812
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_res_cert, pos_preparation_display, l10n_it_pos, pos_restaurant_preparation_display, pos_settle_due Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime. Forward-Port-Of: odoo/enterprise#77915 Forward-Port-Of: odoo/enterprise#77812
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of:
Original PR description
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of: odoo/enterprise#78708 Forward-Port-Of: odoo/enterprise#73785
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78712 Forward-Port-Of: odoo/enterprise#73906
Original PR description
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78712 Forward-Port-Of: odoo/enterprise#73906
**Current behavior:** When a user wants to upload its VAT return to the French Government, they receive the following error message: ``` report_line_code = report_lines_code_per_id[report_line_id] ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^ KeyError: None ``` **Expected behavior:** The user should be able to upload their VAT return without any error message. **Steps to reproduce:** 1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n
Original PR description
**Current behavior:** When a user wants to upload its VAT return to the French Government, they receive the following error message: ``` report_line_code = report_lines_code_per_id[report_line_id]…
**Current behavior:**
When a user wants to upload its VAT return to the French Government, they receive the following error message:
```
report_line_code = report_lines_code_per_id[report_line_id]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: None
```
**Expected behavior:**
The user should be able to upload their VAT return without any error message.
**Steps to reproduce:**
1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n_fr_account`).
2. In the Settings, activate the Analytics option "Add totals below sections".
3. Go to Tax reports > Actions > EDI TVA > Send Report
**Cause of the issue:**
When the "Add totals below sections" parameter is enabled, the system will add new total lines on the report for each group of report lines. In the case of the Standard French VAT report, a single total line is added.
The issue is that before sending the report, the values are formatted by `_get_formatted_edi_values`. Each line to format is mapped to its corresponding line ID in line [255](https://github.com/odoo/enterprise/blob/0c32410b50b0edc2bc68c3199f741756b49600a2/l10n_fr_reports/wizard/l10n_fr_send_vat_report.py#L255): `report_line_id = self.report_id._get_model_info_from_id(line['id'])[-1]` Alas, for the new total lines, the line ID and its corresponding model are both None, which leads to an error on the next line. In version 17.0, there was a check for the model of the line, which was removed in version 18.0.
**Fix:**
- Add a check on the model of the line before formatting its values, to prevent the total lines from being formatted and sent.
opw-4496692
Forward-Port-Of: odoo/enterprise#77964Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match
Original PR description
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match the reused picking. Fix: - Override _compute_location_dest_id and update the location_dest_id if conditions are fulfilled. opw-4298443 Forward-Port-Of: odoo/enterprise#78729 Forward-Port-Of: odoo/enterprise#73895
Currently, an exception is generated while connecting to the bank. Error:- ``` TypeError: AccountOnlineLink.create_new_bank_account_action() missing 1 required positional argument: 'journal_type' ``` This is because of the latest changes were added from the below commit. https://github.com/odoo/enterprise/pull/70591/files#diff-72ccf5e061185b2d649fb844db777d7e229c31c38e1dc68283984a0772b481bfR384 A new argument `journal_type` was added in the `create_new_bank_account_action` method.
Original PR description
Currently, an exception is generated while connecting to the bank. Error:- ``` TypeError: AccountOnlineLink.create_new_bank_account_action() missing 1 required positional argument: 'journal_type' ``` This is because of the latest changes were added from the below commit. https://github.com/odoo/enterprise/pull/70591/files#diff-72ccf5e061185b2d649fb844db777d7e229c31c38e1dc68283984a0772b481bfR384 A new argument `journal_type` was added in the `create_new_bank_account_action` method. But forget pass that required argument in the ORM call in below lines. https://github.com/odoo/enterprise/blob/b588877a12f4952d02c747b230065c5b52f21e1a/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L68-L72 This leads to the above traceback. sentry-6248235685 Forward-Port-Of: odoo/enterprise#78587
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78622 Forward-Port-Of: odoo/enterprise#56896
Issue ===== The view is not inserted into the article, or the view link results in a traceback error. Steps ====== 1. Create a custom menu with its configuration using the model (Create a Menu). 2. Navigate to the custom menu action via the parent menu's route. 3. Use the actions to navigate to Knowledge > Insert view/link in article, then select an article (either existing or new). Technical ========= Due to a recent change introduced in this [commit](https://github.com/odoo/enter
Original PR description
Issue ===== The view is not inserted into the article, or the view link results in a traceback error. Steps ====== 1. Create a custom menu with its configuration using the model (Create a Menu). 2. Navigate to the custom menu action via the parent menu's route. 3. Use the actions to navigate to Knowledge > Insert view/link in article, then select an article (either existing or new). Technical ========= Due to a recent change introduced in this [commit](https://github.com/odoo/enterprise/commit/30c71b1fee8c91df5342b2b1ef5f6e888e84571d) the issue arises from the function 'this.actionService.loadAction' requiring either an actionxmlid or actWindow to process the action. Previously, only the actionxmlid was available, which caused the problem. The provided fix resolves this issue by ensuring both identifiers are correctly handled. Task-4437944 Forward-Port-Of: odoo/enterprise#76918
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module T
Original PR description
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module This will trigger the constraint: ``` psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "whatsapp_template_unique_name_account_template" DETAIL: Key (template_name, lang_code, wa_account_id)=(invoice, en, 1) already exists. ``` Forward-Port-Of: odoo/enterprise#78501
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like lea
Original PR description
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the…
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI. Steps to reproduce the error: - Create an uruguayan electronic invoice on a testing enviroment. - Select a product and change its unit price to 0. - Try to send & print the invoice, creating the CFE. - An error like this will be shown:  - Go back to the move and check that a banner with the error has been added at the top.  - Reset to draft, add a valid unit price and delete the "Taxes" column value. - Confirm, Send&Print the invoice. - A new pop up like this should raise:  - Go back to the invoice and check that the banner remains as before, showing an outdated error message. Forward-Port-Of: odoo/enterprise#77710
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the
Original PR description
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those…
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the same issue - didn't complained with it... But the "new" mode (which is actually closer to the actual GUI behavior of Chrome) got stuck at those steps. This commit fixes this issue by using the `private_street` field (which contains the actual street name) instead of the `private_street2` field (which is often empty). Once done, a second issue was detected as the step filling the computation of "58/4" didn't match (even wrongly) any empty field anymore. This commit simply removes those unused steps. Forward-Port-Of: odoo/enterprise#78626 Forward-Port-Of: odoo/enterprise#78397
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Original PR description
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#78318 Forward-Port-Of: odoo/enterprise#76686
Original PR description
Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#78318 Forward-Port-Of: odoo/enterprise#76686
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Original PR description
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78619 Forward-Port-Of: odoo/enterprise#78543
Original PR description
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78619 Forward-Port-Of: odoo/enterprise#78543
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
Original PR description
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
**Steps to Reproduce:** 1. Open a sign template. 2. Open a PDF. 3. Copy and paste a sign item. **Issue:** An error occurs when pasting a sign item. **Cause:** The saveChanges function was replaced with setTemplateChanged to manage the template's state, but the old function was still being referenced. **Solution:** Replace saveChanges with setTemplateChanged to ensure proper state management. task-4531219 Forward-Port-Of: odoo/enterprise#78258
Original PR description
**Steps to Reproduce:** 1. Open a sign template. 2. Open a PDF. 3. Copy and paste a sign item. **Issue:** An error occurs when pasting a sign item. **Cause:** The saveChanges function was replaced with setTemplateChanged to manage the template's state, but the old function was still being referenced. **Solution:** Replace saveChanges with setTemplateChanged to ensure proper state management. task-4531219 Forward-Port-Of: odoo/enterprise#78258
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330 Forward-Port-Of: odoo/enterprise#77592
Original PR description
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330 Forward-Port-Of: odoo/enterprise#77592
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947
Original PR description
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 BANK DETAILS: TEST12344 4) Confirm, print and send the invoice. 5) Check the pdf is created like this:  Expected behavior after this PR: The text on the "Adenda" section of the pdf should not print hidden characters. Forward-Port-Of: odoo/enterprise#76972
During odoo/enterprise@ca5a67c4faaf refactoring, the data file with default ICP for timesheet rounding/min duration was renamed but got removed from the manifest. This commit re-add it into the manifest. Forward-Port-Of: odoo/enterprise#77682
Original PR description
During odoo/enterprise@ca5a67c4faaf refactoring, the data file with default ICP for timesheet rounding/min duration was renamed but got removed from the manifest. This commit re-add it into the manifest. Forward-Port-Of: odoo/enterprise#77682
37 changes
Resolved issues and error corrections
Users in the Invoicing & Banks role can now access customer statements and partner ledger reports from partner records. This fixes a permissions gap so the new invoicing role can use the expected reporting tools without needing broader accounting access.
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208
Changing font size on underlined or strikethrough text now applies the sizing to the full styled text rather than only wrapping the inner characters. This keeps the underline or strikethrough visually aligned with the resized text for a more consistent editor experience.
Original PR description
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline remains the original size instead of scaling with the text. opw-3086072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale login flow now correctly returns from the screensaver without treating it as the prior screen. This prevents staff from getting stuck seeing the screensaver during employee login after the terminal has been idle.
Original PR description
Before this commit, when the login screen was left idle using an employee login, the screensaver would appear as expected. However, upon user interaction (e.g., moving the mouse), the system would update the previous screen to the screen saver. This causing issues during login where the screensaver would be displayed. opw-4494087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how eligible profit and loss accounts are filtered when configuring cash rounding. It ensures the account choices follow the intended rules consistently, reducing the chance of selecting an incorrect account.
Original PR description
The domain on the view overrides the domain on the model. As both domains are correct, this commit moves the partial domain on the view and adds it to the partial domain on the model. task-4514485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When Audit Trail is enabled, users who try to delete an incorrect payment now receive a more accurate error message. This avoids suggesting an unavailable archive option and helps users understand why the action is blocked.
Original PR description
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820
Users in the Invoicing & Banks group can now access customer statements and partner ledger reports from partner records. This fixes missing report access for the newer invoicing role, making day-to-day customer follow-up and account review smoother.
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208
The commissions report no longer displays a summed Achieved Rate when users group their commission records. This avoids showing an incorrect total for a percentage-based value, making grouped commission views clearer and less misleading.
Original PR description
Steps to reproduce: -Make multiple sales and assign a salesman to it in order to have a commission -Go to My Commissions -Add a Group By -The Achieved Rate column is displaying the sum of the achieved rates instead but it shouldn't display anything Problem: When making a group by on the commissions view and enabling the optional column achieved rate, the result of this group by would be the sum of all the achieved rate for this group, which is not correct. As it was decided that it made no sense, the total would not be displayed anymore. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/sale_commission/report/commission_report.py#L19 Fix: The aggregator parameter was used to prevent the total to be displayed. opw-4512739
This update cleans up an unusual indentation issue in the tax report code. It is a minor maintenance fix that helps keep the reporting module tidy and easier to maintain, with no expected change to business workflows.
Original PR description
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb
This fixes an issue where old error messages could remain visible after processing Uruguay electronic invoices. Users will see more accurate current status information, reducing confusion when reviewing invoices.
The Kenya payroll accounting demo data now assigns the required payroll journal before confirming demo payslips. This prevents demo installation and automated validation failures, helping test and demonstration environments load reliably.
Original PR description
In odoo 18.0 the `journal_id` on `hr.payroll.structure` [became not required](https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e#diff-761891fe4e3aa9cb1df74ffca5261004adaf8ac8c3df5857035953e5318be967L16-R16). And in the demo data for this module `action_payslip_done` is called, which [requires](https://github.com/odoo/enterprise/blob/4784d4a48d11c72afb05f2bc7c9062c5644bbf75/hr_payroll_account/models/hr_payslip.py#L53-L54) the payroll structure to have a journal. `hr_payroll_structure_ken_employee_salary` is used as the structure for all the payslips in the demo error in runbot [build](https://runbot.odoo.com/runbot/build/73486292)
The Studio report editor now shows the translation button again when editing a report source. This lets users translate report field labels directly from the editor, restoring expected access for multilingual reports.
Original PR description
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402
Code cleanup and technical improvements
This change removes an unused internal input from the HTML editor’s text paste handling. It simplifies the code and helps prevent future maintenance issues without changing the user experience.
Original PR description
**Reason**: After PR https://github.com/odoo/odoo/pull/196130, we discovered that the `selection` parameter of `pasteText` was unnecessary. It was not used before calling `insert`, and after that, the selection is outdated. The current selection should instead be retrieved from the selection plugin. **Change**: Remove the unused `selection` parameter from `pasteText`. opw-4558222 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
Letzdoo has formally signed Odoo's Contributor License Agreement. This confirms the company can contribute to Odoo under the required legal terms, supporting compliant future collaboration.
Original PR description
Sign the CLA in name of Letzdoo https://www.letzdoo.com --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-orde
Original PR description
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. opw-4225668 (This pr was merged but introduced an error with the test which was fixed in a separate pr: https://github.com/odoo/odoo/pull/186539) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186174 Forward-Port-Of: odoo/odoo#183601
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR https://github.com/odoo/odoo/pull/157412 modified the `_setUrlHash` method used to manage product attributes. One of the changes it made is modified the current URL using `window.location.hash` instead of `window.location.replace`. While both methods can make identical changes to the
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR…
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR https://github.com/odoo/odoo/pull/157412 modified the `_setUrlHash` method used to manage product attributes. One of the changes it made is modified the current URL using `window.location.hash` instead of `window.location.replace`. While both methods can make identical changes to the URL, a key side-effect of `Location:replace()` is that the URL being replaced won't get saved in the session's `History`[^1]. As this method is called the moment the page loads, modifying the URL via `location.hash` will store the initial product page URL without attribute hashes in the session history. Then when trying to navigate back, the method will be called again immediately to apply attribute hashes, again modifying the session history, making it virtually impossible to leave the page without clicking a new URL. Solution -------- Use `history.replaceState`[^2] to update the current state, and not create any new entries. opw-4416701 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/Location/replace [^2]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState Forward-Port-Of: odoo/odoo#194712
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all. ### Steps to reproduce: - In the settings, Enable "Multi-Step Routes" - Go to Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in 2 steps-manufacturing - Create a final product (FP) tracked by Serial number, and 2 storable components:
Original PR description
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the…
### Issue:
Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all.
### Steps to reproduce:
- In the settings, Enable "Multi-Step Routes"
- Go to Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in 2 steps-manufacturing
- Create a final product (FP) tracked by Serial number, and 2 storable components: COMP1 and COMP2
- Create a BOM for FP:
- Component lines:
- 1 x COMP1
- 0 x COMP2 !!
- Operations:
- OP1 with an instruction of type "register production"
1. Create an MO for 1 x FP > Confirm
2. Validate the pick transfer for 1 unit of COMP1
> Currently OP1 is marked as ready
3. Mark the component line of COMP1 as "picked"
#### > OP1 is in waiting status
Same result as 3:
3'. Go to the shopfloor > register production from the MO card
#### > This will pick the COMP1 raw move and OP1 will disappear because of the "ready" filter
### Cause of the issue:
Since you manufacture in 2 steps, the state of the raw move of COMP2 is waiting even though its demand is 0 (before and after you validated the pick move for COMP1). However, only non picked moves are considered to be relevant in the computation of the reservation state of the MO: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_production.py#L613-L621 Once you pick the COMP1 move which should be the only relevant one the reservation state of the MO becomes computed solely based on the state of the COMP2 raw move and becomes "waiting". In turns, this triggers a recomputation of the state of the workorders and flagging it as waiting: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_workorder.py#L148-L165
opw-4383004
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196517
Forward-Port-Of: odoo/odoo#196388The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#196702 Forward-Port-Of: odoo/odoo#195482
Original PR description
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#196702 Forward-Port-Of: odoo/odoo#195482
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a
Original PR description
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a CN and then change the journal on the CN wizard, the visibility and requirement of the fields should be adjusted as expected for the journal type selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192728
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196886 Forward-Port-Of: odoo/odoo#196835
Original PR description
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196886 Forward-Port-Of: odoo/odoo#196835
Behavior Before the Commit: Whenever you change the account type of a Cash and Bank account to a different type, please ensure that the Reconcile option is set to True. However, if you later switch the account type back to Cash and Bank, the Reconcile option will remain True and will not automatically revert to False. Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile method. Behavior After the commit: Reconcile will be changed to false o
Original PR description
Behavior Before the Commit:
Whenever you change the account type of a Cash and Bank account to a different type,
please ensure that the Reconcile option is set to True. However, if you later switch
the account type back to Cash and Bank, the Reconcile option will remain True and
will not automatically revert to False.
Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile
method.
Behavior After the commit:
Reconcile will be changed to false on changing the account type to Cash and Bank.
opw-4450088: https://www.odoo.com/odoo/my-support-tasks/4450088
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194358### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory > Configuration > Warehouse Management > Locations - Create 2 warehouse locations: WH/LOC1, WH/LOC2 - Go to the barcode app and proceed with the scans: 1. Scan the internal transfer picking type 2. Scan WH/STOCK as a source location 3. Scan the package name (PK) 4. Scan WH/LOC1 as
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory >…
### Steps to reproduce:
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable prodcut
- Update the on hand quantity:
- 10 units in package PK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans:
1. Scan the internal transfer picking type
2. Scan WH/STOCK as a source location
3. Scan the package name (PK)
4. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Try to validate the picking
#### > Invalid operation: You cannot move the same package content more than once in the same transfer or split the same package into two location.
### Cause of the issue:
As both pickings were treated via the barcode app, they generated picked move lines related to the package. Both of these move lines have updated the reserved quantity of the stock.quant present in stock:
- WH/STOCK, quantity: 10, reserved_quantity: 20.
When you try to validate the second picking, you will launch an `_action_done` of its move line that will create a new quant in WH/LOC2 and update the quant in stock:
- WH/STOCK, quantity: 0, reserved_quantity: 10.
- WH/LOC2, quantity: 10, reserved_quantity: 0.
The error is raised just after since 2 quants with either a quantity or reserved quantity are found:
https://github.com/odoo/odoo/blob/6349fb0362d881672616bb4b800bd32be82f9a5f/addons/stock/models/stock_move.py#L1910-L1917
### Fix:
Since the check is made in order to check the consistency of result packages moved by the current validation the "reserved_quantity" should not matter.
opw-4456484
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193214**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder (1st delivery for the 1st line, 2nd delivery for the 2nd line), then invoicing the delivered product separately result in an invoice with invoice lines which do not reflect the value of the product at delivery time. **Expected behavior:** The SVLs generated from the deliveries should info
Original PR description
**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder…
**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder (1st delivery for the 1st line, 2nd delivery for the 2nd line), then invoicing the delivered product separately result in an invoice with invoice lines which do not reflect the value of the product at delivery time. **Expected behavior:** The SVLs generated from the deliveries should inform the generated AccountMoves. **Steps to reproduce:** 1. `FIFO-prod`: FIFO and real-time valuation & costing 2. Receive 12 units of `FIFO-prod` @ $100 per 3. Create a sale order with order lines: * `FIFO-prod` `10 units` `price_unit=$100` * `FIFO-prod` `2 units` `price_unit=$100` 4. Confirm the sale order, on the delivery, only receive the first move for the 10 qty, backorder the other 2 qty 5. Receive the backorder, create an invoice- edit the invoice lines so that 5/10 of line 1 and 2/2 of line 2 are invoiced, then post/confirm 6. Edit the `standard_price` of `FIFO-prod` (e.g., $100 -> $50) 7. Create another invoice for the remaining quantity and post 8. Observe that the COGs lines on the invoice have been calculated with a different price unit than the other invoice & unit_price for the out SVLs **Cause of the issue:** When getting the price unit of a given anglo saxon invoice line, there is no check that all the collected COGS lines are linked to the sale order line which corresponds to the product and product_qty that we are attempting to value. This creates an imbalance in the qty calculation later here: https://github.com/odoo/odoo/blob/f2728b2fe13a355ecb301a3714639b8a07f418b4/addons/stock_account/models/stock_valuation_layer.py#L202-L211 when the valuation is actually performed. **Fix:** Only consider posted COGS lines for the sale order line with the product qty that is getting valued when calculating `qty_invoiced`. opw-4321363 Forward-Port-Of: odoo/odoo#196067 Forward-Port-Of: odoo/odoo#195046
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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-p
Original PR description
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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#194726 Forward-Port-Of: odoo/odoo#165333
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear o
Original PR description
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On…
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear on the XML file of an electronic invoice. Steps to reproduce: 1. Install Uruguay - Electronic Invoice module 2. Create EDI invoice, add special character to the description of the product you are using. Example used for testing (copy-paste it): 219179120011 3. Validate the invoice 4. Print and send it 5. Check "DscItem" field on the XML file created. Here is a one minute [video](https://drive.google.com/file/d/18JcnKCbaq7cH_NVyPol4CWXHdqZAxAdo/view) reproducing the error on runbot. Desired behavior after PR is merged: These characters are cleaned up at the xml level on cleanup_xml_node method to avoid them to appear and prevent errors when validating the XML on localizations web services. Related PR on v16 regarding the same issue in another context: https://github.com/odoo/odoo/pull/154509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193047
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
Original PR description
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still
Original PR description
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still match and it would be possible to go beyond 35 characters. In this commit, we fix this by using a full match instead of a match from the beginning. [opw-4357554](https://www.odoo.com/odoo/project.task/4357554) Forward-Port-Of: odoo/odoo#194583
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is
Original PR description
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. (forward port of https://github.com/odoo/enterprise/commit/d3606d5a99ba7328cce164c0c16ff594d7639f4a) opw-4225668 X-original-commit: https://github.com/odoo/odoo/commit/2d753a90d0612b35d9d012574915d2e6bb754b1f Forward-Port-Of: odoo/enterprise#74256
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpD
Original PR description
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each…
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly. 3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified. Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment. OPW-4256568 Forward-Port-Of: odoo/enterprise#77784 Forward-Port-Of: odoo/enterprise#74421
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
Original PR description
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like lea
Original PR description
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the…
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI. Steps to reproduce the error: - Create an uruguayan electronic invoice on a testing enviroment. - Select a product and change its unit price to 0. - Try to send & print the invoice, creating the CFE. - An error like this will be shown:  - Go back to the move and check that a banner with the error has been added at the top.  - Reset to draft, add a valid unit price and delete the "Taxes" column value. - Confirm, Send&Print the invoice. - A new pop up like this should raise:  - Go back to the invoice and check that the banner remains as before, showing an outdated error message. Forward-Port-Of: odoo/enterprise#77710
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Original PR description
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the
Original PR description
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those…
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the same issue - didn't complained with it... But the "new" mode (which is actually closer to the actual GUI behavior of Chrome) got stuck at those steps. This commit fixes this issue by using the `private_street` field (which contains the actual street name) instead of the `private_street2` field (which is often empty). Once done, a second issue was detected as the step filling the computation of "58/4" didn't match (even wrongly) any empty field anymore. This commit simply removes those unused steps. Forward-Port-Of: odoo/enterprise#78626 Forward-Port-Of: odoo/enterprise#78397
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Original PR description
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match
Original PR description
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match the reused picking. Fix: - Override _compute_location_dest_id and update the location_dest_id if conditions are fulfilled. opw-4298443 Forward-Port-Of: odoo/enterprise#73895
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947
Original PR description
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 BANK DETAILS: TEST12344 4) Confirm, print and send the invoice. 5) Check the pdf is created like this:  Expected behavior after this PR: The text on the "Adenda" section of the pdf should not print hidden characters. Forward-Port-Of: odoo/enterprise#76972
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
Original PR description
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821