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
This update brings the XML export for French Intrastat service declarations into Odoo 18.0. It helps French companies prepare service-related Intrastat reporting in the required electronic format, reducing manual work and improving compliance.
Original PR description
We backport this commit: https://github.com/odoo/enterprise/commit/07fe7cc37adc81691114de4cecf2f8334a09da37 in 18.0 Linked: https://github.com/odoo/upgrade/pull/7616 task-4402569
Brazilian POS orders now record a tax breakdown for each order line, making it easier for users to check whether taxes were charged correctly. This improves transparency and supports faster review of fiscal data without changing the sales flow.
Original PR description
Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950
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
Fixes an issue where accounting dashboard information could disappear for bank journals connected to online accounts, especially in branch/parent company setups. The update reuses the correct dashboard indicator and ensures credit journals also show the expected synchronization actions.
Original PR description
A previous commit 9b133b2cd03a726d330c87a1227903fc925b0ed5 restricted the view and actions we had on the accounting dashboard for a bank journal from a branch company, if the journal belongs to the parent company. In Odoo 17 the fix made sense, but in Odoo 18, the dashboard data added conflicts with another one, resulting in no data being displayed at all when the journal is connected to an online account. This PR adapts the initial fix to use the existing data (deprecate `show_bank_connect` in favor of `display_connect_bank_in_dashboard`) and adds the 'credit' type journal in the condition for `show_sync_action` to be used by the dashboard data.
**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
### Description: By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action. ### Reference: opw-4707551 Forward-Port-Of: odoo/enterprise#83296
Original PR description
### Description: By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action. ### Reference: opw-4707551 Forward-Port-Of: odoo/enterprise#83296
- Turn on Inter-company transactions. Select to sync invoices and bills in two companies. - Create an invoice in company A for an individual contact belonging to company B, then send and print the invoice. - In the corresponding bill in Company B, the draft bill is created without any attachment_ids. In the method _process_send_and_print from account_inter_company_rule the moves_with_attachements does not check if a partner belong to a synced company. opw-4675654 Forward-Port-Of: odoo/e
Original PR description
- Turn on Inter-company transactions. Select to sync invoices and bills in two companies. - Create an invoice in company A for an individual contact belonging to company B, then send and print the invoice. - In the corresponding bill in Company B, the draft bill is created without any attachment_ids. In the method _process_send_and_print from account_inter_company_rule the moves_with_attachements does not check if a partner belong to a synced company. opw-4675654 Forward-Port-Of: odoo/enterprise#83431
Steps to reproduce the bug: - Create a quality point with the following settings: - Measure on: Operation - Picking Type: Manufacturing - Product Category: "All" - Create a storable product “P1”: - Product Category: "All" - BoM: - components: - 1 unit of P1 - Create a manufacturing order to produce one unit of P1 - Confirm it Problem: The manufacturing order is confirmed, but the corresponding quality check is not created. This issue occurs when a quality
Original PR description
Steps to reproduce the bug: - Create a quality point with the following settings: - Measure on: Operation - Picking Type: Manufacturing - Product Category: "All" - Create a storable product “P1”: -…
Steps to reproduce the bug:
- Create a quality point with the following settings:
- Measure on: Operation
- Picking Type: Manufacturing
- Product Category: "All"
- Create a storable product “P1”:
- Product Category: "All"
- BoM: - components: - 1 unit of P1
- Create a manufacturing order to produce one unit of P1
- Confirm it
Problem:
The manufacturing order is confirmed, but the corresponding quality check is not created.
This issue occurs when a quality point is configured with "Measure on:
Operation". In that case, the quality check should be created for
manufacturing orders here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L49-L51
However, an empty record is passed for the product parameter.
As a result, the domain defined here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L19-L21
is evaluated with both product and category set to False, which
prevents the created quality point from being matched and thus no
quality check is created.
https://github.com/odoo/enterprise/blob/6ee3472937118e758399a9577251efad8c4c1195/quality_control/models/quality.py#L175-L177
opw-4762914
Forward-Port-Of: odoo/enterprise#84683- With l10n_mx_edi, create an invoice and send it to the cfdi. Download the cfdi xml. - Import the xml as a vendor bill. Confirm and click on Update SAT. - The vendor bill list view the l10n_mx_edi_cfdi_sat_state is set to false despite the l10n_mx_edi.document.sat_state being set. https://github.com/odoo/enterprise/commit/b34a4d105c67807628284257be51295e33da6bf0 added the ability to import cfdi xml as vendor bills and updated the selection for l10n_mx_edi.document.state with invoice_receiv
Original PR description
- With l10n_mx_edi, create an invoice and send it to the cfdi. Download the cfdi xml. - Import the xml as a vendor bill. Confirm and click on Update SAT. - The vendor bill list view the l10n_mx_edi_cfdi_sat_state is set to false despite the l10n_mx_edi.document.sat_state being set. https://github.com/odoo/enterprise/commit/b34a4d105c67807628284257be51295e33da6bf0 added the ability to import cfdi xml as vendor bills and updated the selection for l10n_mx_edi.document.state with invoice_received. However the compute _compute_l10n_mx_edi_cfdi_state_and_attachment which depends on l10n_mx_edi.document.state was not updated to take into account that new possible selection. opw-4673134 Forward-Port-Of: odoo/enterprise#84332 Forward-Port-Of: odoo/enterprise#83629
**Steps to reproduce:** - Install Accounting and l10n_lu_reports - Switch to a Luxembourgish company (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Set custom date from "01/01/2025" to "31/12/2025" - Export XML **Issue:** In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025". **Cause:** When generating the report values of that section, the options are recomputed with the co
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_lu_reports - Switch to a Luxembourgish company (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Set custom date from "01/01/2025" to "31/12/2025" - Export XML **Issue:** In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025". **Cause:** When generating the report values of that section, the options are recomputed with the comparison filter. This section is based on "Balance Sheet" report and recomputing the options of that report provides a different "from date" coming from "_init_options_date" method. **Solution:** Force the "from date" of the original options when using a custom range date. opw-4737810 Forward-Port-Of: odoo/enterprise#84959 Forward-Port-Of: odoo/enterprise#84672
Currently the "resend" mechanism relies on `_send`; marking messages to resend as "outgoing". However when used in batch mode `_send` only sends template messages. We enable `_send_cron` to send discuss messages too and to process these in priority. As these have a fixed time limit to be sent. We also do some filtering on resend to avoid marking messages that we know will fail as outgoing. Including "unrecoverable" errors and messages on outdated channel. Methods that use crons are a
Original PR description
Currently the "resend" mechanism relies on `_send`; marking messages to resend as "outgoing". However when used in batch mode `_send` only sends template messages. We enable `_send_cron` to send discuss messages too and to process these in priority. As these have a fixed time limit to be sent. We also do some filtering on resend to avoid marking messages that we know will fail as outgoing. Including "unrecoverable" errors and messages on outdated channel. Methods that use crons are also updated to use direct method trigger and prevent commits during tests to avoid having to patch them every time. task-3547088 Forward-Port-Of: odoo/enterprise#84887 Forward-Port-Of: odoo/enterprise#79050
Issue: Syntax error is raised when applying period comparison on partner ledger report. Purpose of this PR: Group queries with the parentheses. Steps to Reproduce in Runbot: - install accounting - add period comparison to Partner Ledger Report - try to apply period comparison opw-4730435 Forward-Port-Of: odoo/enterprise#84950 Forward-Port-Of: odoo/enterprise#83652
Original PR description
Issue: Syntax error is raised when applying period comparison on partner ledger report. Purpose of this PR: Group queries with the parentheses. Steps to Reproduce in Runbot: - install accounting - add period comparison to Partner Ledger Report - try to apply period comparison opw-4730435 Forward-Port-Of: odoo/enterprise#84950 Forward-Port-Of: odoo/enterprise#83652