Friday, February 7, 2025
24 changes · saas-17.2
Resolved issues and error corrections
Users can now sync appointment events to their calendar even when they do not have permission to view the related appointment type. This prevents missed calendar updates and keeps personal schedules accurate without changing broader access rights.
Original PR description
If a user has an appointment in an appointment type they may not read. They should still be able to sync it to their calendar. Related to this fix: e52b13c9fc9cb309351f527bfbe961fcb0fb961e task-4526059
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
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78553 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78553 Forward-Port-Of: odoo/enterprise#77423
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca
Original PR description
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77
Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
- First MO: 1 unit of P1
- Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis
Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.
opw-4529333
Forward-Port-Of: odoo/enterprise#78731Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`. Solution -------- When creating a SDD mandate transactions, display `tx.reference` as payment communication. opw-4380832 Forward-Port-Of: odoo/enterprise#78413
Facebook graph API may not respond in 5 seconds and result in issues with the social media account manager/posting/etc. Backport of: https://github.com/odoo-dev/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4164679 Forward-Port-Of: odoo/enterprise#77842
Original PR description
Facebook graph API may not respond in 5 seconds and result in issues with the social media account manager/posting/etc. Backport of: https://github.com/odoo-dev/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4164679 Forward-Port-Of: odoo/enterprise#77842
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
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#76111
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
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