Friday, May 9, 2025
70 changes
6 changes
Miscellaneous changes
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
Original PR description
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - F
Original PR description
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - From an EU company, create an invoice to a company in another EU country - Do not set an incoterm on the invoice - In settings, set a default incoterm on the company - Display the intrastat report for the time period of the invoice - Try to unfold the line corresponding to the invoice opw-4642781 Forward-Port-Of: odoo/enterprise#84734
Steps to reproduce the issue: - Create a quality check with any parameters - Add a future activity - Click on the activity icon in the top bar - The activity summary shows: - 0 Late, 0 Today, 1 Future - Click on "Late" Issue: No filter is applied and all quality checks are displayed. Solution: Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin. opw-4727840
Original PR description
Steps to reproduce the issue:
- Create a quality check with any parameters
- Add a future activity
- Click on the activity icon in the top bar
- The activity summary shows:
- 0 Late, 0 Today, 1 Future
- Click on "Late"
Issue:
No filter is applied and all quality checks are displayed.
Solution:
Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin.
opw-4727840
Forward-Port-Of: odoo/enterprise#84523In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
Original PR description
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar
Original PR description
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar_afip_ws_key_id field. Sentry - 5999498377 Forward-Port-Of: odoo/enterprise#83233
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to
Original PR description
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to the preparation display opw-4754522 Forward-Port-Of: odoo/enterprise#84870
19 changes
Enhancements to existing features
This update streamlines internal test setup for SMS, email, portal, rating, and mass mailing areas, making future checks easier to maintain. It also improves test tools for SMS status reporting and supports broader marketing automation coverage, reducing the risk of regressions without changing end-user behavior.
Original PR description
Continuing some cleaning in various test classes to lessen setup and/or have it done in as few places as possible. Improve some asserts tools. Task-4224145: [marketing_automation] Improve test coverage
Argentinian invoice reports now show the company logo at a larger size with a small spacing adjustment. This makes printed invoices look clearer and more professional for customers without changing invoice content or workflow.
Original PR description
Description of the issue/feature this PR addresses: Some of our clients have reported that the company logo on printed invoices is too small. This PR slightly increases its size and adds a small bottom margin. Current behavior before PR: The height in logo is 45px Desired behavior after PR is merged: Increases to 65px --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes an issue in the website recruitment page editor where deleting the “Apply Now!” button text could make the button impossible to edit after saving. Website editors can now safely clear and later update the button text without needing technical help.
Original PR description
Problem: When the "Apply Now!" button text is deleted (e.g., on `jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: Deleting all text inserts a zero-width space (ZWNS) with…
Problem: When the "Apply Now!" button text is deleted (e.g., on `jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: Deleting all text inserts a zero-width space (ZWNS) with `data-oe-zws-empty-inline` attribute. This is removed during save. Since the button has `data-oe-field="arch"` and no content, it's excluded from editable areas in `_getContentEditableAreas`, making it uneditable. This used to work in 17.0 due to the button inheriting `display: block` from its floated parent, adds `br` once content is cleared. Solution: Force `display: block` on the button so that when its text is deleted, a `<br>` is inserted, maintaining its editability. Steps to reproduce: 1. Go to `/jobs/experienced-developer-4`. 2. Open the web editor. 3. Delete the text "Apply Now!" inside the button. 4. Save the page. 5. Reopen the web editor. → The button is now uneditable. opw-4737255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an accounting error when Odoo calculates lock dates for companies that have been archived. It ensures archived parent companies are still considered, helping avoid unexpected crashes for users working with inactive company records.
Original PR description
Currently, when we are accessing the `parent_ids` of an archived company with code `company.sudo().parent_ids`, it will return an empty record, and an error will be generated when code tries to…
Currently, when we are accessing the `parent_ids` of an archived company
with code `company.sudo().parent_ids`, it will return an empty record, and an
error will be generated when code tries to access `max()` from that empty
record at code line [1].
```
>>> company = self.env['res.company'].browse(2)
>>> company
res.company(2,)
>>> company.active
False
>>> company.sudo().parent_ids
res.company()
>>> max(c.hard_lock_date or date.min for c in company.sudo().parent_ids)
Traceback (most recent call last):
File "/usr/lib/python3.12/code.py", line 90, in runcode
exec(code, self.locals)
File "<console>", line 1, in <module>
ValueError: max() iterable argument is empty
>>> max(c.hard_lock_date or date.min for c in
company.sudo().with_context(active_test=False).parent_ids)
datetime.date(1, 1, 1)
>>>
>>>
```
This commit fixes the above issue by setting `active_test=False`, which
allows access to `archived (inactive)` parent companies, ensuring that
`company.sudo().parent_ids` includes them and avoids passing an empty
sequence to max()
[1] - https://github.com/odoo/odoo/blob/ac3924508016178427c7962fa3b8e645e7e03835/addons/account/models/company.py#L393
sentry-6581609140Cancelled kitchen order tickets in Point of Sale now show the full product display name, including selected attributes. This helps kitchen staff correctly identify cancelled items when products have variants or custom attributes.
Original PR description
Steps to reproduce: ------------------------ - Install POS & setup kitchen printer. - Open session and make an order with instant creation mode attribute product. - Cancel the order. Issue: ------- - In the cancel KOT the attribute name wasn't visible. Cause: --------- - Wrong value passed for display name just simple name was passed instead of display name containing the attribute. FIX: ------ - Corrected the value passed for the display name. Task: 4720599
This fixes the printed Purchase Order layout so the totals section lines up correctly again. It reverts a prior report styling change that helped sales documents but unintentionally affected purchase documents.
Original PR description
## Version: 18.0+ ## Issue: Total section on Purchase Order document is misaligned. ## Steps to reproduce: - Go to Purchase: - Open a purchase order record; - Click on Print > Purchase Order. ## Cause: Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 ## Fix: Full style reverting opw-4771854
Knowledge article templates were updated so file attachments use the same structure as the current editor. This keeps built-in templates cleaner and more consistent without changing existing user content or requiring an upgrade.
Original PR description
This update is done without an upgrade because the old format will still work. But for cleanliness, templates should reflect what the editor will actually do, and since [This commit], files are `span` elements, not `div` anymore, and they are wrapped in a baseContainer (`div` or `p`). [This commit]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 task-4745902
The employee document shortcut now shows only documents the user is allowed to access. This prevents misleading counts and makes the button’s number match what users can actually open.
Original PR description
Previously the smartbutton showed the number of documents the user was a contact of, without checking if the user had access to such documents or not, resulting in sometimes different values Task: 4771754
Miscellaneous changes
ISSUE: When you remove the user from an employee all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model REPRODUCE: - create a vehicle and link it an employee with user - remove the user from the employee - employee and driver is removed from the vehicle As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior Task: 4680261 -
Original PR description
ISSUE: When you remove the user from an employee all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model REPRODUCE: - create a vehicle and link it an employee with user - remove the user from the employee - employee and driver is removed from the vehicle As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior Task: 4680261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209232 Forward-Port-Of: odoo/odoo#206396
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/s
Original PR description
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo…
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L18 when removing the event listener "this.onInput.bind(this)" creates another function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L22 As a consequence the event listener is not properly removed **Fix:** If the new function reference is created before in a variable the same function reference will be passed the two times and it will be properly removed opw-4711101 Forward-Port-Of: odoo/odoo#206478
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference: 5678 - Go to "Accounting / Vendors / Bills" - Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products: `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and `<cbc:Name>XYZ</cbc:Name>`
Original PR description
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference:…
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference: 5678 - Go to "Accounting / Vendors / Bills" - Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products: `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>5678</cbc:ID></cac:SellersItemIdentification>` **Issue:** The 2 invoice lines of the generated bill have the same exact product, even when 2 different codes are provided for the products. **Cause:** In "_retrieve_product" method, a search is made on the name, the code and the barcode, but an "OR" operator is applied. Not an "AND". Several products may satisfy the domain but only the first one is returned. **Solution:** If several products matches the conditions, instead of directly returning the first one, try to select one based on the following priority: barcode, code, name. opw-4466322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209048 Forward-Port-Of: odoo/odoo#205739
Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings
Original PR description
Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these…
Issue:
On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings on the first page takes 8 to 10s.
One of the issues found when analyzing the issue is that the 3 SQL queries performed on stock_move in the beginning of _get_report_lines are slow:
```
past_outs = self.env['stock.move'].search(AND([out_domain, past_domain]), order='priority desc, date, id')
future_outs = self.env['stock.move'].search(AND([out_domain, future_domain]), order='reservation_date, priority desc, date, id')
outs = past_outs | future_outs
ins = self.env['stock.move'].search(in_domain, order='priority desc, date, id')
```
Further analysis and testing show that using a domain with a negative condition ('not in') on the `state` column of stock_move prevents PostgreSQL from using the existing index on that column. By changing the condition in the domain to use a positive condition on that column, the execution time of each of the three queries goes from 1000-1500ms to about 100ms, saving about 3s on the total loading time of the page, which is still slow but a bit less.
Without patch:
```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 3.907 4.824
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 3.998 5.284
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 4.246 5.725
```
With patch:
```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 0.619 4.639
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 0.643 5.143
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 0.862 5.618
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207022This commit removes all files related to the session tour for survey. This tour has been maintained for years but sadly keeps breaking as it's very sensitive due to various reasons: - Mix of python code and multiple chained tours - Multiple "timing" components that are part of the session functional flow: - SVG charts animations for question answers - CSS animations when showing the leaderboard - Animations when going from one question to another We have already put a lot of eff
Original PR description
This commit removes all files related to the session tour for survey. This tour has been maintained for years but sadly keeps breaking as it's very sensitive due to various reasons: - Mix of python…
This commit removes all files related to the session tour for survey. This tour has been maintained for years but sadly keeps breaking as it's very sensitive due to various reasons: - Mix of python code and multiple chained tours - Multiple "timing" components that are part of the session functional flow: - SVG charts animations for question answers - CSS animations when showing the leaderboard - Animations when going from one question to another We have already put a lot of effort into fixing it in various versions, despite never touching the base survey code, only the test was broken, not the feature. It started failing yet again recently and the cause is (once again) obscure. Due to all these reasons, and the fact that survey is in "maintenance mode" and rarely modified to a significant degree, we believe it's best to get rid of it to focus on more important matters. Task-4778379 Side-note: Sorry Florian Charlier <flch@odoo.com> we have tried enough, it's time to let it go now :') Forward-Port-Of: odoo/odoo#208950 Forward-Port-Of: odoo/odoo#208757
Since [1], the website visitor update in the login process uses the request's environment, which might not yet have the user in the cursor for auto-provisioning modules like LDAP, where the user is created in a different cursor. Steps to reproduce: 1. Install auth_ldap & website 2. Configure the website to have the correct domain 3. Configure the LDAP connection to create users 4. Logout and navigate to a website page (to create a visitor) 5. Login with an LDAP user -> traceback 6. Logi
Original PR description
Since [1], the website visitor update in the login process uses the request's environment, which might not yet have the user in the cursor for auto-provisioning modules like LDAP, where the user is created in a different cursor. Steps to reproduce: 1. Install auth_ldap & website 2. Configure the website to have the correct domain 3. Configure the LDAP connection to create users 4. Logout and navigate to a website page (to create a visitor) 5. Login with an LDAP user -> traceback 6. Login again -> works After this commit: As the website visitor is not business-critical, the visitor is not updated to ensure no deadlock is reintroduced. opw-4378487 cc @thle-odoo [1]: https://github.com/odoo/odoo/commit/b241cf7de9329af1410b9dd45b161aa41926effb Forward-Port-Of: odoo/odoo#209016 Forward-Port-Of: odoo/odoo#203913
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958
Original PR description
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing
Original PR description
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing a unique constraint violation if the same name already exists. This PR removes `default_name` from the context. Task-3901336 Forward-Port-Of: odoo/odoo#208362
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity. # How to Reproduce - Create Subcontract BoM, with 1 cmp at $10 - Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10) - Scrap 1 unit of finished product => Journal ent
Original PR description
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the…
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity.
# How to Reproduce
- Create Subcontract BoM, with 1 cmp at $10
- Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10)
- Scrap 1 unit of finished product => Journal entry for scrapped layer contains 3 AML instead of 2 => The additional cost is incorrectly added to the Stock Valuation account, making the line balance at -$30, while the layer is still at -$20
OPW-4640650
---
Test result without fix:
```
2025-04-24 09:26:06,083 18424 ERROR oes_test_17 odoo.addons.mrp_subcontracting_account.tests.test_subcontracting_account: FAIL: TestAccountSubcontractingFlows.test_subcontracting_account_flow_1
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_subcontracting_account/tests/test_subcontracting_account.py", line 174, in test_subcontracting_account_flow_1
self.assertRecordValues(amls, [
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 3 records versus 2 expected values.
==== Differences at index 0 ====
---
+++
@@ -1,3 +1,3 @@
-account_id:300
-debit:60.0
-credit:0.0
+account_id:301
+debit:0.0
+credit:60.0
==== Differences at index 1 ====
---
+++
@@ -1,2 +1,2 @@
-account_id:299
-debit:30.0
+account_id:300
+debit:60.0
==== Additional record ====
{'account_id': 301, 'credit': 90.0, 'debit': 0.0, 'product_id': 107}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207204When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward
Original PR description
When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208276
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally
Original PR description
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a…
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally impossible. --- Steps to reproduce: 1. Install l10n_eu_oss and any oss member loca (be for example) 2. Use the company of the loca installed 3. Go to Accouting, Settings, click Refresh tax mapping. 4. Go to the fiscal positions and delete any oss fiscal position. 5. Go back to Accoutning, Settings, click Refresh tax mapping. 6. "Tax names must be unique!" error shows up. --- Desired behavior after this commit is merged: When creating the oss fiscal positions, a search is performed to gather the tax and its copies that use the desired name. The name of the new tax will be the name of the one with the most " (Copy)" in its name with one more " (Copy)". --- no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208985 Forward-Port-Of: odoo/odoo#208532