Daily updates from Odoo
Navigate
Branch
Wednesday, April 30, 2025
60 changes
24 changes
Resolved issues and error corrections
Fixes an error that occurred when previewing the Calendar Attendee Information email template. Users can now preview this template normally, avoiding a disruptive traceback during email template setup or review.
Original PR description
When a user previews the mail template for Calendar Attendee Information,
A traceback will appear.
Steps to reproduce the error:
- Install ``calendar``
- Now go to Email Templates >
Open email template (Applies to: ``Calendar Attendee Information``)
- Click Preview
Traceback:
```
File "/home/odoo/src/odoo/saas-18.2/addons/mail/models/models.py", line 300, in _message_get_default_recipients
all_emails += defaults['partners'].mapped('email_normalized')
KeyError: 'partners'
```
https://github.com/odoo/odoo/blob/09099ab477bd871c67205388d96172280cd714a5/addons/mail/models/models.py#L300 Here, ``partners`` key is accessed but at [1] key is ``partner_ids``,
So, it will lead to the above traceback.
1-https://github.com/odoo/odoo/blob/09099ab477bd871c67205388d96172280cd714a5/addons/calendar/models/calendar_attendee.py#L116
sentry-6505820998
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Point of Sale restaurant orders from failing when they are created and paid while offline, then reloaded after reconnecting. It improves reliability for staff using POS in unstable network conditions by correctly handling saved order identifiers.
Original PR description
This error occurs when creating an `order` and `validating payment` in offline mode then reloading the same order. Steps to reproduce: - Install module `pos_restaurant`. - Open `POS Restaurant`. -…
This error occurs when creating an `order` and `validating payment` in offline mode then reloading the same order. Steps to reproduce: - Install module `pos_restaurant`. - Open `POS Restaurant`. - Add some products to the order go to Payments, and select card(Pick any table) - Open Inspect, go to the Network tab and enable Offline Mode. - Click Validate, go to `Orders`, and click `Load Order`. - Add Products to the `Orders` and click on Order. - In the Network tab, enable No Throttling and click on Orders again. - Do the above step one more time on the same table. ValueError Expected singleton: pos.order() This error occurs due to the `missing handling ID` as a string like in saas18.1 at [1], so when the fieldName is a string the type system is unable to fetch the ID This commit resolves the error by ensuring that the ID is correctly processed. If it is a number, it remains unchanged. If it is a string containing an underscore (_), the numeric part after _ is extracted. Link [1] :https://github.com/odoo/odoo/blob/d4e40e4be4233d91db80717891cef73c4fdec06c/addons/point_of_sale/static/src/app/models/related_models.js#L281-L285 Sentry - 6365371665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spanish companies will now always show the business customer fields needed during checkout and address editing. This prevents customers from getting blocked by a required VAT field that was hidden by website settings.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Enable Spanish localization; 2. assign website to Spanish company; 3. disable B2B fields in checkout via website editor; 4. edit address in eCommerce as a Spanish customer. Issue ----- Impossible to proceed, as VAT is a required field, but isn't displayed. Cause ----- Commit 26df8d31ab94 fixed this issue in earlier versions, but wasn't adapted for changes in 18.2+ where 5a93da8e9220 refactored address management. Solution -------- Override `_prepare_address_form_values` to always render B2B fields when the current company is Spanish. opw-4708230
Creating a new attendee from the eLearning reporting views no longer triggers an error when the new record has not been saved yet. This improves reliability for users managing course attendance and prevents an avoidable interruption in the workflow.
Original PR description
Currently, this exception is raised when a user tries to create a new attendee. Steps to Reproduce: 1. Install `website_slides` module. 2. Go to eLearning ->Reporting -> Attendees 3. Switch to the Pivot view and click on a count integer. 4. Open the List View and click the "New" button. 5. An error Occurs Error: ```SyntaxError syntax error at or near ")" LINE 18: WHERE SCP.id IN () ``` This issue[1] occurs because the system runs a query expecting an existing record with an ID, but since the record isn't saved yet, `self.ids` is empty, causing the query to fail. [1]- https://github.com/odoo/odoo/blob/fbee52705e0332f7134eb5505eac26677e38c168/addons/website_slides/models/slide_channel.py#L91 This fix ensures that if self.ids is empty, the system stops the process early and sets a proper value, preventing the query from failing. sentry-6465821899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where automated actions creating activities could fail when a record had more than one user in a multi-user field. The system now creates the activity for the first user found, avoiding an error that blocked the action.
Original PR description
Have a server action that creates an activity based on a record's x2m user field. Run that action on a record that has more than one user in this field. Before this commit: display traceback "ValueError: Expected singleton" After this commit: the activity is created for the first user found in the x2m field value. Task id: opw-4745032
This fixes an internal test so it skips folders and items that are not meant to be imported as Python code. It helps developers run checks locally without false failures, improving confidence in routine maintenance.
Original PR description
The test was failing locally due to attempts to import non-Python modules like `.tx`, `.git`, and `odoo.setup`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Forward-Port-Of: odoo/odoo#208093 Forward-Port-Of: odoo/odoo#208076
Original PR description
Forward-Port-Of: odoo/odoo#208093 Forward-Port-Of: odoo/odoo#208076
odoo/odoo#203874 broke compatibility with Python 3.8 and Python 3.9 due to the typing annotations, leading `test_pylint` to fail on Focal and Bullseye: - `list[int]` requires Python 3.9 (PEP 585) - type-wise `a | b` requires Python 3.10 (PEP 604) Making annotations lazy works around the issue (and changes less stuff than removing the annotations). Forward-Port-Of: odoo/odoo#208110
Original PR description
odoo/odoo#203874 broke compatibility with Python 3.8 and Python 3.9 due to the typing annotations, leading `test_pylint` to fail on Focal and Bullseye: - `list[int]` requires Python 3.9 (PEP 585) - type-wise `a | b` requires Python 3.10 (PEP 604) Making annotations lazy works around the issue (and changes less stuff than removing the annotations). Forward-Port-Of: odoo/odoo#208110
Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major versoins. As of the time of this commit this included: - Azerbaijani (az), - Bulgarian (bg), - Croatian (hr), - Estonian (et), - Greek (el), - Hebrew (he), - Hungarian (hu), - Latvian (lv), - Mongolian (mn), - Persian (fa), - Portuguese (pt), - Romanian (ro), - Ukranian (uk) Therefo
Original PR description
Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major…
Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major versoins. As of the time of this commit this included: - Azerbaijani (az), - Bulgarian (bg), - Croatian (hr), - Estonian (et), - Greek (el), - Hebrew (he), - Hungarian (hu), - Latvian (lv), - Mongolian (mn), - Persian (fa), - Portuguese (pt), - Romanian (ro), - Ukranian (uk) Therefore this commit pulls the current translations from the 18.0 transifex project for these languages. Note that pot file msgmerges were not applied since the end result would have been the same, missing terms from pot files won't have a translation in the po file + extra terms in the po file not in the pot won't be used. 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 commit adds a new button to the dialog used to connect the IoT Box to a Wi-Fi network, to display/hide the password. Forward-Port-Of: odoo/odoo#207285
Original PR description
This commit adds a new button to the dialog used to connect the IoT Box to a Wi-Fi network, to display/hide the password. Forward-Port-Of: odoo/odoo#207285
…taxes are included in price 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#205925
Original PR description
…taxes are included in price 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#205925
**Current behavior:** With anglo saxon accounting and real-time valuation, purchasing a kit product with a BoM that has components whose costs add up to the exact price of the kit product and that is invoiced on ordered qty and has avg costing, then billing before receiving will prevent the reception from being validate-able. **Expected behavior:** Can validate **Steps to reproduce:** 1. Create a kit product with avg costing, invoiced on ordered qty, and a BoM with 2 components tha
Original PR description
**Current behavior:** With anglo saxon accounting and real-time valuation, purchasing a kit product with a BoM that has components whose costs add up to the exact price of the kit product and that is…
**Current behavior:** With anglo saxon accounting and real-time valuation, purchasing a kit product with a BoM that has components whose costs add up to the exact price of the kit product and that is invoiced on ordered qty and has avg costing, then billing before receiving will prevent the reception from being validate-able. **Expected behavior:** Can validate **Steps to reproduce:** 1. Create a kit product with avg costing, invoiced on ordered qty, and a BoM with 2 components that have a cumulative cost equalling that of the final kit product 2. Make a purchase for it, invoice -> post 3. Try to validate the receipt -> can't due to attempted re-reconicilation **Cause of the issue:** When validating the receipt, we end up here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L81-L90 And attempt to reconcile both the original kit product AML from corresponding to the purchase line as well as the AML for the component in the stock input account. But we only will capture 1 exploded component AML in each loop iteration, so the original kit product AML will not actually be set `reconciled = True`, so we will also add it to be reconciled again: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L90 The same thing happens in subsequent calls to `_stock_account_anglo_saxon_reconcile_valuation()`, except on a final call for the last component line- if the components' cumulative cost aligns with the total cost of the kit product (which it should) then the reconciliation attempt will succeed. Then here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L92 `reconcile()` is called on the already-reconciled AML which will cause the re-reconiliation error. **Fix** Reconcile all the resulting kit AMLs (component AMLs + actual kit product AML from the bill) together. opw-4668004 Forward-Port-Of: odoo/odoo#207803 Forward-Port-Of: odoo/odoo#205401
Thanks to [1], we can now fix the website page properties tour ensuring that the necessary elements are visible on the page. [1]: https://github.com/odoo/odoo/commit/4e25c13c918382afb34013a6dd30aac4a0ce4e84 runbot-106391 Co-authored-by: Pierre Pulinckx Forward-Port-Of: odoo/odoo#207740
Original PR description
Thanks to [1], we can now fix the website page properties tour ensuring that the necessary elements are visible on the page. [1]: https://github.com/odoo/odoo/commit/4e25c13c918382afb34013a6dd30aac4a0ce4e84 runbot-106391 Co-authored-by: Pierre Pulinckx Forward-Port-Of: odoo/odoo#207740
We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal. Steps to reproduce: 1. Have two purchase journal A and B on the same company 2. Set an expense account that is allowed on one of those journa
Original PR description
We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal. Steps to reproduce: 1. Have two purchase journal A and B on the same company 2. Set an expense account that is allowed on one of those journal (A) and not the other (B) 3. Create multiple bills with this account on the journal A for partner X 4. Upload a XML bill of partner X in journal B -> The expense account is used based on the bills in journal A -> Error because journal B is not allowed for this account opw-4607733 Forward-Port-Of: odoo/odoo#206104 Forward-Port-Of: odoo/odoo#203664
When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207896
Original PR description
When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207896
When using an intermediate return location, the delivered qty of a returned kit is incorrect To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a location L: - Parent: WH - Type: Internal - Return location: True 3. Create a route: - Applicable on: Main warehouse - Add one rule: - Action: Push To - Operation Type: Internal - From: L - To: WH/Stock 4. Create a kit K 5. Sell and deliver 1 x K 6. Return it to L - It
Original PR description
When using an intermediate return location, the delivered qty of a returned kit is incorrect To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a location L: - Parent: WH -…
When using an intermediate return location, the delivered qty of a
returned kit is incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a location L:
- Parent: WH
- Type: Internal
- Return location: True
3. Create a route:
- Applicable on: Main warehouse
- Add one rule:
- Action: Push To
- Operation Type: Internal
- From: L
- To: WH/Stock
4. Create a kit K
5. Sell and deliver 1 x K
6. Return it to L
- It will create an internal transfer
7. Process the internal transfer
8. Open the SO
Error: The delivered quantity of the kit is -1 instead of 0
Step 6, when returning the kit, the push rule is applied and create
the SM from L to WH/Stock. Since we copy the SM from Customer to L, the
new SM also has the field `sale_line_id` defined.
As a result, step 7, since all SM are done, `moves` contain them
(the delivery, the return and the internal transfer). We then filter
them based on some criteria:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L67-L73
But, for `outgoing_moves` (which is actually the incoming ones, the
name is wrong), since we look at the destination location, both the
return and the internal SM will match. That's why we will decrease
twice the delivered quantity. Hence, the bug.
A fix could be to avoid copying the `sale_line_id` field. That being
said, when looking `sale_stock` side (i.e., same flow with a classic
product), we don't have any issue because the filters are slightly
different:
https://github.com/odoo/odoo/blob/418dc0cc3b3aa1ee2abbdb4852d9cd24fba7636e/addons/sale_stock/models/sale_order_line.py#L274-L278
(Here, we need to look at the `incoming_moves`. Again: the name is just
incorrect on mrp side...)
We see that, for `incoming_moves`, we actually look at the source
location. This explains why we don't have any issue with a non-kit
product.
Therefore, the best fix would be to use the same filters everywhere.
Good news, such a method already exist:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L115-L116
However, using this method might lead to some other issues (among them:
the override in `sale_subscription_stock` reads a field although the
method is an `api.model` one). So, let's minimize the diff on stable
version and refactor the code (use the same filters everywhere) on
master.
About the filter names, the confusion actually comes from:
https://github.com/odoo/odoo/blob/312572c7b8138a4800350cd7a524a37551a348ef/addons/mrp/models/stock_move.py#L624
There, we should rather talk about positive moves and negatives
moves, since this method can be used either in a SO flow or in a PO
one. This explains why, for now, SO sode, an "incoming move" is
actually an outgoing one. So, on master, another commit will be
added to also clean that part of the code:
\- Improve the expected filter names in `_compute_kit_quantities`
\- Fix the filter names in `_get_incoming_outgoing_moves_filter`
OPW-4625228
Forward-Port-Of: odoo/odoo#207739
Forward-Port-Of: odoo/odoo#206966Steps to reproduce [17.1]: - Add a property field to a job application in the backend. - Go to the linked website job application form (in edit mode). - The property field is inaccessible. To be able to access the new property field in the application form, the `job_id` value of the related job record needs to be specified by default. Unfortunately, these values are removed before accessing "edit" mode: Starting from [1], a fix was added to clear default values coming from `data-f
Original PR description
Steps to reproduce [17.1]: - Add a property field to a job application in the backend. - Go to the linked website job application form (in edit mode). - The property field is inaccessible. To be able…
Steps to reproduce [17.1]: - Add a property field to a job application in the backend. - Go to the linked website job application form (in edit mode). - The property field is inaccessible. To be able to access the new property field in the application form, the `job_id` value of the related job record needs to be specified by default. Unfortunately, these values are removed before accessing "edit" mode: Starting from [1], a fix was added to clear default values coming from `data-for` attributes when the form is edited (at `cleanForSave()`) to prevent saving it with changed default values. Since the code from [1] can also remove default values set by the user, a new fix (see [2]) updated this implementation to ensure that only values from auto-fill and data-for fields will be removed (this time, when the form public widget is destroyed [3]). The behaviour from [3] will always unlink the `data-for` values in edit mode, and as a consequence, the related property fields won't be correctly retrieved. The goal of this commit is to fix this behaviour by excluding `data-for` values from the reset in [3]. An extra check will be added to be sure the form won't be saved with updated default values if it already has `data-for` ones [4]. Important: The diff from [5] made the `email_to` field as an exception for the data-for/prefill priority system and only used the `data-for` value if nothing has been configured by the user (it also used the `data-for` value if what was configured by the user is the dummy default email: `info@yourcompany.example.com`). That's why we need to exceptionally allow saving the default value added by the user in the check from [4] to preserve the same behavior. Following [6], The `email_to` value won't be kept in edit mode to prevent breaking its dynamic behavior. [1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b [2]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544 [5]: https://github.com/odoo/odoo/commit/a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b [6]: https://github.com/odoo/odoo/commit/6658d61e304c9dfd8e512648c4a001dcaac44bc1 task-3922573 Forward-Port-Of: odoo/odoo#204027 Forward-Port-Of: odoo/odoo#166565
Before this commit, pricelist rules defined on a parent category were not applied to products belonging to its child categories. opw-4685399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204302
Original PR description
Before this commit, pricelist rules defined on a parent category were not applied to products belonging to its child categories. opw-4685399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204302
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 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#207816 Forward-Port-Of: odoo/odoo#203254
Original PR description
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 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#207816 Forward-Port-Of: odoo/odoo#203254
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#199930
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 Forward-Port-Of: odoo/odoo#199930
Fix an issue when sending invoices asynchronously to SDI from multiple companies. Steps to reproduce: - Setup two Italian companies, A and B - Create and post one invoice in each company - From the list view, batch send both invoices - Run the “Send invoices automatically” scheduled action An error occurs: ValueError: Expected singleton: account_edi_proxy_client.user(4, 3) This happens because both companies try to send their moves simultaneously, but the proxy client is company-sp
Original PR description
Fix an issue when sending invoices asynchronously to SDI from multiple companies. Steps to reproduce: - Setup two Italian companies, A and B - Create and post one invoice in each company - From the list view, batch send both invoices - Run the “Send invoices automatically” scheduled action An error occurs: ValueError: Expected singleton: account_edi_proxy_client.user(4, 3) This happens because both companies try to send their moves simultaneously, but the proxy client is company-specific. This fix groups the invoices by company before sending them. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4725653) opw-4725653 Forward-Port-Of: odoo/odoo#207831 Forward-Port-Of: odoo/odoo#206267
When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior. While at it, update the NSIS version. Forward-Port-Of: odoo/odoo#207464
Original PR description
When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior. While at it, update the NSIS version. Forward-Port-Of: odoo/odoo#207464
PR #202334 introduced a test in `pos_loyalty` that depends on the field `discount_product_id` that is created in the module `pos_discount`. However, `pos_loyalty` and `pos_discount` does not have dependence, so the fails if `pos_discount` is not installed. This PR only runs it when `pos_discount` is installed. opw-4622428 Forward-Port-Of: odoo/odoo#207758
Original PR description
PR #202334 introduced a test in `pos_loyalty` that depends on the field `discount_product_id` that is created in the module `pos_discount`. However, `pos_loyalty` and `pos_discount` does not have dependence, so the fails if `pos_discount` is not installed. This PR only runs it when `pos_discount` is installed. opw-4622428 Forward-Port-Of: odoo/odoo#207758
Steps to reproduce: - Have a pricelist with rules. - Add this pricelist as the default one for a POS (kiosk). - Open the kiosk and add the products to trigger the price rule Issue: The price rule is not taken into account. This occurs because the kiosk currently does not set the order pricelist in kiosk mode. Also, pricelist rules are not loaded as it occurs in normal POS session [1] [1] https://github.com/odoo/odoo/blob/c8d7452063a4712b03b6d23e944ff283bdcea857/addons/point_of_sale
Original PR description
Steps to reproduce: - Have a pricelist with rules. - Add this pricelist as the default one for a POS (kiosk). - Open the kiosk and add the products to trigger the price rule Issue: The price rule is not taken into account. This occurs because the kiosk currently does not set the order pricelist in kiosk mode. Also, pricelist rules are not loaded as it occurs in normal POS session [1] [1] https://github.com/odoo/odoo/blob/c8d7452063a4712b03b6d23e944ff283bdcea857/addons/point_of_sale/static/src/app/store/pos_store.js#L417 This commit aim to restore the pricelist functionality by loading the pricelist rules at startup like `computeProductPricelistCache` does opw-4553345 Forward-Port-Of: odoo/odoo#206039 Forward-Port-Of: odoo/odoo#199942
36 changes
New functionality added to Odoo
Spreadsheet users can now create funnel charts from Odoo data. This helps teams visualize staged processes, such as pipelines or conversions, directly in spreadsheets for easier business analysis.
Original PR description
This commit adds the `odoo_funnel` chart type. Task: [4629660](https://www.odoo.com/web#id=4629660&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Enhancements to existing features
Vendors in Ecuador can now view purchase withholding documents directly in the customer portal. Printing and downloading related EDI documents now works correctly from the portal, helping both companies and vendors verify withholding information more easily.
Original PR description
For Ecuador, Purchase Withholdings are a common document that needs to be visible to vendors to make sure everything is as expected on both sides. Since they are of type entry, they aren't currently visible on the portal view so a new section needed to be added. It is implemented as another filter on the invoicing portal controller and slightly modified views. As a result of adding the portal view, the previous implementation of blocking the print button with a warning saying to use the context action instead is no longer working. As such, the print button has been implemented to display the right report as well as the account.move.send wizard being able to be used to match invoices and vendor bills. This allows for the invoice report id to be properly set and allow us to download the edi documents automatically in the portal. Community PR: https://github.com/odoo/odoo/pull/205420 task-4304037
This update standardizes how several Odoo apps connect with mail discussion features, making future maintenance safer and more consistent. It is an internal improvement with no expected change to everyday user workflows.
Original PR description
odoo/odoo#206588
Payroll demo environments for many country localizations now include local bank examples with proper bank identifiers. Each localization also gets two sample employees with contracts and locally relevant details, making demonstrations and testing more realistic.
Original PR description
* = ae, au, bd, eg, hk, id, jo, ke, lt, lu, ma, mx, nl, pk, pl, ro, sa, sk, tr, and us. This PR improves the demo data for multiple l10n payroll modules by adding two banks (`res.bank`) with local bank names and BIC codes to each localization. Additionally, this PR also implements a baseline demo data experience for the payroll localizations. Every l10n now comes with 2 demo employees, each with a contract and most of their information filled out with data that fits the localization. task-3969900
A new logout option lets authorized users disconnect from the GST portal and remove stored GST API credentials from Odoo. This helps businesses manage GST portal access more cleanly when credentials need to be cleared or refreshed, with the option limited to Developer Mode.
Original PR description
This **PR** introduces a Logout button for the GST API in the configuration settings. It allows users to log out from the GST portal and removes the stored GST API credentials from the system. **Note**: This button is available only in the Developer Mode. **task**-4430663 ~~Community PR: https://github.com/odoo/odoo/pull/192162~~ **IAP PR**: https://github.com/odoo/iap-apps/pull/971
The payroll payment report CSV export now includes clearer payment details, such as sequence numbers and effective dates, while removing unnecessary employee address information. The report title, filename, and currency formatting have also been corrected so exported files are easier to read and use for payment processing.
Original PR description
This PR includes multiple changes in the Payment Report export CSV: - A sequence number is added - The effective date is added even for CSV exports - The title has been corrected to "Payment" - The employee address and report date has been removed - The currency symbol position is correctly set inside the file task-4689321
Resolved issues and error corrections
Non-admin users can now use AI agent chats and close them without running into permission errors. The update also fixes API key access, demo data links, and hides an admin-only progress banner so agent forms open more reliably.
Original PR description
## Purpose This PRs corrects some permission issues for non-admin users. Specifically, it allows non-admin users to delete their chat channel with the agent upon closing the chat window, and corrects the retrieval of API keys in the `llm_api_service` class. It also corrects the demo data to have proper link between the attachment and the agent, and hides the progress banner form the agent form for non-admin users. This solves the permission issues that were faced when the user tried to chat with the agent, or to access its form.
The AI message action now works correctly even when an incoming message cannot be matched to a known contact. This prevents an error from interrupting users when viewing or acting on those messages.
Original PR description
Purpose: -------- A message can have no author (when 'email_from' does not match any partner). When this is the case, the messageActionsInternal patch throws an error because it assumed that a message always has an author. Task-4762361
AI agent attachments are now linked directly to their owning agent so access permissions can be checked reliably. This prevents users from encountering attachment access issues, with the trade-off that duplicated attachments may need their AI embeddings recalculated.
Original PR description
Using a `Many2many` for the `attachment_ids` and `url_attachment_ids` fields was problematic. The `ir.attachment` model is meant to be used as a `Many2one` or `One2Many` since it is linked to its parent record using ressource fields (`res_model` and `res_id`). When using a `Many2many` field, the `res_id` loses its meaning since it should be able to include multiple IDs to be accurate. In practice, this caused an access rights issue because the `ir.attachment` model [1] relies on the `res_id` to check which user is allowed to access the attachment. To fix this, the attachment fields of the agent are replaced with `One2many` fields. This implies that the attachments aren't shared anymore and the embedding will need to be recomputed in case of duplicated attachments across multiple agents. [1] See function `check` of `base/models/ir_attachments.py`
Spreadsheet list autofill now handles spilled value ranges more accurately instead of always copying from the first item in the sequence. This helps users extend lists horizontally with the expected sequence, reducing manual corrections and data entry errors.
Original PR description
When autofilling value in odoo list, we always autofill based on the first value of the spilling sequence. This change not only fill when overflowing from the current spilling range and autofill with the sequence when doing so horizontally. Task: 4700968
Temporarily disables unreliable VoIP test checks that were failing inconsistently due to timing issues. This helps keep the development validation process stable while the underlying test problems are investigated later.
Original PR description
Some tests seem to have race conditions. We don't have time to debug it right now, so let's just disable the problematic tests for the time being.
Code cleanup and technical improvements
This change updates internal data cleaning logic to use a shared maintenance approach for resetting stored values. It helps keep the codebase simpler and more consistent, with no expected change to day-to-day user workflows.
Original PR description
odoo/odoo#207475
This update reorganizes internal automated tests so they reuse shared project testing models instead of duplicating setup across modules. It helps keep project planning, field service, and timesheet test coverage more consistent and easier to maintain, with no expected change for end users.
Original PR description
_*= industry_fsm, timesheet_grid - Replaced custom model definitions in `task_gantt.test.js`, `task_gantt_dependency.test.js`, and `task_progress_gantt.test.js` with extensions of models from the project module. - Moved shared model setup to project_test_models.js to avoid duplication and improve consistency. task-4725275
This update renames internal project task field references to use clearer portal-related wording. It does not change business workflows, but helps keep project, field service, helpdesk, and timesheet code easier to maintain consistently.
Original PR description
odoo/odoo#207477
Miscellaneous changes
In continuation of this pull request https://github.com/odoo/enterprise/pull/81569 We had to add more features, this includes: - An improvement of the return dashboard journal: (name and style) - Support for dark mode - Additional checks for oss and intrastat - periodicity selection order changed Forward-Port-Of: odoo/enterprise#84115
Original PR description
In continuation of this pull request https://github.com/odoo/enterprise/pull/81569 We had to add more features, this includes: - An improvement of the return dashboard journal: (name and style) - Support for dark mode - Additional checks for oss and intrastat - periodicity selection order changed Forward-Port-Of: odoo/enterprise#84115
[IMP] account_reports: EC Sales List return: checks improvement - Make the checks generic for all returns made for any EC Sales List, not just for Belgium - Improve the phrasing of the check messages [FIX] account_reports: EC Sales List generic check: wrong warning keys The account_reports prefix was missing ; so the check was never considered a failure. Forward-Port-Of: odoo/enterprise#84110
Original PR description
[IMP] account_reports: EC Sales List return: checks improvement - Make the checks generic for all returns made for any EC Sales List, not just for Belgium - Improve the phrasing of the check messages [FIX] account_reports: EC Sales List generic check: wrong warning keys The account_reports prefix was missing ; so the check was never considered a failure. Forward-Port-Of: odoo/enterprise#84110
Add, update, or delete some checks done on the accounting returns for the vat return and the partner vat listing reports. task-4627315 Forward-Port-Of: odoo/enterprise#84103
Original PR description
Add, update, or delete some checks done on the accounting returns for the vat return and the partner vat listing reports. task-4627315 Forward-Port-Of: odoo/enterprise#84103
Before we did it only for be but it was decided to move it for every l10n Forward-Port-Of: odoo/enterprise#84047
Original PR description
Before we did it only for be but it was decided to move it for every l10n Forward-Port-Of: odoo/enterprise#84047
When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. Forward-Port-Of: odoo/enterprise#84388
Original PR description
When `<attribute name="string" add="something more"` is used to add onto a string in another view, the `"something more"` string isn't translatable. Therefore since there isn't anything else adding onto this string, let's completely replace it with the original string + the "something more" string. Forward-Port-Of: odoo/enterprise#84388
Forward-Port-Of: odoo/enterprise#84269
Original PR description
Forward-Port-Of: odoo/enterprise#84269
Dates used to be loaded as strings until odoo/odoo#189879 in 18.2. Now they're loaded as luxon DateTime objects and those cannot be passed directly to `t-out`. Task: 4751574 Forward-Port-Of: odoo/enterprise#84096
Original PR description
Dates used to be loaded as strings until odoo/odoo#189879 in 18.2. Now they're loaded as luxon DateTime objects and those cannot be passed directly to `t-out`. Task: 4751574 Forward-Port-Of: odoo/enterprise#84096
- If the payslip sturct has `use_worked_day_lines = False` the printed payslip shoud not have worked_days_table Task: 4720429 Forward-Port-Of: odoo/enterprise#84248
Original PR description
- If the payslip sturct has `use_worked_day_lines = False` the printed payslip shoud not have worked_days_table Task: 4720429 Forward-Port-Of: odoo/enterprise#84248
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question and open the generated PDF - The address is not the one of the company, the footer doesn't show the right company, etc ### Cause: When sending to multiple partners, the action is dispatched with cron so a new `env` is created. This `env` has all companies active and the first one as main company.
Original PR description
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question and open the generated PDF - The address is not the one of the company, the footer doesn't show the right company, etc ### Cause: When sending to multiple partners, the action is dispatched with cron so a new `env` is created. This `env` has all companies active and the first one as main company. So in the end the wrong company is used to generate the report. ### Solution: In the cron when calling `_process_send_and_print` we give `report.with_company(company)` to make sure that the value the report will us are the one from the correct company. Also revert the small [fix](https://github.com/odoo/enterprise/pull/82320/files) that was made before, which is no longer needed. opw-4635283 Forward-Port-Of: odoo/enterprise#84408
This PR adds a validation check for a company's GST token before making GST API calls via cron. These validations already exist when making GST API calls through the GST return period but were missing in the cron execution. This ensures that no unnecessary cron execution and api call takes place. task-4350780 Forward-Port-Of: odoo/enterprise#84339 Forward-Port-Of: odoo/enterprise#81974
Original PR description
This PR adds a validation check for a company's GST token before making GST API calls via cron. These validations already exist when making GST API calls through the GST return period but were missing in the cron execution. This ensures that no unnecessary cron execution and api call takes place. task-4350780 Forward-Port-Of: odoo/enterprise#84339 Forward-Port-Of: odoo/enterprise#81974
Following 002df5f10d2378bab139ea5d59af7be3d6b40358 which made an error. When creating a new model, the feature that make a record specific to a company (ie: "use_company" -- just adds a field "company_id" on a model) should not be available when in single company mode, but should be available when in multicompany mode opw-4752832 Forward-Port-Of: odoo/enterprise#84225
Original PR description
Following 002df5f10d2378bab139ea5d59af7be3d6b40358 which made an error. When creating a new model, the feature that make a record specific to a company (ie: "use_company" -- just adds a field "company_id" on a model) should not be available when in single company mode, but should be available when in multicompany mode opw-4752832 Forward-Port-Of: odoo/enterprise#84225
Open Trial Balance report in debug mode Access report options In Column tab, check 'Blank if Zero' for all columns Go back to report Issue: If Initial/End Balance columns are blank, also the total line will be blank. This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost opw-4624006 Forward-Port-Of: odoo/enterprise#84070 Forward-Port-Of: odoo/enterprise#83493
Original PR description
Open Trial Balance report in debug mode Access report options In Column tab, check 'Blank if Zero' for all columns Go back to report Issue: If Initial/End Balance columns are blank, also the total line will be blank. This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost opw-4624006 Forward-Port-Of: odoo/enterprise#84070 Forward-Port-Of: odoo/enterprise#83493
…terms Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days" - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled. This occurs because each installment of the payment terms will be a payment term line, an
Original PR description
…terms Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days" - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled. This occurs because each installment of the payment terms will be a payment term line, and the query retrieving values to compose MOD349 will take the whole move amount for each payment term line. opw-4637439 Forward-Port-Of: odoo/enterprise#84085 Forward-Port-Of: odoo/enterprise#82435
task-4751862 Forward-Port-Of: odoo/enterprise#84094
Original PR description
task-4751862 Forward-Port-Of: odoo/enterprise#84094
"Do not disturb selector changes state correctly with limited time" is failing with this error: ``` 9. [toBe] Failed to find 1 of "p" with text "Until Jan 1, 2025, 1:15 AM" (Timeout of 3 seconds). Found 0 instead. > Expected: true > Received: false ``` Depending on the environment, it seems that the time is sometimes formatted with a nonbreaking space before the AM, and sometimes not. This is likely the reason for the failure. This commit adapts the test in order to exclude the prob
Original PR description
"Do not disturb selector changes state correctly with limited time" is failing with this error: ``` 9. [toBe] Failed to find 1 of "p" with text "Until Jan 1, 2025, 1:15 AM" (Timeout of 3 seconds). Found 0 instead. > Expected: true > Received: false ``` Depending on the environment, it seems that the time is sometimes formatted with a nonbreaking space before the AM, and sometimes not. This is likely the reason for the failure. This commit adapts the test in order to exclude the problematic space from the selector. Forward-Port-Of: odoo/enterprise#84383
Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id Actually this is not the case, different upsell order can have a line that have the same parent. Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B. Before this commit if the parent line of both order were computed at the same time one of them would end up
Original PR description
Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible…
Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id Actually this is not the case, different upsell order can have a line that have the same parent. Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B. Before this commit if the parent line of both order were computed at the same time one of them would end up without parent. This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched The follow use case lead to duplicate line on the parent A parent subscription A with 1 product Z Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z After this commit, parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time. Forward-Port-Of: odoo/enterprise#84340 Forward-Port-Of: odoo/enterprise#84255
Steps to Reproduce: 1. A document with a long title 2. Upload document 3. Preview the document When a document had a long title, the action buttons in the DocumentsFileViewer The header became misaligned. After this commit: No misalignment on action buttons. Task-4600177 Forward-Port-Of: odoo/enterprise#84375
Original PR description
Steps to Reproduce: 1. A document with a long title 2. Upload document 3. Preview the document When a document had a long title, the action buttons in the DocumentsFileViewer The header became misaligned. After this commit: No misalignment on action buttons. Task-4600177 Forward-Port-Of: odoo/enterprise#84375
The aim of this commit is fixing a traceback when we have a statement group with no balance passed as props. It could happen when we have statement lines without any statement between 2 groups of statement lines with statement. This commit changes the component to set this props as optional (as before) and adds a new props "isValid" to put the label of the statement group in text-danger when the statement is not valid. no task id Forward-Port-Of: odoo/enterprise#84387
Original PR description
The aim of this commit is fixing a traceback when we have a statement group with no balance passed as props. It could happen when we have statement lines without any statement between 2 groups of statement lines with statement. This commit changes the component to set this props as optional (as before) and adds a new props "isValid" to put the label of the statement group in text-danger when the statement is not valid. no task id Forward-Port-Of: odoo/enterprise#84387
**PURPOSE** ESG (Environmental, Social, and Governance) module was built with one clear mission: to make ESG reporting simple, integrated, and affordable for every business. Today, ESG is no longer a nice-to-have, it's a legal, financial, and reputational necessity. With the EU's Corporate Sustainability Reporting Directive (CSRD) now in force, companies are required to report their environmental, social, and governance performance using formal frameworks like the European Sustainability Rep
Original PR description
**PURPOSE** ESG (Environmental, Social, and Governance) module was built with one clear mission: to make ESG reporting simple, integrated, and affordable for every business. Today, ESG is no longer a…
**PURPOSE**
ESG (Environmental, Social, and Governance) module was built with one clear mission: to make ESG reporting simple, integrated, and affordable for every business.
Today, ESG is no longer a nice-to-have, it's a legal, financial, and reputational necessity. With the EU's Corporate Sustainability Reporting Directive (CSRD) now in force, companies are required to report their environmental, social, and governance performance using formal frameworks like the European Sustainability Reporting Standards (ESRS).
But beyond compliance, the pressure is mounting from all sides: investors are assessing ESG risks before funding businesses, major clients are adding sustainability criteria to supplier evaluations, and consumers are choosing brands that act responsibly. At the same time, ESG opens up massive business opportunities; from lowering energy costs and improving employee retention to building long-term trust and brand loyalty.
That's where Odoo comes in. By natively integrating with apps like Accounting, Fleet, Payroll, and Employees, we automate ESG data collection, eliminating the manual burden and reducing the cost and time spent collecting the data required for carbon footprint reporting. Each business activity can be tracked, through expense type of account move lines, in real time, giving you an up-to-date view of your emissions and enabling you to measure the immediate impact of your sustainability efforts.
If you work with a carbon consultant, their configuration becomes a reusable asset, making year-on-year updates seamless. For environmental consultancies, we also offers the most affordable carbon tracking tool on the market enabling you to focus on expertise services while giving clients a powerful, integrated platform without the need for expensive external tools. With secure access rights, ESG professionals can collaborate directly on client data, just like accountants do.
With Odoo, ESG impact is no longer a burden or a side project, it becomes a natural, data-driven part of how you run your business.
**MODELS**
* Source Database (`esg.database`): connect to certified emission factor databases, including regional and sector-specific sources (e.g. ADEME, IPCC). Download the DB that the system proposes and that fit your business needs or upload yours by creating a new one.
* Gaz (`esg.gas`): includes the six gases defined under the Kyoto Protocol: CO₂, CH₄, N₂O, HFCs, PFCs, and SF₆. Each gas is assigned a Global Warming Potential (GWP) value, allowing for conversion into a standard unit — CO₂-equivalents (kgCO₂e). This ensures consistency and comparability across different emission sources, aligning with GHG Protocol standards.
* Emission Sources (`esg.emission.source`): grouped into three scopes based on their origin:
- Scope 1: Direct emissions from owned or controlled sources (e.g. fuel used in company cars or on-site combustion).
- Scope 2: Indirect emissions from purchased energy (e.g., electricity, steam, heating).
- Scope 3: All other indirect emissions from the value chain, including both upstream (e.g. supplier emissions, travel) and downstream (e.g. product use, waste). Scope 3 often represents the majority of total emissions.
* Emission factors (`esg.emission.factor`): coefficients which allows to convert activity data into GHG emissions.
- Computation method: physical vs monetary (choose how emissions are calculated)
- Physical: based on quantity and unit of measure: e.g. kg CO₂ per liter of fuel or per kWh — more precise.
- Monetary: based on amount and currency: e.g. kg CO₂ per € spent — useful when no physical data is available.
* Assignation Rules (`esg.assignation.line`): define how the emission factors will be assigned on the account move lines.
- Product level (e.g. laptop, printer)
- Partner level (e.g. emissions tied to a specific supplier)
- Account level (e.g. expense account 6700 for Office Equipment)
=> Product assignation takes precedence over partner and account, and partner assignation takes precedence over account.
* Activity type mapping (`esg.activity.type`): link each emission to a lifecycle activity type (e.g. Raw Materials, Transport, Energy).
* Other Emissions (`esg.other.emission`): emissions that are not linked to a journal entry. This allows for the inclusion of emissions from activities that are not directly tied to financial transactions, such as employee commuting or waste disposal.
**MENU ITEMS**
* Collect:
- Emissions: automatic data synchronization. Pulls data from Accounting for purchase and expense data and provides a “New” option to add Other Emissions (not linked to a journal entry) manually. The system will assign Emission Factor if there's a pre-configured assignation rule and if not, the user can add an emission factor on an emission manually.
- Employee commuting pivot table: uses data from the Employee (distance from home to office), Fleet (Vehicle model and associated emission factor (gCO₂/km)).
Apply the formula: `Days * Distance * 2 (round trip) * 3/7 (average number of office days per week) * Vehicle emission factor`
* Measure -> Environment:
- Carbon Analytics: visualize and analyze emissions per year, scopes (1,2,3), activity types (energy, transport, etc.), etc. To highlight where to act to have the biggest impact on your company's carbon footprint.
- Carbon Footprint Report: automatically generate your company's carbon footprint report: in tCO₂e (tonnes of CO₂ equivalent), by scopes, with gas repartition, aligned with “Le Bilan Carbone” and “GHG Protocol” requirements, available in downloadable PDF and Excel formats for submission or internal use.
* Measure -> Social:
- Gender Parity: view gender breakdown across departments, leadership levels, locations, job positions, etc.
- Pay Gap Calculation: automatically calculates the median hourly pay gap between male and female employees, following the EU method: `(Median male pay - Median female pay) / Median male pay * 100`
* Act:
- Initiatives as projects: Use the Project module to manage ESG actions.
[ task-4517841](https://www.odoo.com/odoo/project.task/4517841)
Related to https://github.com/odoo/odoo/pull/195951
Forward-Port-Of: odoo/enterprise#79004Forward-Port-Of: odoo/enterprise#84345 Forward-Port-Of: odoo/enterprise#83244
Original PR description
Forward-Port-Of: odoo/enterprise#84345 Forward-Port-Of: odoo/enterprise#83244
Before this commit, achievement were performed using records on account_move, sale_order and sale_order_log tables (+ move lines, order lines, products etc). Reading those table is extermely costly. We tried to limit what we fetched using context depending on the current action: - https://github.com/odoo/enterprise/commit/7c8621e71b1e8267cd6e0e7968cbb46705568e32 - https://github.com/odoo/enterprise/pull/80043 And we had to revert it here: https://github.com/odoo/enterprise/commit/c
Original PR description
Before this commit, achievement were performed using records on account_move, sale_order and sale_order_log tables (+ move lines, order lines, products etc). Reading those table is extermely costly.…
Before this commit, achievement were performed using records on account_move, sale_order and sale_order_log tables (+ move lines, order lines, products etc). Reading those table is extermely costly. We tried to limit what we fetched using context depending on the current action: - https://github.com/odoo/enterprise/commit/7c8621e71b1e8267cd6e0e7968cbb46705568e32 - https://github.com/odoo/enterprise/pull/80043 And we had to revert it here: https://github.com/odoo/enterprise/commit/c6ee48faa967342c958b4410e71b49bf453cd316 Using a period_domain in the context computed on fly in _where_calc was a bad idea. The record were correctly fetched but the following flow was broken: Go to an approved commission plan --> click on the commissions stat button --> everything is correct Now click on details for a commission line with non empty achived amount All the achievements are correct but when we click on "Details" of sale.commission.achievement.report (id=42) account_move (142), we may end up on another record. Because when the ORM does the fetch query, it will fetch sale.commission.achievement.report where id=42 and at that moment, the context is lost when we click on the line. Therefore as ids are recomputed, the line 42 is not the one corresponding to the account move 142 anymore. This commit ensure we avoid doing a cross join on account_move or sale_order or sale_order_log because these are really bad for performance and we select the record in a CTE. - We select them based on current users, teams if defined - We avoid fetching records outside of plan date values Forward-Port-Of: odoo/enterprise#84352 Forward-Port-Of: odoo/enterprise#82518
When a bank statement line has a partner name (from the bank), that is not in our database, we have a button to create it. Add the partner name from the bank as the default for the new partner. task-4749340 Forward-Port-Of: odoo/enterprise#84137
Original PR description
When a bank statement line has a partner name (from the bank), that is not in our database, we have a button to create it. Add the partner name from the bank as the default for the new partner. task-4749340 Forward-Port-Of: odoo/enterprise#84137