Daily updates from Odoo
Navigate
Branch
Thursday, April 3, 2025
39 changes
29 changes
Enhancements to existing features
Spreadsheet dashboard files across several business apps were updated to the latest internal data format. This prepares the dashboards for upcoming visual improvements such as cleaner table styling and row hover effects, with no immediate functional change expected for users.
Additional tests improve confidence that planning resources, reporting figures, and export behavior work as expected. This reduces the risk of regressions in planning, timesheet forecasting, and sales-related planning workflows without changing day-to-day user features.
Original PR description
_*= project_timesheet_forecast, project_timesheet_forecast_sale
This commit introduces multiple test cases to ensure robust functionality across various aspects of the planning modules.
- Test the creation of material resources and assigning roles to them.
- Validate the accurate calculation of the following measures in `Planning Analysis` report.
- Billable Allocated Hours
- Non-Billable Allocated Hours
- Remaining Hours
- Effective hours
- Verify that the default exported field is correctly included in the export fields
when the "I want to update data" option is selected.
task-3231758Field service, subscription, and stock-related workflows now assign the right manager permissions when demo defaults are unavailable. This helps keep core business scenarios working reliably across companies and sales subscriptions.
Original PR description
_*= project_sale_subscription, sale_subscription, industry_fsm_stock The default demo is not loading, and the default groups have been moved to the demo. Therefore, I had to apply the project manager group to the current user. task-4677936
The rental eCommerce module was updated to stay compatible with recent changes in the main Odoo website sales platform. This helps ensure rental product pages and shopping flows continue to work consistently after the broader platform update.
Original PR description
Adapt according to changes in community. [task-4447730](https://www.odoo.com/web#id=4447730&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Requires: - https://github.com/odoo/odoo/pull/197320 - https://github.com/odoo/upgrade/pull/7469
Operators can now record partial quantities produced directly from work orders, allowing the next work to move forward without waiting for the full operation to be marked done. This improves manufacturing flexibility and helps reduce reliance on confusing backorders.
Original PR description
Allow operators to register partial production on work orders, thereby liberating work orders in the queue before marking operations as done. This will make it much more flexible for users and also reduce the need for creating backorders, which can be quite messy and difficult to understand. Task [3504085](https://www.odoo.com/odoo/project/966/tasks/3504085) odoo/odoo#171062
This update improves how manufacturing work orders handle dependencies, preventing circular scheduling relationships that can disrupt planning. It should make production workflows more reliable and reduce the risk of blocked or confusing work order sequences.
BACS payments can now use UK account numbers and sort codes directly instead of relying only on IBAN details. This makes UK bank setup more flexible and prevents an error when creating a new direct debit mandate.
Original PR description
BACS was only supporting IBAN account type and extracting account number and sort code from it. Added support for BACS to handle account number and sort code(clearing number field) separately. task-4630586
Resolved issues and error corrections
This update adjusts internal app customizations so they stay aligned with the latest core Odoo method definitions. It helps prevent technical linting issues and reduces the risk of errors when these modules interact with the main platform.
Original PR description
See community branch for lint test. odoo/odoo#203296
The sale stock renting module now keeps the standard information needed to show product availability on sales order lines. This restores the forecast widget for storable products, helping sales users see stock availability when preparing orders.
Original PR description
Steps to reproduce: - Create a sale order - Add a line using a storable product Issue: There is no forecast widget on the line. Previous commit [1] replaced the base `fieldDependencies` of the widget when patching it instead of replacing them. Thus, since none of the expected fields where in the props, the widget was not displayed at all. [1] b90bbde
This fixes unstable automated tests for VOIP and room features so they run faster and more consistently. It reduces the risk of false failures during development and helps teams validate changes with less delay.
Original PR description
Issue: non-deterministic JS unit tests in VOIP. See commits for details. Community: https://github.com/odoo/odoo/pull/204471
Payslip calculations now use the same ordering as the lines shown to payroll users. This prevents cases where a salary rule appeared before Net Salary but was not included in that displayed total, improving consistency and confidence in payroll results.
Original PR description
Before this commit, the computation for hr.payslip.lines was done in a different order from how they are displayed, leading to UI inconsistencies. Steps to reproduce ----- 1. On the Salary Structure, add a new rule with the same sequence as Net Salary (200) but a lexicographically lower code (< NET) 2. Create a new payslip with this structure and select Compute Sheet 3. In the payslip lines list view, the line corresponding to the new rule will be before Net Salary but not factored into the Net Salary Cause ----- The `_order` of `hr.payslip.line` is by contract_id, sequence, code. But when they are computed from the rules in `_get_payslip_lines`, the rules are only sorted by sequence. This can result in a computation order different from the order displayed on the payslip, depending on the code and rule id. Solution ----- Update the sorting to match the payslip lines, and update `_order` of `hr.salary.rule` to reflect this as well. opw-4619598
This fix makes document-based accounting actions more reliable by allowing a journal to be identified either by its internal ID or by its code. It reduces the chance of errors when creating accounting entries from documents, especially in configurations that reference journals differently.
Original PR description
refactor account_create_account_move() to accept an ID of a journal or code of journal
This fixes a visual issue in Documents where the shortcut indicator could disappear when users dragged files over the search panel while holding Ctrl. Users now keep the expected visual guidance during drag-and-drop actions, reducing confusion.
Original PR description
Before this commit, when dragging documents over the search panel while holding the ctrl key the icon disappear preventing the user from the visual help. This commit fix the issue. Task-4689834
Finance-related documents are now organized using folders instead of tags. This keeps automated finance actions aligned with the folder structure, making document handling more consistent for users.
Original PR description
Files inside Finance folder are now managed in folders instead of tags. Changed the server actions to use the created folders.
The Documents app now opens the server actions list with a default filter showing only top-level actions. This makes the list easier to navigate and helps users focus on the actions most relevant for configuration or review.
Original PR description
Add Top-level actions filter to the documents server actions list by default
Code cleanup and technical improvements
Customer-facing subscription actions in the portal, such as changing plans and closing subscriptions, have been rebuilt using Odoo’s newer interaction framework. This keeps the same business capabilities while making the subscription portal code easier to maintain and align with ongoing platform modernization.
Original PR description
**PR Description:** - Replace public widgets for portal subscriptions with new Interaction alternatives. This continues the refactoring work for public widgets. **Steps to Reproduce the Features:** -…
**PR Description:**
- Replace public widgets for portal subscriptions with new Interaction alternatives.
This continues the refactoring work for public widgets.
**Steps to Reproduce the Features:**
- **SubscriptionChangePlan:**
- Log in as an **Admin**.
- Navigate to the **Subscriptions app** and open a subscription with a recurring payment.
- Modify the **Self-Service** section of the subscription plan to include an optional plan
(e.g., update "Monthly" to include "Yearly" as an option).
- If the modified plan isn’t available on an existing subscription, create a new subscription for a **portal user**.
- Log in as the **portal user** and open the subscription with the modified plan.
(Alternatively, you can preview it as an **Admin**.)
- The **Change Plan** button should appear.
To test the feature, append `&change_plan=true` to the URL.
- **SubscriptionCloseFinish & SubscriptionCloseSelect:**
- Navigate to **Subscriptions app** → **Configuration** → **Recurring Plans**.
- Create a new plan or modify an existing one.
- In the **Recurring Plans** form, enable the **Closable** option under the **Self-Service** section.
This allows customers to close their own subscriptions via the portal.
- Open any subscription and click **Preview**.
- The **Close Subscription** button should now be visible on the left.
Clicking it will trigger the two widgets.This change updates internal mobile app tests to use a shared helper for preparing web request data. It keeps test behavior consistent with the main Odoo codebase and reduces maintenance effort, with no expected impact on day-to-day users.
Original PR description
- use `build_rpc_payload` helper function in `HttpCase`. Related PR: [#196819][1] [1]: https://github.com/odoo/odoo/pull/196819
Miscellaneous changes
Following a change of behaviour of the library, hidden headers are not considered in a chart data, and the pie chart of Cost Repartition was stripped of its data. Task-4687551 Forward-Port-Of: odoo/enterprise#82673
Original PR description
Following a change of behaviour of the library, hidden headers are not considered in a chart data, and the pie chart of Cost Repartition was stripped of its data. Task-4687551 Forward-Port-Of: odoo/enterprise#82673
Description ----------- The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method `_search_user_has_access` is frequently called and quickly becomes a performance bottleneck. This is particularly noticeable when opening the Knowledge app, as it involves reading the displayed article along with loading the sidebar. This update optimizes the method as follows: - For generic article access, the opti
Original PR description
Description ----------- The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method…
Description
-----------
The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method `_search_user_has_access` is frequently called and quickly becomes a performance bottleneck. This is particularly noticeable when opening the Knowledge app, as it involves reading the displayed article along with loading the sidebar.
This update optimizes the method as follows:
- For generic article access, the optimization leverages the field `inherited_permission`, which already contains the propagated `internal_permission` of the article along the hierarchy. This removes the need to recompute these permissions dynamically with a complex query since the data has already been precomputed.
- For member access, the query logic has been revised while maintaining the same outcome: Previously, the process involved: `for all articles, append the member and their permission, recurse into child articles for all in-sync and permissionless articles, and propagate the member's permission. Finally, discard all articles without any set permission.`, The new approach reverses the logic to avoid the need for discarding at the end and iterating through all articles: `for the articles the member belongs to, propagate the member's permission to its child articles, provided the child is in-sync, has no explicit permission, and the partner is not already a member of that article.` Although the last condition may seem counterintuitive, the initial set of articles considered encompasses those the member is linked to already. This also avoids cases where a parent article's member permission would overwrite differing permissions on its child articles.
- Additionally, `set` manipulations are used to handle IDs, thereby preventing the injection of large ID lists into multiple domain leaves. This improves query parsing and avoids poor query execution plans that could be caused by excessively large ID lists.
Benchmark
---------
On odoo.com, opening the Knowledge app from the Apps dashboard:
| Request | Before | After | Speed-up |
|----------------------|--------|-------|----------|
| web_read | 1.69s | 160ms | **10x** |
| get_sidebar_articles | 1.64s | 160ms | **10x** |
In a shell, searching articles with `[('user_has_access', '=', True)]`:
| User Type | Before | After | Speed-up |
|-----------------------|--------|-------|----------|
| `sudo` | 251ms | 35ms | **7x** |
| regular internal user | 577ms | 58ms | **10x** |
Reference
---------
task-4633813
Notice
------
⚠️ Note to clients/partners that might read this: For the full benefits of the patch, deploy the indexes that were added in this PR. This can be done by Upgrading the module `knowledge`, or creating the indexes manually in database. The patch should still be a net-benefit even for database without the indexes deployed.
Forward-Port-Of: odoo/enterprise#82773
Forward-Port-Of: odoo/enterprise#80971When you uncheck the 'Other dependent' box, it keeps the value in the dependent fields. This leads to have values set on the employees that are not visible. To avoid this issue, we empty the 'dependent' fields when we uncheck the 'Other Dependent' checkbox. This is the same behaviour of what is done in the onchange on backend view. Forward-Port-Of: odoo/enterprise#82794
Original PR description
When you uncheck the 'Other dependent' box, it keeps the value in the dependent fields. This leads to have values set on the employees that are not visible. To avoid this issue, we empty the 'dependent' fields when we uncheck the 'Other Dependent' checkbox. This is the same behaviour of what is done in the onchange on backend view. Forward-Port-Of: odoo/enterprise#82794
We need to use the payment method linked to the biggest paid amount, not the payment method linked to the biggest order. Forward-Port-Of: odoo/enterprise#82693
Original PR description
We need to use the payment method linked to the biggest paid amount, not the payment method linked to the biggest order. Forward-Port-Of: odoo/enterprise#82693
`prevent_zero_price_sale` was not set according to the right prices for `website_sale_renting` and `website_sale_subscription` opw-4650460 See also: https://github.com/odoo/odoo/pull/202867 Forward-Port-Of: odoo/enterprise#82685 Forward-Port-Of: odoo/enterprise#82082
Original PR description
`prevent_zero_price_sale` was not set according to the right prices for `website_sale_renting` and `website_sale_subscription` opw-4650460 See also: https://github.com/odoo/odoo/pull/202867 Forward-Port-Of: odoo/enterprise#82685 Forward-Port-Of: odoo/enterprise#82082
Bug: When creating a new payslip for a salesperson with work entries of code LEAVE1731, we would get a traceback. Reason: Since we were creating the record and did not yet save, the code was calling a method that did an SQL query on ids of self which is empty. Fix: We created a new method that uses the orm instead to handle this specific case. Forward-Port-Of: odoo/enterprise#78269
Original PR description
Bug: When creating a new payslip for a salesperson with work entries of code LEAVE1731, we would get a traceback. Reason: Since we were creating the record and did not yet save, the code was calling a method that did an SQL query on ids of self which is empty. Fix: We created a new method that uses the orm instead to handle this specific case. Forward-Port-Of: odoo/enterprise#78269
This commit addresses post merge fixes in the UI after the big rework of the sidebar and UI improvements: - Fix alignment of the sign items when being dropped, as from now on sign items follow the pre-defined alignment and are not forced to be rendered in the center anymore. task-4555838 Forward-Port-Of: odoo/enterprise#79448
Original PR description
This commit addresses post merge fixes in the UI after the big rework of the sidebar and UI improvements: - Fix alignment of the sign items when being dropped, as from now on sign items follow the pre-defined alignment and are not forced to be rendered in the center anymore. task-4555838 Forward-Port-Of: odoo/enterprise#79448
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashe
Original PR description
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashes. Solution ======== We can simply blacklist that model when searching for relations to add opw-4513295 Forward-Port-Of: odoo/enterprise#81068
In the Knowledge editor, the "New Article" button uses a "pen" icon, while most buttons for creating a new record in Odoo use a "plus" icon. To ensure consistency across views, we are replacing the "pen" icon with a "plus" icon. task-4690444 Forward-Port-Of: odoo/enterprise#82741
Original PR description
In the Knowledge editor, the "New Article" button uses a "pen" icon, while most buttons for creating a new record in Odoo use a "plus" icon. To ensure consistency across views, we are replacing the "pen" icon with a "plus" icon. task-4690444 Forward-Port-Of: odoo/enterprise#82741
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a no
Original PR description
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this…
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer. While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0. When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer. As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again. opw-4681035 Forward-Port-Of: odoo/enterprise#82754
Isuue: - When on a relatively slower network, if we double click the comments icon present on the social media post, the comments dialog box opens up twice. - Can be spotted easily on the runbot as well. Video of the issue https://drive.google.com/file/d/1abe7Cq3otsVNH4hGRHFV34jC3uIGHY6m/view?usp=drive_link Reason: - There is no existing mechanism present to prevent this kind of scenario. Fix: - We simply use a flag to prevent this. We set/reset the value as we desire. Task-418
Original PR description
Isuue: - When on a relatively slower network, if we double click the comments icon present on the social media post, the comments dialog box opens up twice. - Can be spotted easily on the runbot as well. Video of the issue https://drive.google.com/file/d/1abe7Cq3otsVNH4hGRHFV34jC3uIGHY6m/view?usp=drive_link Reason: - There is no existing mechanism present to prevent this kind of scenario. Fix: - We simply use a flag to prevent this. We set/reset the value as we desire. Task-4184968 Forward-Port-Of: odoo/enterprise#82717 Forward-Port-Of: odoo/enterprise#82411
After the refactor by https://github.com/odoo/enterprise/commit/84cc09959d82dbceb4fe673b85464ef3d8630606 the noCertificado field in the COA (Chart of Accounts) report became invalid. - On a Mexican company, generate the COA report from the Trial Balance. - In the generated XML, the noCertificado tag exceeds 20 characters. This tag should contain exactly 20 characters and match the noCertificado from the CFDI report. This commit applies the same string manipulation for the COA repoart a
Original PR description
After the refactor by https://github.com/odoo/enterprise/commit/84cc09959d82dbceb4fe673b85464ef3d8630606 the noCertificado field in the COA (Chart of Accounts) report became invalid. - On a Mexican company, generate the COA report from the Trial Balance. - In the generated XML, the noCertificado tag exceeds 20 characters. This tag should contain exactly 20 characters and match the noCertificado from the CFDI report. This commit applies the same string manipulation for the COA repoart as the cfdi report (in the _add_certificate_cfdi_values method in the l10n_mx_edi module) source: http://www.sat.gob.mx/esquemas/ContabilidadE/1_1/BalanzaComprobacion/BalanzaComprobacion_1_1.xsd opw-4644489 Forward-Port-Of: odoo/enterprise#82430
10 changes
Resolved issues and error corrections
Fixes an issue in Studio where extra items in a Kanban card footer could overlap with the next card and become impossible to click. Users editing Kanban views can now reach and select those overflowing elements while preserving the normal view appearance.
Original PR description
In studio, editing a kanban, activate show invisible elements if needed Before this commit, when the footer had many items, those were not wrapped so, they overflew under the next card and were unreachable and unclickable. After this commit the overflowing elements are reachable and clickable, but still outside of the kanban box. They just have a z-index high enough to be visible and reachable. The motivation behind this choice is that we cannot really apply targetted visual rules as those would betray the actual visual on the view in normal mode. task-4609581
The barcode app now displays image previews and dialogs without them covering each other incorrectly. This prevents visual confusion and makes barcode-related workflows smoother when viewing attached files or images.
Original PR description
This commit fixes the overlapping between the dialog and file viewer due to a combination of the z-index value set by the .modal class and the .fixed-top utility class. This is the counterpart of the related community change in FileViewer.
The manufacturing change process now counts engineering change orders separately for products and bills of materials. This prevents misleading counts and avoids showing empty results when users open the ECO smart button.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Create a BoM - Go back to the product form and create an ECO: - Apply on: “Bill of Materials” - The created BoM will be selected…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a BoM
- Go back to the product form and create an ECO:
- Apply on: “Bill of Materials”
- The created BoM will be selected automatically.
- Save.
- Return to the product form.
- The ECO count in the smart button is 1.
- Click on it.
Problem:
No ECO is displayed because the domain filters only ECOs applied to the product:
https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed500f580/mrp_plm/models/product.py#L17-L20
Solution:
only ECOs of type "Product" should be counted in the product form.
Issue 2:
- Try updating the "Apply on" field of the ECO to “Product.”
Problem:
The "Bill of Materials" field becomes invisible but is not cleared. As a result, when counting the number of ECOs linked to the BoM, the count will be incorrect.
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4653598This fixes how German balance sheets calculate profit or loss for the current and previous fiscal years. The correction helps ensure carried-forward profit or loss and net income figures are reported in the right period, improving financial statement accuracy.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/82656 Profit and loss from previous year was not well calculated on the balance sheet. With this commit, we change the date scope for the `Net profit/loss for the year` line from `normal` to `from_fiscalyear`. We also change the way we calculate `Profit carried forward/loss carried forward` and `Net income/loss for the year` lines. opw-3663626
This update adjusts an internal Knowledge app test so it automatically uses the latest available HTML migration version. This reduces maintenance effort and helps prevent future test failures when new HTML versions are introduced.
Original PR description
Dynamically use the latest `html_migrations` version in the `knowledge_history_tour` to avoid having to update the test every time a new html version is deployed. task-4640490
The sales spreadsheet demo data was corrected so the Cost Repartition pie chart displays its values again. This prevents demo dashboards from appearing incomplete after a library behavior change around hidden headers.
Original PR description
Following a change of behaviour of the library, hidden headers are not considered in a chart data, and the pie chart of Cost Repartition was stripped of its data. Task-4687551
Miscellaneous changes
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a no
Original PR description
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this…
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer. While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0. When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer. As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again. opw-4681035 Forward-Port-Of: odoo/enterprise#82754
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashe
Original PR description
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashes. Solution ======== We can simply blacklist that model when searching for relations to add opw-4513295 Forward-Port-Of: odoo/enterprise#81068
Isuue: - When on a relatively slower network, if we double click the comments icon present on the social media post, the comments dialog box opens up twice. - Can be spotted easily on the runbot as well. Video of the issue https://drive.google.com/file/d/1abe7Cq3otsVNH4hGRHFV34jC3uIGHY6m/view?usp=drive_link Reason: - There is no existing mechanism present to prevent this kind of scenario. Fix: - We simply use a flag to prevent this. We set/reset the value as we desire. Task-418
Original PR description
Isuue: - When on a relatively slower network, if we double click the comments icon present on the social media post, the comments dialog box opens up twice. - Can be spotted easily on the runbot as well. Video of the issue https://drive.google.com/file/d/1abe7Cq3otsVNH4hGRHFV34jC3uIGHY6m/view?usp=drive_link Reason: - There is no existing mechanism present to prevent this kind of scenario. Fix: - We simply use a flag to prevent this. We set/reset the value as we desire. Task-4184968 Forward-Port-Of: odoo/enterprise#82717 Forward-Port-Of: odoo/enterprise#82411
Relocated the get_fiscal_year_start_date method from l10n_in_reports_gstr to l10n_in_reports to ensure availability even if the GSTR module is uninstalled. This improves modularity and prevents dependency issues. Trace-back: ```RPC_ERROR Odoo Server Error Occured on 77578514-18-0-all.runbot143.odoo.com on model account.report and id 10 on 2025-04-01 13:02:27 GMT Traceback (most recent call last): File "/data/build/odoo/odoo/http.py", line 1962, in _transactioning return s
Original PR description
Relocated the get_fiscal_year_start_date method from l10n_in_reports_gstr to l10n_in_reports to ensure availability even if the GSTR module is uninstalled. This improves modularity and prevents…
Relocated the get_fiscal_year_start_date method from l10n_in_reports_gstr to l10n_in_reports to ensure availability even if the GSTR module is uninstalled.
This improves modularity and prevents dependency issues.
Trace-back:
```RPC_ERROR
Odoo Server Error
Occured on 77578514-18-0-all.runbot143.odoo.com on model account.report and id 10 on 2025-04-01 13:02:27 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 1962, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http.py", line 1929, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 36, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/api.py", line 533, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 5225, in get_report_information_readonly
return self.get_report_information(options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports_cash_basis/models/account_report.py", line 17, in get_report_information
info = super().get_report_information(options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 5209, in get_report_information
'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2544, in _get_lines
dynamic_lines = self._get_dynamic_lines(options, all_column_groups_expression_totals, warnings=warnings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2996, in _get_dynamic_lines
rslt = self.env[self.custom_handler_model_name]._dynamic_lines_generator(self, options, all_column_groups_expression_totals, warnings=warnings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 173, in _dynamic_lines_generator
self._get_out_of_fiscal_year_reversed_moves(options)
File "/data/build/enterprise/l10n_in_reports/models/l10n_in_report_handler.py", line 146, in _get_out_of_fiscal_year_reversed_moves
('reversed_entry_id.invoice_date', '<', AccountMove.get_fiscal_year_start_date(self.env.company, datetime.strptime(options['date']['date_to'], '%Y-%m-%d')))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.move' object has no attribute 'get_fiscal_year_start_date'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3153:163)
at XMLHttpRequest.<anonymous> (https://77578514-18-0-all.runbot143.odoo.com/web/assets/3b85f28/web.assets_web.min.js:3158:13)```
Forward-Port-Of: odoo/enterprise#82681