Friday, May 9, 2025
35 changes · 18.0
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
This update expands marketing automation testing to better cover WhatsApp, SMS, scheduling, rescheduling, and large-volume scenarios. It also fixes issues found during that work, helping campaigns react more reliably to customer messages, bounces, and timing changes.
Original PR description
Integrate whatsapp into marketing automation test tools and flow. Module marketing_automation_whatsapp has been added but is still not integrated into global marketing automation tests. Cover more…
Integrate whatsapp into marketing automation test tools and flow. Module marketing_automation_whatsapp has been added but is still not integrated into global marketing automation tests. Cover more activity types and scenarios, notably to spot corner cases currently badly covered. Added tests: whatsapp / sms types, opposite triggers (aka: cancel mail not open when mail is opened), rescheduling, scheduling for new participants / new activities, ... Add long awaited performance tests for marketing automation. As it may be quite a time consuming module by generating participants, traces for millions of records, better start with some performance tests in order to prepare work for some optimizations. Finally, fix various issues in marketing automation detected when writing tests. Task-4066243: [marketing_automation] Rescheduling issues Task-4224145: [marketing_automation] Improve test coverage Task-4759343: [marketing_automation] Integrate Whatsapp into MA test suite Prepares Task-4224152: [marketing_automation] Performance / Scalability
Resolved issues and error corrections
This fix prevents embedded items, such as files in Knowledge templates, from disappearing when an editable page is opened. It also keeps older or demo embedded file links working when they rely on a direct URL rather than a file identifier.
Original PR description
Prior to this commit, if an inline embedded component block was put as a direct child of the editable, it was removed during `initElementForEdition`, because `isVisible` returned false. However at…
Prior to this commit, if an inline embedded component block was put as a direct child of the editable, it was removed during `initElementForEdition`, because `isVisible` returned false. However at that point, the `embedded_component_plugin` did not yet have the opportunity to fill that embedded component. Therefore, as a prevention measure, all elements with `data-embedded` attribute will always be considered `visible`, as their removal should be at the discretion of the `embedded_component_plugin`. If they happen to have an `inline` style and they are direct children of the editable, they should be wrapped in a baseContainer `div` or `p`, but never removed. Issues of the type were observed when loading a Knowledge template containing a `div` with `data-embedded="file"` since embedded files have since been refactored to use an `inline-block` display style which made them eligible to be removed by `initElementForEdition` prior to the changes introduced in this commit. task-4745902
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
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-6581609140Invoices in foreign currencies now recalculate accounting amounts correctly when both the invoice date currency rate and line price are changed. This prevents journal entries from using an outdated price with a new exchange rate, improving financial accuracy.
Original PR description
**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date:…
**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date: date1 * Currency: EUR * Invoice line: [any] - Save the invoice - Check debit and credit amounts in "Journal Items" tab - Change the price of the product and set "Invoice Date" to date2 - Save the invoice - Check debit and credit amounts in "Journal Items" tab **Issue:** The debit and credit amounts have been recomputed with the new currency rate, but the conversion has been applied on the old price. **Cause:** In "_sync_invoice" method, when the currency rate has changed, balance (and subsequently debit/credit) is recomputed from amount_currency. However, in this case, balance should be recomputed completely because the line subtotal has changed and amount_currency is not up-to-date with it. **Solution:** Do not recompute balance based on amount_currency when price_subtotal of a line has changed. In that case, it will be recomputed anyway. opw-4658156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cancelled 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
Batch inventory adjustments no longer risk creating duplicate accounting journal entries. This helps keep inventory valuation and accounting records accurate when multiple stock adjustments are applied together.
Original PR description
Issue ----- Batch applying quantity adjustments creates duplicated journal entries. Steps to reproduce ----- - Create two products with automated valuation and 10 on hand quantity - Go to Inventory > Operations > Physical inventory and create an inventory adjustment for the two products (one positive, one negative) - Select both lines and click on "Adjust All" - Go to accounting > Accounting > Journal items -> Duplicated entries with one using the inventory valuation account and stock input and the other using the valuation account with stock output account Fix ----- This issue has been fixed by commit ce5d303 so just adding a small test to round things up. ----- Tickets: opw-4672011 opw-4677147 opw-4670069
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 dashboard has been corrected so it only includes employees from the user's company. This prevents figures from other companies from appearing in dashboard results, keeping reporting aligned with company access rules.
Original PR description
Commit odoo/odoo@abd909498e4fd relaxed the multi-company rule for hr.employee (more records are visible). Instead the action domains were updated to include the restricted company rules (see only from your company) The domains in the Employee dashboard was not updated though. It means the dashboard takes into account employees from other companies (as allowed by the ir.rule) opw-4777122
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
**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
The mx payment method on a payment should be the one from the pos payment method. Steps: - Have a PoS payment method with `l10n_mx_edi_payment_method_id` != `payment_method_transferencia` - Open a PoS session, make an order with this payment method and close the session - Look for the related payment --> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia` With this commit, we override the compute to get the payment way from the pos payment method. opw-4699064 Forward-Port-
Original PR description
The mx payment method on a payment should be the one from the pos payment method. Steps: - Have a PoS payment method with `l10n_mx_edi_payment_method_id` != `payment_method_transferencia` - Open a PoS session, make an order with this payment method and close the session - Look for the related payment --> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia` With this commit, we override the compute to get the payment way from the pos payment method. opw-4699064 Forward-Port-Of: odoo/enterprise#85001 Forward-Port-Of: odoo/enterprise#83323