Tuesday, March 18, 2025
65 changes
23 changes
Enhancements to existing features
Sales order-related screens were simplified across several Odoo apps by removing redundant hidden fields, duplicate view customizations, and obsolete filters. This should make the views easier to maintain while preserving the same business behavior for users.
Original PR description
* drop useless invisible fields (rely on ORM fallback, and js field dependencies when possible) * clean and harmonize xpaths definitions. Prefer the use of simplified xpath expressions when possible. * clean attributes overwrite, prefer using the add/remove API. Also remove the useless overwrites defining the same value as the base view. * Clean and harmonize files indentation, remove useless `<data>` nodes. * Remove empty domains from search filters. * merge views when targeting the same parent view (some views were targeting specific groups in the past, but this logic has been deprecated and removed from standard code). * target the shared parent view (between quotes and orders) for shared content, instead of adding the same content in the two inherited views. Related PRs: * odoo/odoo#167023 * odoo/enterprise#63350 * odoo/upgrade#6817
The update aligns Planning tests with a related web change that offers archiving when deletion is blocked. This helps ensure the Planning app continues to behave correctly when users cannot delete records and need an alternative action.
Original PR description
This commit adapts JS tests according to the changes done in the related community PR: https://github.com/odoo/odoo/pull/200414 task-4610830
Resolved issues and error corrections
This fix ensures debug settings are handled consistently during automated tests, preventing avoidable test failures. It helps maintain confidence in quality checks for Documents, Dashboards, and Studio without changing end-user functionality.
Original PR description
odoo.debug has to be a string. If an error is thrown in a test with a
patchWithCleanup(odoo, { debug: true/false });
an error of type "env.debug.includes is not a function" is thrown.
Task ID: 4655180Code cleanup and technical improvements
The spreadsheet global filter tests were reorganized and simplified so they run with only the needed components instead of loading the full web client flow. This reduces test runtime and memory use, helping development and validation complete faster without changing end-user features.
Original PR description
…bal filters tests This commit has two main goals: - Reduce memory usage/time of global filters tests - Move global filters tests to their module (from documents_spreadsheet to spreadsheet_edition)…
…bal filters tests This commit has two main goals: - Reduce memory usage/time of global filters tests - Move global filters tests to their module (from documents_spreadsheet to spreadsheet_edition) The tests have been refactored to use the minimum setup possible. Before this commit, tests were using the full setup with a web client, with a pivot view and then a click on "Insert in spreadsheet", then the rendering of the spreadsheet, then the opening of the global filters side panel. And only after that the test can begin. Now, we create a spreadsheet model and we mount only the components that are tests (the global filters side panel and the global filter editor). The tests are now faster and use less memory. | On runbot | Before | After | |------------------------------------------------|--------|-------| | Memory consumption of all JS tests, at the end | 880mb | 715mb | | Time to run this suite | 40s | 9s | Task: 4653513
Miscellaneous changes
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax re
Original PR description
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax return - An error occurs due to duplicate line IDs Issue originates from `append_country_and_taxes_lines`, which appends a new line with incorrect markup (using new line markup instead of the last line markup). opw-4629989 Forward-Port-Of: odoo/enterprise#81641
42 changes
Enhancements to existing features
Point of Sale orders can now be marked as eligible for mailing, allowing the system to send related communications when needed. This is a small internal improvement that supports better integration with Odoo's messaging features without changing the checkout experience.
Original PR description
Add `_mailing_enabled` flag on `pos.order` model to enable sending it. taskId: 4564577
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currenc
Original PR description
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency conversion introduces a exchange loss/gain, it is put back on the largest transaction of the entry. opw-4393164 Forward-Port-Of: odoo/enterprise#80622 Forward-Port-Of: odoo/enterprise#76828
**Steps to reproduce** - Install PoS, and select a Mexican company - Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog - Validate the order - Click on "Orders" and set the filter to "Paid" to see order O1 - Click O1, click "Refund", and from the product screen, click "Payment" Observed behavior: White screen with traceback in the console. **Issue** It's happening because in l10n_mx_edi_pos, an invoiced order is supposed to have fields `l10n_mx_edi
Original PR description
**Steps to reproduce** - Install PoS, and select a Mexican company - Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog - Validate the order - Click on "Orders"…
**Steps to reproduce** - Install PoS, and select a Mexican company - Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog - Validate the order - Click on "Orders" and set the filter to "Paid" to see order O1 - Click O1, click "Refund", and from the product screen, click "Payment" Observed behavior: White screen with traceback in the console. **Issue** It's happening because in l10n_mx_edi_pos, an invoiced order is supposed to have fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage` https://github.com/odoo/enterprise/blob/a0a97f2c87f76ae035394a67b09d71ec8f4567e7/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.js#L18-L21 And they are being accessed in the `product_screen.xml` https://github.com/odoo/enterprise/blob/0396d4f0ac33640dc042bb97e9e8d4b498e6a128/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.xml#L7-L12 That works for the original ordre (aka O1), however, when the refund order is created, we set its `to_invoice` to `true` if the original order is invoiced ([code](https://github.com/odoo/odoo/blob/53e7c0adf093dc950a42989a56b4594f734c17b2/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L69-L75)), but we don't set any values to the fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage`, causing the crash in the payment screen. **Fix** If the refund order is invoiced, we set the `l10n_mx_edi_usage` to "G02" which corresponds to 'Returns, discounts or bonuses' (assuming that a refund can be seen as a 'return' here). We also copy the field `l10n_mx_edi_cfdi_to_public` from the original order. opw-4608630 Forward-Port-Of: odoo/enterprise#80664
Direct Debit payment notification email was always sent in english regardless of customer language. **Steps to reproduce:** * Configure SDD creditor identifier in accounting settings * Bank Journal should have valid bank account * Customer record have different language than user's language and have valid IBAN bank account * Create Direct Debit mandate for this customer * Pay an invoice for this customer with SDD payment method * Create batch payment for this payment and validate it. *
Original PR description
Direct Debit payment notification email was always sent in english regardless of customer language. **Steps to reproduce:** * Configure SDD creditor identifier in accounting settings * Bank Journal should have valid bank account * Customer record have different language than user's language and have valid IBAN bank account * Create Direct Debit mandate for this customer * Pay an invoice for this customer with SDD payment method * Create batch payment for this payment and validate it. * The payment notification email should be sent on payment chatter with wrong language. Video: https://drive.google.com/file/d/1jzlALs4SJRtOA5gPBt_xo0m8r7kpZd_m/view opw-4552438 Forward-Port-Of: odoo/enterprise#81490
## Purpose - When paying from the portal a quotation for a subscription starting in the past, or in the future, the deadline is incorrectly set which leads in a duplication of the quantities when creating the invoice. - Removal of the banner indicating the cron will run as not needed anymore Task: 4571168 Forward-Port-Of: odoo/enterprise#81304 Forward-Port-Of: odoo/enterprise#79828
Original PR description
## Purpose - When paying from the portal a quotation for a subscription starting in the past, or in the future, the deadline is incorrectly set which leads in a duplication of the quantities when creating the invoice. - Removal of the banner indicating the cron will run as not needed anymore Task: 4571168 Forward-Port-Of: odoo/enterprise#81304 Forward-Port-Of: odoo/enterprise#79828
Before this commit, the `test_smart_schedule_with_allocated_hours_and_deadlines` test fails when only `project_enterprise` module is installed because the allocated_hours on the tasks are recomputed. However, when timesheet_grid module is installed, the project inside the test has the timesheets feature enabled by default and so the allocated_hours are not recomputed because we suppose the allocated_hours on tasks inside that project can only be altered by the user when the tasks are already cre
Original PR description
Before this commit, the `test_smart_schedule_with_allocated_hours_and_deadlines` test fails when only `project_enterprise` module is installed because the allocated_hours on the tasks are recomputed. However, when timesheet_grid module is installed, the project inside the test has the timesheets feature enabled by default and so the allocated_hours are not recomputed because we suppose the allocated_hours on tasks inside that project can only be altered by the user when the tasks are already created. This commit checks in the test is timesheet_grid module is installed to give the right expected allocated_hours on tasks. runbot-108336 Forward-Port-Of: odoo/enterprise#81387 Forward-Port-Of: odoo/enterprise#79947
For the Reload DIAN Configuration button, a newly added class modifies the `colspan` of the surrounding `<div>`, forcing it to `colspan="1"` and causing the fields to be positioned next to the button incorrectly. **To Reproduce:** 1. Install the Accounting app and the `l10n_co_dian` module. 2. Navigate to Accounting > Configuration > Journals. 3. Open a Sales or Purchase Journal. 4. Observe that some localization fields are missing, misplaced, or unreadable. Community PR: odoo/odoo#201
Original PR description
For the Reload DIAN Configuration button, a newly added class modifies the `colspan` of the surrounding `<div>`, forcing it to `colspan="1"` and causing the fields to be positioned next to the button incorrectly. **To Reproduce:** 1. Install the Accounting app and the `l10n_co_dian` module. 2. Navigate to Accounting > Configuration > Journals. 3. Open a Sales or Purchase Journal. 4. Observe that some localization fields are missing, misplaced, or unreadable. Community PR: odoo/odoo#201227 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4601714) opw-4601714 Forward-Port-Of: odoo/enterprise#81173
Steps to reproduce: - create two companies - create two analytic account (no company defined) - create for company B an analytic distribution model with one of the analytic account and define company A as parter - With Company A, create an invoice and on the line use the other analytic account and confirm Issue: The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line Cause: In the _get_distribution
Original PR description
Steps to reproduce: - create two companies - create two analytic account (no company defined) - create for company B an analytic distribution model with one of the analytic account and define company A as parter - With Company A, create an invoice and on the line use the other analytic account and confirm Issue: The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line Cause: In the _get_distribution method, the partner is incorrectly set to Company B, leading to this issue. opw-4414850 Forward-Port-Of: odoo/enterprise#80954 Forward-Port-Of: odoo/enterprise#76395
To reproduce the issue: 1) Install l10n_es_reports 2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view) 3) Create an invoice with two lines of 100€, so that - both lines use both IVA21% and WHI 1% taxes - one of those lines defines an anlaytic distribution while the other doesn't 4) Open the generic tax report, and generate the VAT Record Books XLSX export ===> In that file, the amount of withholding is 15€. It should be 30€
Original PR description
To reproduce the issue:
1) Install l10n_es_reports
2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view)
3) Create an invoice with two lines of 100€, so that
- both lines use both IVA21% and WHI 1% taxes
- one of those lines defines an anlaytic distribution while the other doesn't
4) Open the generic tax report, and generate the VAT Record Books XLSX export
===> In that file, the amount of withholding is 15€. It should be 30€.
The same issue can be reproduced for surcharge taxes, in the same way.
This is due to the fact different analytic distributions between base lines will trigger the creation of different tax lines for the same tax (one for each distribution). The code handling the export "saw" both lines, but ovewrote the total instead of summing all the values.
opw-4471253
Forward-Port-Of: odoo/enterprise#81375opw-4592126 Forward-Port-Of: odoo/enterprise#81324
Original PR description
opw-4592126 Forward-Port-Of: odoo/enterprise#81324
Add missing search and tree vues of sale.commission.plan.user Allow to filter achievements by users Display target amount from the plan on commissions. Task: 4633303 Forward-Port-Of: odoo/enterprise#81511 Forward-Port-Of: odoo/enterprise#80978
Original PR description
Add missing search and tree vues of sale.commission.plan.user Allow to filter achievements by users Display target amount from the plan on commissions. Task: 4633303 Forward-Port-Of: odoo/enterprise#81511 Forward-Port-Of: odoo/enterprise#80978
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------
Original PR description
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------------ We should base the payment type on the payment method type and not on the payment method name. opw-4606731 Forward-Port-Of: odoo/enterprise#80995 Forward-Port-Of: odoo/enterprise#80919
It doensn't work to scan a lot in the kanban view of stock.barcode. It's not recognize since the company_id is not required on the lot since 18.0 but the domain was not adapt and expect it. opw-4626206 Forward-Port-Of: odoo/enterprise#81351
Original PR description
It doensn't work to scan a lot in the kanban view of stock.barcode. It's not recognize since the company_id is not required on the lot since 18.0 but the domain was not adapt and expect it. opw-4626206 Forward-Port-Of: odoo/enterprise#81351
- Sign > Templates > Click on any of the kanban record - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, on reloading the sign template page user was redirected back to kanban view. This occurs because, the client action 'sign.Template' required template_id (found in the context) that was lost when reloading. Now, template_id is put in the query string of the URL, in that way, when reloading, the client ac
Original PR description
- Sign > Templates > Click on any of the kanban record - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, on reloading the sign template page user was redirected back to kanban view. This occurs because, the client action 'sign.Template' required template_id (found in the context) that was lost when reloading. Now, template_id is put in the query string of the URL, in that way, when reloading, the client action 'sign.Document' will have the needed template_id. Note that, this is also the behavior of the base_import 'ImportAction' action [1]. task-4391729 [1] : https://github.com/odoo/odoo/pull/182744/commits/a6801ce4aa65cd023e2a762ab5c42755a4599c95 Forward-Port-Of: odoo/enterprise#80776 Forward-Port-Of: odoo/enterprise#77400
Steps to reproduce: * Customer record has language different than user's language. * Customer form view -> Accounting Tab -> Invoice follow-ups -> Send * Check sms checkbox * sms template in user's language, it should be in customer's languange. opw-4599660 Forward-Port-Of: odoo/enterprise#81382
Original PR description
Steps to reproduce: * Customer record has language different than user's language. * Customer form view -> Accounting Tab -> Invoice follow-ups -> Send * Check sms checkbox * sms template in user's language, it should be in customer's languange. opw-4599660 Forward-Port-Of: odoo/enterprise#81382
Steps to reproduce the bug: - Enable “Signature” option in inventory settings - Go to barcode → delivery orders > batch: - select any batch: - settings: - Operations > sign: - Sign and validate Problem: A traceback is triggered: “ValueError: Invalid field 'signature' on model 'stock.picking.batch'” Solution: It is not possible to sign a batch picking, so the button should not displayed. opw-4610471 Forward-Port-Of: odoo/enterprise#81051
Original PR description
Steps to reproduce the bug: - Enable “Signature” option in inventory settings - Go to barcode → delivery orders > batch: - select any batch: - settings: - Operations > sign: - Sign and validate Problem: A traceback is triggered: “ValueError: Invalid field 'signature' on model 'stock.picking.batch'” Solution: It is not possible to sign a batch picking, so the button should not displayed. opw-4610471 Forward-Port-Of: odoo/enterprise#81051
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained abo
Original PR description
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained above which contains the identifier of the move. We now save this identifier and use it in the automatic GetStatus call to get odoo and DIAN back in sync. ticket: 4569829 Forward-Port-Of: odoo/enterprise#81350
In this commit, we add a delay to ensure Gantt view will correclty be loaded after clicking on Gantt view button. This allow to fix an indeterministic behavior that can occurs in restaurant_appointment_tour tour. Forward-Port-Of: odoo/enterprise#81562
Original PR description
In this commit, we add a delay to ensure Gantt view will correclty be loaded after clicking on Gantt view button. This allow to fix an indeterministic behavior that can occurs in restaurant_appointment_tour tour. Forward-Port-Of: odoo/enterprise#81562
Specs: When documents are in the trash folder, no actions are required except for the Download button, which remains visible. After this commit: Remove action buttons in the trash folder. Task-4574919 Forward-Port-Of: odoo/enterprise#81206 Forward-Port-Of: odoo/enterprise#79644
Original PR description
Specs: When documents are in the trash folder, no actions are required except for the Download button, which remains visible. After this commit: Remove action buttons in the trash folder. Task-4574919 Forward-Port-Of: odoo/enterprise#81206 Forward-Port-Of: odoo/enterprise#79644
Point of Sale payment methods linked to bank journals now automatically use the appropriate outstanding account. This reduces manual setup work and helps keep payment accounting consistent.
Original PR description
- Automatically assigns the outstanding account for payment methods using bank journals. task-id: 4600008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents the web interface from crashing when a record contains a related record ID but is missing the related model information. Instead of failing, Odoo now treats the missing relationship as no related record, improving reliability for affected users.
Original PR description
Having a record with set res_id but no res_model doesn't mean much, but we can consider, in web_read, that it means that there is no related record to avoid crashes. opw-4527152
Users who have been granted access to bills of material can now open them without hitting an attachment-related error. This makes custom access setups more reliable without requiring extra development work.
Original PR description
### Steps to reproduce 1. Create a new group 2. Give the group access to the following models: - `mrp.bom` - `mrp.bom.line` - `mrp.routing.workcenter` - `product.document` 3. Create a new menu using studio to access `mrp.bom` directly 4. Create a new user with the newly created group 5. Sign-in with this user and go on a BoM 6. AccessError ### Before this commit: Users without the `mrp.group_mrp_user` group cannot display bills of material, even if we add the necessary access rights. The record loads without issue, but the chatter displays an error when loading the attachments, due to strict group access on the field `attached_on_mrp`. ### After this commit: Remove the group from the field and move it into the view. This allows easier and more flexible access rights to the BoM without writing any custom code. opw-4538532
Fixed a configuration issue in the Indian withholding tax module that was causing automated validation to fail. This helps keep the module stable and prevents avoidable deployment or upgrade blockers.
Original PR description
In this commit-
We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614)
```py
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_in_withholding'
View: tds_entry_view_form
Fields:
<field name="currency_id" column_invisible="True"/>
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where manually created company-specific fields did not keep their company-dependent behavior. Businesses using custom fields can now rely on values being stored separately per company as intended.
Original PR description
The field attribute `company_dependent` is not passed when instanciating manual fields so they do not get created as jsonb columns and lose the company dependent property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal signing flow now handles customers or contacts that do not have a standard name without failing. This prevents users from hitting an error when previewing and signing sales quotations for such contacts.
Original PR description
Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `SignatureForm` initialization, `onMounted` raise a traceback, because it calls directly `this.signature.resetSignature`. This commit adds default functions to `resetSignature` and `getSignatureImage` to prevent the crash. opw-4504223
Exporting products by category with only the external ID field selected no longer causes an error. This keeps product data exports reliable for users who need external IDs for integrations or reporting.
Original PR description
Steps: - Install sales app. - Go to product menu and group list view by category - Export products with only `Product/Product/External ID` Issue: - Traceback. Cause: - Directly try to access `type` key from dict without checking dict contain `type` key or not. Before [this] PR we were checking if it contain type or not. Fix: - Check dictionary contain `type` or not. [this]: https://github.com/odoo/odoo/pull/178214 opw-4585879
This fixes automated web tours so steps using shared helper actions still perform the expected page-unload safety check. It helps make tour execution more reliable and reduces missed issues during automated testing.
Original PR description
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the beforeUnload event that is done. In this commit, we fix this. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish SII electronic invoicing demo certificates were replaced because the previous ones had expired and were causing automated validation tests to fail. This keeps the demo/test setup working reliably and aligns certificate naming with related Spanish localization components.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix helps accounting keep zero-value tax lines when they are needed for correct tax repartitioning. It reduces the risk of missing tax details in invoices or accounting entries, supporting more accurate reporting and compliance workflows.
Original PR description
opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
Some internal system labels in the Base module were incorrectly eligible for translation. This fix keeps those strings unchanged across languages, reducing confusion in configuration screens and ensuring consistent technical labels.
Original PR description
The Documents file viewer now stays correctly positioned when users scroll horizontally, including in grouped views. This prevents misplaced previews and provides a more consistent document viewing experience.
Original PR description
Previously, the file viewer was misaligned when scrolling horizontally, causing incorrect placement. This fix ensures that the file viewer remains properly positioned, even when scrolling, for a consistent viewing experience. Task-4531591
The automated test for the signing flow now closes the final confirmation window instead of trying actions that trigger a download or do not fit the test purpose. This prevents timeout failures and keeps the signing process validation stable after related platform changes.
Original PR description
In this commit, we fix the latest step of tour. We can't click on primary or secondary button ... make no sense. As the primary button download the pdf file and there is no test to ensure the file is well downloaded, it make more sense to click on close the modal. With the fix in https://github.com/odoo/odoo/pull/202089 and without the correction, the tour was timeout exceeded.
Payment notification emails for SEPA Direct Debit are now sent in the customer’s preferred language instead of always defaulting to English. This helps customers receive clearer, localized communication when direct debit payments are processed.
Original PR description
Direct Debit payment notification email was always sent in english regardless of customer language. **Steps to reproduce:** * Configure SDD creditor identifier in accounting settings * Bank Journal should have valid bank account * Customer record have different language than user's language and have valid IBAN bank account * Create Direct Debit mandate for this customer * Pay an invoice for this customer with SDD payment method * Create batch payment for this payment and validate it. * The payment notification email should be sent on payment chatter with wrong language. Video: https://drive.google.com/file/d/1jzlALs4SJRtOA5gPBt_xo0m8r7kpZd_m/view opw-4552438
Code cleanup and technical improvements
This draft pull request appears to reorganize or clean up internal code related to Brol. No specific user-facing changes or affected Odoo modules are provided, so the expected business impact is limited until more details are available.
Miscellaneous changes
Steps to reproduce: - Go to Accounting > Customers > Invoices - Insert the list into a spreadsheet - in any cell, type `=ODOO.LIST(1,1,"company_currency_id")` => the currency is not displayed. The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing. Task: 4633078 --- I confirm I have signed the CLA and
Original PR description
Steps to reproduce: - Go to Accounting > Customers > Invoices - Insert the list into a spreadsheet - in any cell, type `=ODOO.LIST(1,1,"company_currency_id")` => the currency is not displayed. The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing. Task: 4633078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200886 Forward-Port-Of: odoo/odoo#200663
- On a view with a company-dependent field with a `many2many_tags` widget, where the `edit_tags` option is set to `true`; - Click on a tag; - Change the company; - Save the tag; - Open the same tag again; A traceback error is displayed. This error occurs because, since [1], when loading the form view the access errors are handled, the company is added to the selected companies and the record is reloaded. The issue is that this cannot be done with a dialog form view, not only is an unreach
Original PR description
- On a view with a company-dependent field with a `many2many_tags` widget, where the `edit_tags` option is set to `true`; - Click on a tag; - Change the company; - Save the tag; - Open the same tag again; A traceback error is displayed. This error occurs because, since [1], when loading the form view the access errors are handled, the company is added to the selected companies and the record is reloaded. The issue is that this cannot be done with a dialog form view, not only is an unreachable action service function is called, but also the dialog is not reopened when reloading. In this commit, we fix this by showing the access error. Forward-Port-Of: odoo/odoo#202222
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positi
Original PR description
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positive quantity - Confirm manufacturing order - Pick components - Produce & close MO opw-4620008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202159 Forward-Port-Of: odoo/odoo#201619
- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201680 Forward-Port-Of: odoo/odoo#201230
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fi
Original PR description
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fiscale if the VAT field is filled, and it starts with 'IT' or the country selected is Italy. Task [link](https://www.odoo.com/odoo/project/967/tasks/4596227) task-4596227 Forward-Port-Of: odoo/odoo#202046 Forward-Port-Of: odoo/odoo#199876
Before this commit, if an IoT connected customer display was activated without a valid HTTPS certificate, it would fail as the IoT box would not trust accessing its own endpoint, due to the request using https://<iot_box_ip>. After this commit, the proxy display instead uses http://localhost, so the certificate is not requirec and the customer display functions as expected. task-4648702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
Before this commit, if an IoT connected customer display was activated without a valid HTTPS certificate, it would fail as the IoT box would not trust accessing its own endpoint, due to the request using https://<iot_box_ip>. After this commit, the proxy display instead uses http://localhost, so the certificate is not requirec and the customer display functions as expected. task-4648702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202023
Issue ----- When the user clicks on "Continue Shopping" without providing a value for the selected variant, they get a Traceback. Steps to reproduce ----- - Install the ECommerce app - Create an "Att" attribute - Set its' Display Type to "Select" - Add 2 values, 1 & 2 - Set value 1 to Free text - Create a new product "Trace" - Add "Att" as an attribute with values 1 & 2 - Go to the Website - Open the Shop page - Edit the page to add the cart button to pro
Original PR description
Issue ----- When the user clicks on "Continue Shopping" without providing a value for the selected variant, they get a Traceback. Steps to reproduce ----- - Install the ECommerce app - Create an…
Issue
-----
When the user clicks on "Continue Shopping" without providing a value for the
selected variant, they get a Traceback.
Steps to reproduce
-----
- Install the ECommerce app
- Create an "Att" attribute
- Set its' Display Type to "Select"
- Add 2 values, 1 & 2
- Set value 1 to Free text
- Create a new product "Trace"
- Add "Att" as an attribute with values 1 & 2
- Go to the Website
- Open the Shop page
- Edit the page to add the cart button to products & Save
- Click on the cart button of the "Trace" product
- Select the 1 variant
- Click the "Continue Shopping" button without entering a custom value
-> Traceback
Cause
-----
In website_sale_product_configurator, we append to the attribute array even when
there is no custom value provided by the user. When the Python code tries to
access the value, it creates an error because there is no 'custom_value' key.
Solution
-----
Only search for a product template attribute variant when a value is provided.
-----
Ticket:
opw-4535469
Forward-Port-Of: odoo/odoo#197657Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202162 Forward-
Original PR description
Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202162 Forward-Port-Of: odoo/odoo#202115
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was creat
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was created, trying to cancel will say you're not allowed to read journal entries. You are supposed to get an error when trying to modify journal entries. Cause ----- The cancel wizard doesn't check the order's invoices using sudo. Solution -------- Check the order's invoices using sudo. opw-4554639 Forward-Port-Of: odoo/odoo#201785
**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201903 Forward-Port-Of: odoo/odoo#179345
Original PR description
**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201903 Forward-Port-Of: odoo/odoo#179345
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200821 Forward-Port-Of: odoo/odoo#195305
When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guideli
Original PR description
When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202055
**Steps to reproduce:** - Install Accounting and l10n_it_edi_withholding - Switch to an Italian company (e.g. IT Company) - Import an electronic Italian invoice (XML) containing an element like: ```xml <DettaglioLinee> <NumeroLinea>2</NumeroLinea> <Descrizione>Contributo ENASARCO</Descrizione> <PrezzoUnitario>0.00</PrezzoUnitario> <PrezzoTotale>0.00</PrezzoTotale> <AliquotaIVA>22.00</AliquotaIVA> <AltriDatiGestionali> <TipoDato>CASSA-PREV</TipoDato>
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi_withholding - Switch to an Italian company (e.g. IT Company) - Import an electronic Italian invoice (XML) containing an element like:…
**Steps to reproduce:**
- Install Accounting and l10n_it_edi_withholding
- Switch to an Italian company (e.g. IT Company)
- Import an electronic Italian invoice (XML) containing an element like:
```xml
<DettaglioLinee>
<NumeroLinea>2</NumeroLinea>
<Descrizione>Contributo ENASARCO</Descrizione>
<PrezzoUnitario>0.00</PrezzoUnitario>
<PrezzoTotale>0.00</PrezzoTotale>
<AliquotaIVA>22.00</AliquotaIVA>
<AltriDatiGestionali>
<TipoDato>CASSA-PREV</TipoDato>
<RiferimentoTesto>TC07 - ENASARCO</RiferimentoTesto>
<RiferimentoNumero>10.03</RiferimentoNumero>
</AltriDatiGestionali>
</DettaglioLinee>
```
**Issue:**
1) When the above ENASARCO element is present and its unit price is 0, we consider that the ENASARCO tax should be applied to each line. We try to retrieve the percentage of the ENASARCO tax used by computing it from the amount from <RiferimentoNumero> element and the untaxed amount of the invoice.
Then the ENASARCO tax is applied on all the current move lines. However, it is possible that all the move lines have not been imported yet and the tax will not be applied on all the lines.
2) If a ENASARCO tax has been set on a particular move line with a unit price of 0, the tax is applied to all the move lines, but it shouldn't.
3) When a global ENASARCO element is found in a move line, this move line is deleted, which can cause an error if the ENASARCO tax cannot be found in the database because a message is logged with the move line name.
**Solution:**
1-2. In "_l10n_it_edi_import_line" method, we had the ENASARCO tax to the current line by computing the tax rate with the unit price of the line if it is not 0.
Then, in "_l10n_it_edi_import_invoice" method, we parse the XML to check if there was a unique ENASARCO element with an amount and without unit price.
If it is the case, we considered the ENASARCO tax as global. Instead of using the untaxed amount of the invoice to compute the rate of the ENASARCO tax used, we should be able to retrieve the real taxable amount in a <DatiRiepilogo> element.
There should be an element like:
```xml
<DatiRiepilogo>
<AliquotaIVA>22.00</AliquotaIVA>
<ImponibileImporto>117.97</ImponibileImporto>
<Imposta>25.95</Imposta>
<EsigibilitaIVA>I</EsigibilitaIVA>
</DatiRiepilogo>
```
from which we sum all the "ImponibileImporto" values.
3) Only remove the line if the ENASARCO tax is global and can be found in the database.
Ref old fix: https://github.com/odoo/odoo/pull/197456
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4555966)
opw-4555966
Forward-Port-Of: odoo/odoo#202044
Forward-Port-Of: odoo/odoo#200774Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the oth
Original PR description
Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription;…
Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`. This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to. Solution -------- In `sale`: - The bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field. In `sale_subscription`: - Add a test to prevent regression. opw-4554639 Forward-Port-Of: odoo/odoo#201768
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from thes
Original PR description
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is…
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from these fields. It occurs because timesheet users are restricted by ir-rules that allows access only to users owning the record or associated with a related project/task https://github.com/odoo/odoo/blob/34947c01623a9fc753197bd55d6121d9c6fa682f/addons/hr_timesheet/security/hr_timesheet_security.xml#L52 Solution is to add an ir-rule in account to allow read access to read-only users Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4586096) opw-4586096 Forward-Port-Of: odoo/odoo#202080 Forward-Port-Of: odoo/odoo#201365
Current behavior before PR: `isTalking` status displayed who was talking even when the user had deafened themselves. Desired behavior after PR is merged: `isTalking` status no longer shows who is talking if the user has deafened themselves. Task-id:[4609755](https://www.odoo.com/odoo/project.task/4609755) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200875
Original PR description
Current behavior before PR: `isTalking` status displayed who was talking even when the user had deafened themselves. Desired behavior after PR is merged: `isTalking` status no longer shows who is talking if the user has deafened themselves. Task-id:[4609755](https://www.odoo.com/odoo/project.task/4609755) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200875
When sending an invoice to Viettel, we currently raise an error in Odoo if the address information of the customer is not set. If the VAT is not set, it is the api raising an error. In both case, the information is optional, and we should be able to invoice. For the address information the validation in Odoo is removed, and for the VAT the json will now contain '' if it is not set instead of False Also make sure that the json file is attached to the chatter if it has been generate
Original PR description
When sending an invoice to Viettel, we currently raise an error in Odoo if the address information of the customer is not set. If the VAT is not set, it is the api raising an error. In both case, the information is optional, and we should be able to invoice. For the address information the validation in Odoo is removed, and for the VAT the json will now contain '' if it is not set instead of False Also make sure that the json file is attached to the chatter if it has been generated for audit purpose task-4405507 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196547
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the chatter, schedule an activity 3) Remove the `Due date` and click the `Done & Schedule Next` button Error:- ``` TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta' ``` This traceback is occurring because `date_deadline` is not a required field. So the user can re
Original PR description
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the…
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the chatter, schedule an activity 3) Remove the `Due date` and click the `Done & Schedule Next` button Error:- ``` TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta' ``` This traceback is occurring because `date_deadline` is not a required field. So the user can remove it. If there is no `date_deadline`, the context contains key with no value from the line below. https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L510 But here we are only checking the presence of the key in the context; If yes, the base is calculated based on the context value(None in this case). https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L204-L208 This will lead to the above traceback. sentry-6347875218 Forward-Port-Of: odoo/odoo#201674 Forward-Port-Of: odoo/odoo#199915
Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN. Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199150
Original PR description
Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN. Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199150
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax re
Original PR description
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax return - An error occurs due to duplicate line IDs Issue originates from `append_country_and_taxes_lines`, which appends a new line with incorrect markup (using new line markup instead of the last line markup). opw-4629989 Forward-Port-Of: odoo/enterprise#81641
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad
Original PR description
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos…
**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.
Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.
As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.
- How to reproduce:
* Assign one pos config to preparation display
* Archive the assigned config
* Open another pos config.
* Kitchen display is not loaded
**Solution**:
Change the domain to include displays with no configs, or with no active config.
opw-4504623
Forward-Port-Of: odoo/enterprise#81251
Forward-Port-Of: odoo/enterprise#80117To reproduce the issue: 1) Install l10n_es_reports 2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view) 3) Create an invoice with two lines of 100€, so that - both lines use both IVA21% and WHI 1% taxes - one of those lines defines an anlaytic distribution while the other doesn't 4) Open the generic tax report, and generate the VAT Record Books XLSX export ===> In that file, the amount of withholding is 15€. It should be 30€
Original PR description
To reproduce the issue:
1) Install l10n_es_reports
2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view)
3) Create an invoice with two lines of 100€, so that
- both lines use both IVA21% and WHI 1% taxes
- one of those lines defines an anlaytic distribution while the other doesn't
4) Open the generic tax report, and generate the VAT Record Books XLSX export
===> In that file, the amount of withholding is 15€. It should be 30€.
The same issue can be reproduced for surcharge taxes, in the same way.
This is due to the fact different analytic distributions between base lines will trigger the creation of different tax lines for the same tax (one for each distribution). The code handling the export "saw" both lines, but ovewrote the total instead of summing all the values.
opw-4471253
Forward-Port-Of: odoo/enterprise#81375- Sign > Documents > Click on any of the Kanban record - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading. Now, { id, token, create_uid, state,
Original PR description
- Sign > Documents > Click on any of the Kanban record
- Reload the view (either reload the browser, or activate
the debug, or change to dark mode on the user menu).
Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading.
Now, { id, token, create_uid, state, request_item_states} is put in the query string of the URL, in that way, when reloading, the client action 'sign.Document' will have the needed attributes. Note that, this is also the behavior of the base_import 'ImportAction' action [1].
task-4391729
[1] : https://github.com/odoo/odoo/pull/182744/commits/a6801ce4aa65cd023e2a762ab5c42755a4599c95
Forward-Port-Of: odoo/enterprise#77399Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_c
Original PR description
Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as…
Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`. This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to. Solution -------- In `sale`: - Bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field. In `sale_subscription`: - Add a test to prevent regression. opw-4554639 Forward-Port-Of: odoo/enterprise#81461
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained abo
Original PR description
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained above which contains the identifier of the move. We now save this identifier and use it in the automatic GetStatus call to get odoo and DIAN back in sync. ticket: 4569829 Forward-Port-Of: odoo/enterprise#81350
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currenc
Original PR description
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency conversion introduces a exchange loss/gain, it is put back on the largest transaction of the entry. opw-4393164 Forward-Port-Of: odoo/enterprise#80622 Forward-Port-Of: odoo/enterprise#76828