Monday, June 30, 2025
30 changes · saas-18.1
Resolved issues and error corrections
Middle-clicking a link to open it separately no longer triggers cleanup actions on the page the user is still viewing. This prevents unnecessary warnings or loss of in-progress changes when users open records or actions in another tab.
Original PR description
Before this commit, when middle clicking the clearUncommittedChanges (and subsequently the beforeLeave) were executed on the current controller. This is an issue, as we are not leaving the current controller. Now, the clearUncommittedChanges is not called when middle clicking. Note that, this is already the behaviour if the target is "new".
The demo payroll data now uses a Belgium-specific time off type for employee allocations. This prevents access errors when opening demo employee records and keeps Belgian payroll test data aligned with local configuration.
Original PR description
This commit fixes an issue in the demo data. A time off allocation was done using a time off type that is not in Belgium. This caused access error when trying to access the employee. This commit fixes the issue by changing the time off type to a belgian one. task-4896664
Installing Sale Planning no longer fails if the Hours unit of measure was previously deleted. The module now restores the required Hours unit when needed and prevents it from being deleted in Sale Planning, improving setup reliability for affected databases.
Original PR description
Steps to reproduce: --- - Install `sale_management` module - Enable `Units of Measure & Packagings` - Delete `Hours` in Units & Packagings - Install `sale_planning` module Traceback: --- ```…
Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module
Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
<field name="name">planning.role.list.inherit.sale.planning</field>
<field name="model">planning.role</field>
<field name="inherit_id" ref="planning.planning_role_view_tree"/>
<field name="arch" type="xml">
<field name="resource_ids" position="after">
<field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{ 'default_type': 'service', 'default_planning_enabled': True, 'default_planning_role_id': id, 'default_uom_id': %(uom.product_uom_hour)d, }"/>
</field>
</field>
</record>
```
The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.
This commit resolves the issue by calling the `ensure_uom_hours` method before updating the `Hours` unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261This change corrects the setup of hidden fields in the Spanish tax report export wizard so the system can build and load properly. It is a small technical fix that helps prevent deployment or upgrade errors for companies using Spanish localization reports.
Original PR description
this is a continue of the previous commit:https://github.com/odoo/enterprise/commit/630ab91879a7489658a7eea151c5cc627025e152 build_error-227705
Miscellaneous changes
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it,
Original PR description
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it, the form will be hidden by default then shown based on attributes such as data-visibility-selectors. But on the root tag, we only allow to modify only a very restricted list of tags, so we saved the hiding of the form, but didn't save the attributes that made it visibile based on a condition. Fix: add the attributes used for visibility in the authorized list on the root tag. opw-4765026 Forward-Port-Of: odoo/odoo#215479
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read t
Original PR description
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213807
**Steps to reproduce:** 1) Install CRM 2) Create a crm lead and mark it as lost 3) Create a new activity for the lost lead for today 4) Go to the activity button in the top right corner 5) Click on today's activity for crm leads **Issue:** If you click activity for crm, it will only show the active lead's activities, not the lost ones. You need to click on the filter 'lost', to see the lost leads **Cause:** When the lead is marked as lost, we archive the lead record.
Original PR description
**Steps to reproduce:** 1) Install CRM 2) Create a crm lead and mark it as lost 3) Create a new activity for the lost lead for today 4) Go to the activity button in the top right corner 5) Click on today's activity for crm leads **Issue:** If you click activity for crm, it will only show the active lead's activities, not the lost ones. You need to click on the filter 'lost', to see the lost leads **Cause:** When the lead is marked as lost, we archive the lead record. Indeed, we won't see the lost leads by default when opening activities, since they are not active. https://github.com/odoo/odoo/blob/8111009f6a8888db80f9afaa145a4c64272370e7/addons/crm/models/crm_lead.py#L1013-L1016 **Solution:** Add `active_test` to the context to show the archived/lost activities. opw-4866692 Forward-Port-Of: odoo/odoo#214942
Forward-Port-Of: odoo/odoo#216098
Original PR description
Forward-Port-Of: odoo/odoo#216098
### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user can
Original PR description
### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Forward-Port-Of: odoo/odoo#215455
We recently refactored the UBL generation in master in https://github.com/odoo/odoo/pull/214151. This refactor improves the handling of taxes and enables code to be factorized when generating UBL documents from invoices, sale / purchase orders, and PoS orders. We are back-porting the common helpers and the BIS3 and Colombian UBLs because: - for BIS3, we need to use the new tax computations to avoid customer errors in 18.0 - for Colombia, we will soon be merging an UBL for the Colombian P
Original PR description
We recently refactored the UBL generation in master in https://github.com/odoo/odoo/pull/214151. This refactor improves the handling of taxes and enables code to be factorized when generating UBL documents from invoices, sale / purchase orders, and PoS orders. We are back-porting the common helpers and the BIS3 and Colombian UBLs because: - for BIS3, we need to use the new tax computations to avoid customer errors in 18.0 - for Colombia, we will soon be merging an UBL for the Colombian PoS and basing it on the refactored code will avoid us needing to maintain separate versions in stable and master. Enterprise PR: https://github.com/odoo/enterprise/pull/88366 task-4893999 Forward-Port-Of: odoo/odoo#215610
Description of the issue/feature this PR addresses: Fix #215501 Current behavior before PR: Crash with 500 internal error. Desired behavior after PR is merged: No crash. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215503
Original PR description
Description of the issue/feature this PR addresses: Fix #215501 Current behavior before PR: Crash with 500 internal error. Desired behavior after PR is merged: No crash. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215503
when using partner enrich from CRM category tags were not fetched now category tags are autofilled when using partner enrich from CRM --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215807
Original PR description
when using partner enrich from CRM category tags were not fetched now category tags are autofilled when using partner enrich from CRM --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215807
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another company than Marc's company - Confirm the SO **Issue:** A traceback is raised: `No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.` **Root Cause:** - When the procurement group searches for a pull
Original PR description
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another…
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another company than Marc's company - Confirm the SO **Issue:** A traceback is raised: `No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.` **Root Cause:** - When the procurement group searches for a pull rule with a destination location set to the inter-company transit location (due to the partner's company being different), the rules for the inter-company transit location are not automatically applied. - The `_get_rule_domain` method https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_rule.py#L641-L653 modifies the destination location to the customer's location if: - The user belongs to the `base.group_multi_company` group. - The destination location is the inter-company transit location. - In this use case, the user does not belong to the `base.group_multi_company` group because they are restricted to a single allowed company. Additionally, the logic in `_compute_location_dest_id` https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_move.py#L227-L231 for inter-company transfers does not account for users with a single allowed company. **opw-4749870** 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#211063
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefi
Original PR description
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefined). So when metamask (or another extension that cause window.chrome.runtime to be defined) is installed, we get an error shown because the promise rejection is not handled. Fix: handle the unhandled promise error. opw-4874027 Forward-Port-Of: odoo/odoo#216132
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an mrp.production order and clicking on "Set as done". Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg. At the end of
Original PR description
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an…
Description of the issue/feature this PR addresses:
I'm not sure how to reproduce right now. Clue: these modules are installed:
- sale_stock_margin
- stock_account
Other clue: user is going to an mrp.production order and clicking on "Set as done".
Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg.
At the end of the rabbit hole, the code ends up here, where there's a pretty obvious bug: a singleton value being extracted from a multi-record variable.
So, yes, this is probably the worse fix description ever. 😅 However, the bug is so obvious that I'm not sure I really need something more elaborate in this case. So, here's the fix! 🎁
@moduon MT-7556
Current behavior before PR:
<details>
```
Traceback (most recent call last):
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 15, in _call_kw
raise ValueError
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5182, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1651, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/opt/odoo/custom/src/odoo/odoo/service/[model.py](https://model.py/)", line 133, in retrying
result = func()
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1678, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1882, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/[ir_http.py](https://ir_http.py/)", line 154, in _dispatch
result = endpoint(**request.params)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 734, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 46, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 19, in _call_kw
return super()._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 469, in call_kw
model.env.flush_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 745, in flush_all
self._recompute_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 741, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 6282, in _recompute_field
field.recompute(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1370, in recompute
apply_except_missing(self.compute_value, recs)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1343, in apply_except_missing
func(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1392, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 4240, in _compute_field_value
fields.determine(field.compute, self)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/sale_stock_margin/models/[sale_order_line.py](https://sale_order_line.py/)", line 18, in _compute_purchase_price
purch_price = product._compute_average_price(0, line.product_uom_qty, line.move_ids)
File "/opt/odoo/auto/addons/mrp_account/models/[product.py](https://product.py/)", line 54, in _compute_average_price
return super()._compute_average_price(qty_invoiced, qty_to_invoice, stock_moves, is_returned=is_returned)
File "/opt/odoo/auto/addons/stock_account/models/[product.py](https://product.py/)", line 788, in _compute_average_price
qty_valued, valuation = candidates._consume_specific_qty(qty_invoiced, qty_to_invoice)
File "/opt/odoo/auto/addons/stock_account/models/[stock_valuation_layer.py](https://stock_valuation_layer.py/)", line 113, in _consume_specific_qty
rounding = self.product_id.uom_id.rounding
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1154, in __get__
record.ensure_one()
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5185, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: uom.uom(1, 12)
```
</details>
Desired behavior after PR is merged: Fixed!
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183402Forward-Port-Of: odoo/odoo#213890
Original PR description
Forward-Port-Of: odoo/odoo#213890
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214289 Forward-Port-Of: odoo/odoo#202832
Original PR description
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214289 Forward-Port-Of: odoo/odoo#202832
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 -
Original PR description
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open…
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 - Third line with a price of 0.020 and a qty of 3 - Create a new request for quotation for this product with this vendor - set a quantity of 3 **Current behavior:** The unit price is 0.022 **Expected behavior:** It should be 0.020 **Cause of the issue:** When sorting the set of product.supplierinfo, rounding should not be applied because the rounding will be the one of the currency and the Product Price could allow more decimal than the currency. If we allow vendors price to be more precise the the currency, the sorting should take into account this precision when choosing a vendor. opw-4823919 Forward-Port-Of: odoo/odoo#213826
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 op
Original PR description
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 opw-4824616 opw-4829820 Forward-Port-Of: odoo/enterprise#86831
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The
Original PR description
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The Ticket should continue to include a reference to the originating Lead (existing behaviour). - The Lead should also display a chatter message referencing the newly created Ticket. Forward-Port-Of: odoo/enterprise#87463
Forward-Port-Of: odoo/enterprise#88323
Original PR description
Forward-Port-Of: odoo/enterprise#88323
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88608
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88608
Users can now add a negative quantity product (e.g. cautions) without needing to locate the original order to refund it. We make sure that negative order contains only negative lines and prevents mixing with positive quantities to avoid confusion. task-id: 4771749 community PR: https://github.com/odoo/odoo/pull/209282 Forward-Port-Of: odoo/enterprise#88290 Forward-Port-Of: odoo/enterprise#85137
Original PR description
Users can now add a negative quantity product (e.g. cautions) without needing to locate the original order to refund it. We make sure that negative order contains only negative lines and prevents mixing with positive quantities to avoid confusion. task-id: 4771749 community PR: https://github.com/odoo/odoo/pull/209282 Forward-Port-Of: odoo/enterprise#88290 Forward-Port-Of: odoo/enterprise#85137
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines - Save the SO - Issue: the discount on the non-subscription line has been reset to 0.0 **Issue 2** - Using the previous SO, add back a discount value for the non-subscription line - Confirm the SO and invoice it - Close the subscription - Issue: the discount on the non-subscription line
Original PR description
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines…
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines - Save the SO - Issue: the discount on the non-subscription line has been reset to 0.0 **Issue 2** - Using the previous SO, add back a discount value for the non-subscription line - Confirm the SO and invoice it - Close the subscription - Issue: the discount on the non-subscription line has been reset to 0.0 **Cause** Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount. **Solution** It is not possible to know which dependency triggered the compute, therefore the solutions are to: - avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary - avoid calling super for lines if the subscription is closed opw-4645579 Forward-Port-Of: odoo/enterprise#87840 Forward-Port-Of: odoo/enterprise#84754
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
This commit is a partial backport of this commit [[1]]. This commit has 2 different purposes: 1. Connect the bank synchronization and the payment module to a new API route to get the connection status instead of only getting the consent expiring date. This new route still provides the consent expiring date but will also provide more information about the payment initiation. Three new information are provider, whether the payment feature is enabled, whether the payment activation is reques
Original PR description
This commit is a partial backport of this commit [[1]]. This commit has 2 different purposes: 1. Connect the bank synchronization and the payment module to a new API route to get the connection…
This commit is a partial backport of this commit [[1]]. This commit has 2 different purposes: 1. Connect the bank synchronization and the payment module to a new API route to get the connection status instead of only getting the consent expiring date. This new route still provides the consent expiring date but will also provide more information about the payment initiation. Three new information are provider, whether the payment feature is enabled, whether the payment activation is requested to the provider and whether the feature is activated with the provider. 2. This second purpose is directly linked to the first one, it modifies the Initiate payment visibility. Before it was visible once the bank journal was connected to a bank synchronization, now it's visible once the bank journal has a bank synchronization where the payment initiation feature is enabled by the customer. task-4413740 [1]: https://github.com/odoo/enterprise/commit/a89d1aed466167249cd52b30bce157f015355458 Forward-Port-Of: odoo/enterprise#81060
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Original PR description
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
In master, we recently refactored the UBL generation so that it uses the new tax helpers. This is a back-port of the Colombian part of that refactor. Users will be able to use the new helpers by setting the config param `account_edi_ubl_cii.use_new_dict_to_xml_helpers`. Additionally, back-porting these helpers enables us to reuse them for the Colombian PoS UBL which will be coming out soon. Community PR: https://github.com/odoo/odoo/pull/215610 task-4893999 Forward-Port-Of: odoo/ent
Original PR description
In master, we recently refactored the UBL generation so that it uses the new tax helpers. This is a back-port of the Colombian part of that refactor. Users will be able to use the new helpers by setting the config param `account_edi_ubl_cii.use_new_dict_to_xml_helpers`. Additionally, back-porting these helpers enables us to reuse them for the Colombian PoS UBL which will be coming out soon. Community PR: https://github.com/odoo/odoo/pull/215610 task-4893999 Forward-Port-Of: odoo/enterprise#88366
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455 Forward-Port-Of: odoo/enterprise#88339
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104