Monday, March 17, 2025
35 changes · 18.0
Resolved issues and error corrections
The website editor no longer treats harmless extra spaces in a page element's class information as a real change. This prevents users from seeing an unnecessary warning about losing changes when they simply open and discard the editor without editing content.
Original PR description
Before this commit, there was a bug that could be reproduced this way: - Add a whitespace at the end of the class attribute of the footer main snippet (e.g. by using the HTML editor) - Enter edit mode - Click on the footer - Discard the editor => Bug: a popup shows up saying you are about to lose changes... while you did not make any. This commit fixes that specific issue, also extending the test that was introduced at [1], although as advertised many "no changes" flow are still marking the page as dirty (e.g. just hovering any editor panel option). Note that there seems to be a deeper issue (although with no real breaking consequences) with the code surrounding this (see inline code comments), hopefully we won't have to care about this once the new HTML editor lands in master. [1]: https://github.com/odoo/odoo/commit/8e1bce010be2df8bd7144364fcbbe509d0441695
The Traceability Report PDF header now has more space between the reference and company name. This prevents the text from overlapping, making the report easier to read and more professional for users and customers.
Original PR description
Task: [4591489](https://www.odoo.com/odoo/49/tasks/4591489) Description of the issue/feature this PR addresses: The reference and company name in the header of Traceability Report are currently overlapping a bit. This PR increases the spacing of elements, to resolve the issue. Current behavior before PR: The formatting of the Traceability Report's header is incorrect, reference and company name are overlapping:  Desired behavior after PR is merged: The Traceability Report's header is displayed properly:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue on website portal pages where reactions to a message were shown under the publisher's comment instead of the original message. Reactions now appear where users expect them, making conversations clearer and easier to follow.
Original PR description
Before this commit, message reactions appeared at the bottom of the publisher's comment instead of the original linked message. This commit ensures they are correctly positioned under the original message. Before  After  task-4619148
Google Calendar synchronization now relies on the Google Account module to manage access tokens, keeping authentication responsibilities in the right place. This also ensures the correct client secret helper is used, improving compatibility with customizations that override Google credentials.
Original PR description
Before this commit, the `refresh_token` handling was done in the `calendar`
module, even though it relates to token management and should therefore be
handled by `google_account`, which manages tokens and requests to Google.
This also fixes the call to `get_param('google_calendar_client_secret')`, which should use the correct helper `_get_client_secret`, as it may be monkey-patched by another module.This fixes a typo in an automated website shop test so it looks for the correct sales order reference format. The change helps keep the online store testing process reliable and prevents false build failures.
Original PR description
the Subject input value is supposed to start with S0 instead of S00 Screenshot of where the tour fails:  build_error-116092
This fixes an issue that caused the Indian E-way Bill stock page checks to fail because of hidden fields in the page setup. The change helps keep the E-way Bill workflow stable and prevents related automated validation errors.
Original PR description
In this commit- We fix the invisible fields failing test for `l10n_in_ewaybill_stock` runbot error-https://runbot.odoo.com/runbot/build/76485337 opw-4628736 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents vendor bill forms from crashing when a user clears the Accounting Date field. If the field is empty, the system now uses the invoice date or today's date instead, allowing users to continue editing bills without interruption.
Original PR description
Currently, An error occurs when removing an `Accounting Date` from the invoice bill form view. Steps to produce: - Install the `account` module (with demo data). - Go to Invoicing / Vendors / Bills. - Create a bill, remove value from the Accounting Date, and click anywhere in form view. `AttributeError: 'bool' object has no attribute 'year'` An error occurs when the system tries to get a year part from the accounting date [1], but the value of accounting date is missing. Link 1: https://github.com/odoo/odoo/blob/a0205ffa3d4a42321a41503b8056a9f1c89328bb/addons/account/models/account_move.py#L3522 If the accounting date is not available, then provide a default value as an invoice date or today's date to resolve an issue. Sentry-6188666136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice previews for Argentina and Chile now include proper spacing below custom document headers. This prevents invoice content from appearing stuck to the header and makes the on-screen preview better match the PDF output.
Original PR description
latam document layouts with custom headers don't have any bottom margin. All default layouts use `<ul>` for the header, which by default has 1em bottom margin. When we replace these headers with our…
latam document layouts with custom headers don't have any bottom margin. All default layouts use `<ul>` for the header, which by default has 1em bottom margin. When we replace these headers with our custom ones with just a plain `<div>` which has no bottom margin by deafult, we end up in a situation where in HTML preview, the body is glued to the header in `l10n_ar`, which also looks off comapred to PDF preview. How to reproduce: - Create a DB - Install Accounting - Install AR localization - Move to "(AR) Responsable Inscripto" company - Switch Document Layout to "Bubble" format - Create an invoice with B2B customer. It will make sure the Document Type switches to "(1) INVOICES A". - Make sure the Journal is "Electronic Invoice" - Validate the invoice - Click on Preview button - In parallel generate a PDF report of the invoice too You will see that on the PDF report the header looks nice because of the existing spacing, but on preview it looks glued to the header opw-4411237
Customer invoices now format correctly even when a product description is very long. This prevents invoice layouts from breaking, helping businesses send clearer and more professional invoices to customers.
Original PR description
before this commit: the invoice is incorectly formated when the description for a product is very long after this commit: the invoice is corectly formated task-4640747 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 fixes automated website tour steps so helper-based actions correctly respect page unload checks. It helps make guided tests and onboarding flows more reliable when a step triggers navigation or page changes.
Original PR description
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the µbeforeUnload event that is done. In this commit, we fix this. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated test for expired promo codes so it no longer fails intermittently around midnight. The customer-facing behavior is unchanged: expired promo codes should still be rejected correctly.
Original PR description
The Issue: Before this commit, if a promo code was set to expire today and a user attempted to apply it tomorrow, an error was correctly thrown. Which is the correct behavior, However, due to what seems to be a delay caused by Runbot running all tests, the promo code sometimes gets applied the next day. This issue consistently occurs between 12 AM and 1 AM, as seen in the build error. The Fix: Since the original test checks a promo code one day after its expiration to see if its still applicable or not, we can adjust the expiration date to today +1 and run the test on day +2. runbot-112678
Invoice follow-up SMS reminders are now prepared in the customer’s preferred language instead of the sender’s language. This helps businesses communicate payment reminders more clearly and consistently with customers in multilingual environments.
Original PR description
Steps to reproduce: * Customer record has language different than user's language. * Customer form view -> Accounting Tab -> Invoice follow-ups -> Send * Check sms checkbox * sms template in user's language, it should be in customer's languange. opw-4599660
This fix adds a short wait so the Gantt schedule view finishes loading during the restaurant appointment test. It prevents random test failures, helping keep release validation more stable without changing user-facing behavior.
Original PR description
In this commit, we add a delay to ensure Gantt view will correclty be loaded after clicking on Gantt view button. This allow to fix an indeterministic behavior that can occurs in restaurant_appointment_tour tour.
The expected test data for Ecuador delivery guide documents was updated to match a recent XML change. This helps keep automated checks reliable and reduces false failures during release validation.
Original PR description
Commit 147c9ba6942 added a new node to the Ecuador delivery guide XML. However the node was not added to the TestECDeliveryGuide.test_send_delivery_guide_flow test (which had an active runbot exception at the time). We now add the node to the test's expected XML. runbot-160903
Code cleanup and technical improvements
This change updates internal test labeling in the web_tour module to use the newer Hoot tag format. It helps keep automated tests aligned with current standards without changing customer-facing behavior.
Original PR description
In this commit, we use new tag definition for Hoot in web_tour. 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
Miscellaneous changes
Currently, changing the plan of an analytic account won't do anything with regards to the analytic lines currently using that account: the value will stay recorded in a wrong field. This commit will update all the lines currently using that account in the column of the previous plan. opw-4338406 Forward-Port-Of: odoo/odoo#200655 Forward-Port-Of: odoo/odoo#199287
Original PR description
Currently, changing the plan of an analytic account won't do anything with regards to the analytic lines currently using that account: the value will stay recorded in a wrong field. This commit will update all the lines currently using that account in the column of the previous plan. opw-4338406 Forward-Port-Of: odoo/odoo#200655 Forward-Port-Of: odoo/odoo#199287
The barcode module’s automated tests were migrated from the older qUnit framework to Odoo’s newer Hoot test suite. This is an internal maintenance change that helps keep barcode testing easier to maintain without changing business functionality.
Original PR description
In this commit, we convert unit tests from qUnit to Hoot Suite. 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
**Issue** The timezone mismatch alert on the user view is not displayed as previously. Expected behavior: like in previous versions, show a warning to the user.  **Cause** A previous change (https://github.com/odoo/odoo/pull/137031) made invisible fields unnecessary if they are used in a python expression in the view. However, the field is needed here since it's used in a js widget. Forward-P
Original PR description
**Issue** The timezone mismatch alert on the user view is not displayed as previously. Expected behavior: like in previous versions, show a warning to the user.  **Cause** A previous change (https://github.com/odoo/odoo/pull/137031) made invisible fields unnecessary if they are used in a python expression in the view. However, the field is needed here since it's used in a js widget. Forward-Port-Of: odoo/odoo#197929
In a grouped kanban view (e.g. project tasks), especially on a slow network, quickly move several records from a column to another, and click on a record to open it. Before this commit, we switched to the opened record directly, without waiting for the ongoing rpcs (web_save, resequence), for each moved record. However, the `async` protection in the orm service prevent destroyed components from doing rpcs. As a consequence, a crash can occur if some moved records could not be saved before lea
Original PR description
In a grouped kanban view (e.g. project tasks), especially on a slow network, quickly move several records from a column to another, and click on a record to open it. Before this commit, we switched to the opened record directly, without waiting for the ongoing rpcs (web_save, resequence), for each moved record. However, the `async` protection in the orm service prevent destroyed components from doing rpcs. As a consequence, a crash can occur if some moved records could not be saved before leaving the kanban view. This commit ensures that we wait for all those operations to be done before leaving the kanban view. That way, all moved records are properly saved, and no crash occurs. Issue reported on our prod. 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#201761
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
Steps: - Go to /shop as a guest (without logging in). - Select a pricelist different from the default. - Add a product to the cart and proceed to checkout. - Fill in the address form and submit. - Observe that the pricelist is reset to the default instead of retaining the selected one. Issue - When a user selects a pricelist on the /shop page without logging in, the selected pricelist resets to the default during checkout after filling in the address form. Cause - The upda
Original PR description
Steps: - Go to /shop as a guest (without logging in). - Select a pricelist different from the default. - Add a product to the cart and proceed to checkout. - Fill in the address form and submit. -…
Steps: - Go to /shop as a guest (without logging in). - Select a pricelist different from the default. - Add a product to the cart and proceed to checkout. - Fill in the address form and submit. - Observe that the pricelist is reset to the default instead of retaining the selected one. Issue - When a user selects a pricelist on the /shop page without logging in, the selected pricelist resets to the default during checkout after filling in the address form. Cause - The update_address method updates the partner_id of the sale.order - During this process, the write method triggers a recomputation that resets the pricelist_id to the default instead of preserving the user-selected pricelist. Fix - Assign the selected pricelist to partner_sudo.property_product_pricelist before updating the sale order’s partner. - This ensures that the pricelist remains unchanged throughout the checkout process. Affected Version-saas-17.4 opw-4455367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199927
### Steps to reproduce the issue: (Easier to reproduce with demo data) 1. Create a Fixed Tax and assign it to a Product 2. Open POS session, add Product to Order 3. Add a Coupon Code: "10pc" - This code should give a 10% Discount on the Order 4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total ### Explanation: During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percen
Original PR description
### Steps to reproduce the issue:
(Easier to reproduce with demo data)
1. Create a Fixed Tax and assign it to a Product
2. Open POS session, add Product to Order
3. Add a Coupon Code: "10pc"
- This code should give a 10% Discount on the Order
4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total
### Explanation:
During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percentage taxes to be included, as they become part of the discount, fixed taxes are added to the amount.
### Fix reasoning:
The opposite issue was fixed in commit odoo/odoo@534de1e47ab882bfb1cc006bdf1fa00fc877c6c4, adapting the code to javascript.
opw-4506550
Forward-Port-Of: odoo/odoo#201176
Forward-Port-Of: odoo/odoo#200175…ields Commercial fields are supposed to be synchronized between a customer and their commercial entity. Nevertheless, the synchronization doesn't work for company_dependent fields whose values are only copied for the current company. This commit makes sure the values are properly synchronized for company_dependent fields (+ pricelist) between the contacts and their commercial partner. opw-4523466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi
Original PR description
…ields Commercial fields are supposed to be synchronized between a customer and their commercial entity. Nevertheless, the synchronization doesn't work for company_dependent fields whose values are only copied for the current company. This commit makes sure the values are properly synchronized for company_dependent fields (+ pricelist) between the contacts and their commercial partner. opw-4523466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201251
Steps to reproduce: 1) Install loca spanish 2) Create and post an invoice using the tax 4% G (goods) then create and post a related credit note 3) Check the Tax return report (Modelo 303): Issue: In Odoo 16, the base en cuota are negative (For box 14 and 15) In Odoo17 and 18, the base en cuota are positive (For box 14 and 15) Cause: The sign for the tax tags on the refund was wrong opw-4546566 Forward-Port-Of: odoo/odoo#197376
Original PR description
Steps to reproduce: 1) Install loca spanish 2) Create and post an invoice using the tax 4% G (goods) then create and post a related credit note 3) Check the Tax return report (Modelo 303): Issue: In Odoo 16, the base en cuota are negative (For box 14 and 15) In Odoo17 and 18, the base en cuota are positive (For box 14 and 15) Cause: The sign for the tax tags on the refund was wrong opw-4546566 Forward-Port-Of: odoo/odoo#197376
- Install the CRM app; - Activate leads from the settings; - Create an opportunity with an email address; - Create a lead with the same email address; - Save the lead; - Click on "Convert to Opportunity" (this opens a dialog); - Choose "Merge with existing opportunities"; - Click on "Create Opportunity"; Before this commit, a record not found error notification is displayed. This is because, when closing the dialog, we try to reload the current view and the record doesn't exist any m
Original PR description
- Install the CRM app; - Activate leads from the settings; - Create an opportunity with an email address; - Create a lead with the same email address; - Save the lead; - Click on "Convert to Opportunity" (this opens a dialog); - Choose "Merge with existing opportunities"; - Click on "Create Opportunity"; Before this commit, a record not found error notification is displayed. This is because, when closing the dialog, we try to reload the current view and the record doesn't exist any more. This causes an RPC to reload a view that we are leaving, which is not ideal. Now, we avoid reloading views that we are leaving when closing the dialog. opw-4630624 Forward-Port-Of: odoo/odoo#201503 Forward-Port-Of: odoo/odoo#201109
There are currently 2 issues with the "Gaps in the sequence" warning on journals in the accounting dashboard. (1) Sequence check per company issue: We query and thus do the the sequence check only on the moves of a single company. This e.g. fails though in the following case (all moves in the same journal) ``` move0: company_A move1: company_B move2: company_A ``` The query for company_A will find a gap between move0 and move2. But there is no gap (it just belongs to a different compa
Original PR description
There are currently 2 issues with the "Gaps in the sequence" warning on journals in the accounting dashboard. (1) Sequence check per company issue: We query and thus do the the sequence check only on…
There are currently 2 issues with the "Gaps in the sequence" warning on journals in the accounting dashboard. (1) Sequence check per company issue: We query and thus do the the sequence check only on the moves of a single company. This e.g. fails though in the following case (all moves in the same journal) ``` move0: company_A move1: company_B move2: company_A ``` The query for company_A will find a gap between move0 and move2. But there is no gap (it just belongs to a different company). (2) Lockdate per company issue: Consider the case that the child company is already locked but the parent is not. E.g ``` move0: parent company move1: child company (move is locked) move2: parent company ``` We would find a gap for the parent company. The "right" lock date to use for a journal is the lock date of the journal company: * A branch company is locked when the parent is locked. * Parent companies of the journal company can not add moves to the journal. So we will find all holes that can still be corrected. After this commit we query per lock date (instead of per company). In each query we check all the journals restricted by the same lock date. This solves both issues: (1) is solved since query all moves independent of the company (2) is not an issue since we use the "right" lock date (see reasoning above) opw-4548453 Forward-Port-Of: odoo/odoo#201931 Forward-Port-Of: odoo/odoo#201732
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a conversation A in Discuss app - click on "reply" on a message - open another conversation B in Discuss app - compose a message then send it => the message is posted in conversation A rather than B This happens because when changing conversation, the reply-to mode of the composer is kept. This is
Original PR description
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a…
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a conversation A in Discuss app - click on "reply" on a message - open another conversation B in Discuss app - compose a message then send it => the message is posted in conversation A rather than B This happens because when changing conversation, the reply-to mode of the composer is kept. This is the case because `messageToReplyTo` is a stateful component hook of the thread viewer such as the Discuss app. This is put there because it's shared to both the `Thread` and `Composer` components, respectively to show the message being replied (reduced opacity to all other messages) and for composer to contains the reply-to message. The cancelling of the reply-to mode was only occurring when the user manually cancel it. Changing conversation was not considered as cancelling. This commit fixes this issue. Task-4593206 Forward-Port-Of: odoo/odoo#198653
Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid. Also update the code that do the match of the document types related to docs types: * all cases that accepted A now also accept M documents * remove deprecated responsibility match * add match to new responsibility LATAM 1300 / Adhoc Task 47476 --- I confirm I have signed the CLA and read the PR
Original PR description
Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid.
Also update the code that do the match of the document types related to docs types:
* all cases that accepted A now also accept M documents
* remove deprecated responsibility match
* add match to new responsibility
LATAM 1300 / Adhoc Task 47476
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#201447
Forward-Port-Of: odoo/odoo#198247**Steps to reproduce:** - Install Accounting and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create an invoice without a customer reference - Print the invoice - Create the same invoice with a customer reference - Print the invoice **Issue:** The font size is smaller for the second invoice and the reference label in Arabic doesn't appear. **Cause:** The reference row in the printed invoice is separated in 3 columns like the other information, but the Bootstrap w
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create an invoice without a customer reference - Print the invoice - Create the same invoice with a customer reference - Print the invoice **Issue:** The font size is smaller for the second invoice and the reference label in Arabic doesn't appear. **Cause:** The reference row in the printed invoice is separated in 3 columns like the other information, but the Bootstrap width of the second column is 8 (i.e. col-8) instead of 2. As the first column has an offset of 6 as it is the case for all the rows, the row width exceeds the grid system size (i.e. 12) defined in Bootstrap. opw-4494547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201575
The test is failing due to an expired certificate, removing the module from tests for now. Forward-Port-Of: odoo/odoo#201971
Original PR description
The test is failing due to an expired certificate, removing the module from tests for now. Forward-Port-Of: odoo/odoo#201971
### Issue: The compute method of the json_popover raises a traceback if dates are not uniformly set on blocking operations. #### Steps to reproduce: - Create a bom for a product with 3 operations. - Allow operation dependancies and set op3 to be bloqued by op1 and op2. - Create an MO using that bom and confirm. - Try to set the date_start and date_finished on both op1 and op3 but not op2 - Save #### > Traceback: TypeError: '<' not supported between instances of 'bool' and 'datetime
Original PR description
### Issue: The compute method of the json_popover raises a traceback if dates are not uniformly set on blocking operations. #### Steps to reproduce: - Create a bom for a product with 3 operations. - Allow operation dependancies and set op3 to be bloqued by op1 and op2. - Create an MO using that bom and confirm. - Try to set the date_start and date_finished on both op1 and op3 but not op2 - Save #### > Traceback: TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ### Cause of the issue: The min and max call are simply performed by comparing boolean values with dates. opw-4511050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199975
\* applies to: `l10n_in`, `l10n_in_ewaybill_stock` - Before this commit: The fiscal position computation did not consider the company context, leading to errors in a multi-company environment. - After this commit: The issue is addressed using the `with_company()` method to ensure the correct company context is applied during fiscal position computation. opw-4615629 Forward-Port-Of: odoo/odoo#201515
Original PR description
\* applies to: `l10n_in`, `l10n_in_ewaybill_stock` - Before this commit: The fiscal position computation did not consider the company context, leading to errors in a multi-company environment. - After this commit: The issue is addressed using the `with_company()` method to ensure the correct company context is applied during fiscal position computation. opw-4615629 Forward-Port-Of: odoo/odoo#201515
Before this commit, the `test_smart_schedule_with_allocated_hours_and_deadlines` test fails when only `project_enterprise` module is installed because the allocated_hours on the tasks are recomputed. However, when timesheet_grid module is installed, the project inside the test has the timesheets feature enabled by default and so the allocated_hours are not recomputed because we suppose the allocated_hours on tasks inside that project can only be altered by the user when the tasks are already cre
Original PR description
Before this commit, the `test_smart_schedule_with_allocated_hours_and_deadlines` test fails when only `project_enterprise` module is installed because the allocated_hours on the tasks are recomputed. However, when timesheet_grid module is installed, the project inside the test has the timesheets feature enabled by default and so the allocated_hours are not recomputed because we suppose the allocated_hours on tasks inside that project can only be altered by the user when the tasks are already created. This commit checks in the test is timesheet_grid module is installed to give the right expected allocated_hours on tasks. runbot-108336 Forward-Port-Of: odoo/enterprise#79947
__Current behavior before commit:__ When clicking on the share button of a knowledge article, the `/knowledge/get_article_permission_panel_data` call is made twice. This is because the call to `loadPanel` is made inside the `onWillStart` as well as in the `useEffect`. The call made in the `onWillStart` was already removed in [this PR][1]. However it was added back in the [saas-17.1 forward-port][2] probably by mistake. __Description of the fix:__ Removed the call to `loadPanel` in the
Original PR description
__Current behavior before commit:__ When clicking on the share button of a knowledge article, the `/knowledge/get_article_permission_panel_data` call is made twice. This is because the call to `loadPanel` is made inside the `onWillStart` as well as in the `useEffect`. The call made in the `onWillStart` was already removed in [this PR][1]. However it was added back in the [saas-17.1 forward-port][2] probably by mistake. __Description of the fix:__ Removed the call to `loadPanel` in the `onWillStart`. opw-4603551 [1]: https://github.com/odoo/enterprise/pull/58825 [2]: https://github.com/odoo/enterprise/pull/59561 Forward-Port-Of: odoo/enterprise#81355
LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#81284 Forward-Port-Of: odoo/enterprise#79635
Original PR description
LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#81284 Forward-Port-Of: odoo/enterprise#79635