Daily updates from Odoo
Wednesday, April 30, 2025
36 changes · master
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