Daily updates from Odoo
Wednesday, November 20, 2024
36 changes · master
Enhancements to existing features
This update modernizes how several Odoo apps define extra database indexes, helping keep data access reliable and easier to maintain. The change is internal and should not alter day-to-day user workflows, but it supports smoother performance and future upgrades.
Original PR description
Use `model.Index` for additional indexes. odoo/odoo#187538
The Twitter/X integration now reflects X's stricter privacy rules for likes, so users can still see like counts but no longer see who liked a post or retrieve posts liked by a specific user. Existing social streams will avoid crashing when X returns empty like details, and duplicate feed items stay consistent when a user likes a post.
Original PR description
The X platform announced that they were updating their policy on likes. These changes also impacts their API, this commit updates the social_twitter module to handle this change.
The API has been changed so that when accessing the Likes lookup endpoints, the resulting response will contain data about the accessed posts if it belongs to the authenticated user.
It is still possible to fetch the like_counts for all posts, but not the details of each like.
This disables any user to evaluate who is liking its posts. This also blocks any attempt to retrieve the posts liked by a specific user.
If a user tries to access these endpoints the resulting response will be:
```
{
"meta": {
"result_count": 0
}
}
```
These responses aren't considered errors so exisiting streams using this endpoint will not crash.
But they will not contain any fresh post and won't be able to be refreshed.
task-3986158The mobile-related test suites for web and HR mobile have been updated to use the newer testing framework. This improves maintainability and reliability of internal quality checks without changing day-to-day user workflows.
Original PR description
task-4028335
Studio users can now configure whether records can be duplicated from form and list views. This gives businesses more control over user actions and helps prevent unintended record copies where duplication should not be allowed.
Original PR description
This PR adds the 'duplicate' property to forms and list views. It's true by default and when set to false will add the `duplicate="true"` attribute, when true the attribute is removed Task ID: 4286087
The Mexican e-invoicing setup has been cleaned up so the relevant fields are added consistently across all accounting moves, not just customer invoices. This reduces configuration gaps and makes the view structure easier to maintain going forward.
Original PR description
The 3 fields were only added to the out_invoice view while it should have been on all moves. As we were in stable, we had to add a view inheriting each of the different move view. Now, we should remerge them and inherit the right view.
Resolved issues and error corrections
This fix adds missing test dependencies for Helpdesk Timesheet and Sales Timesheet Enterprise after related model changes. It helps keep automated checks stable, reducing the risk of disruptions in future updates.
Original PR description
[*] sale_timesheet_enterprise Purpose of this commit: Following the changes in PR https://github.com/odoo/odoo/pull/187029 the removal of certain model definitions caused test cases in the specified modules to fail. This commit resolves the issue by adding the necessary model dependencies. Community PR: https://github.com/odoo/odoo/pull/187029 Part of task-3818666
The payroll sales commission tests now calculate expected commissions from the sales order total instead of fixed product prices. This prevents unrelated price list settings from causing false test failures, improving reliability for payroll commission validation.
Original PR description
If a pricelist matches the test product, the commission will be affected. This is one more repeat of odoo/odoo@abe8e38ccc18cfba77317d3fdaf4a066b5f69b79: it's possible for a module to set up a universally applicable pricelist (like `pos_pricer` which sets a 20% discount on everything). In the presence of such a module, tests with hard-coded "output" prices will fail. A common workaround is to disable all pricelists when creating the test, but in this case it seems reasonably easy (and correct) to use the SO's total amount as computation basis.
Enabling UPS delivery in Inventory settings now installs the current UPS integration instead of the legacy one. This prevents users from being placed on the outdated connector and ensures the expected shipping setup is activated.
Original PR description
Steps to reproduce the bug:
- Go to the inventory settings:
- Enable the UPS delivery
Problem:
The Legacy UPS is installed instead of the new one
opw-4341776Code cleanup and technical improvements
The internal file layout of multiple Point of Sale related modules has been reorganized to match the newer structure. This helps keep development and maintenance consistent across country-specific, payment, restaurant, IoT, and self-ordering POS features without introducing intended functional changes for business users.
Original PR description
Reorganization of all pos submodules to follow its new file structure Here is the list of all reorganized modules : - community: l10n_ar_pos, l10n_co_pos, l10n_es_edi_tbai_pos, l10n_es_pos, l10n_gcc_pos, l10n_in_pos, pos_adyen, pos_discount, pos_epson_printer, pos_event, pos_hr, pos_loyalty, pos_mercado_pago, pos_online_payment, pos_paytm, pos_razorpay, pos_restaurant, pos_restaurant_adyen, pos_sale, pos_self_order_epson_printer, pos_six, pos_sms, pos_stripe, pos_viva_wallet - enterprise: l10n_cl_edi_pos, l10n_de_pos_cert, l10n_ec_edi_pos, l10n_mx_edi_pos, l10n_pe_edi_pos, pos_avatax, pos_iot, pos_iot_six, pos_preparation_display, pos_restaurant_appointment, pos_self_order_iot, pos_settle_due, whatsapp_pos community PR: https://github.com/odoo/odoo/pull/186724 task-id: 4290514
Product category demo data has been simplified across several business apps, making sample data easier to maintain and understand. The update also improves how default accounts are selected based on each company's localization, helping accounting behavior better match local settings.
Original PR description
This commit clean category data and demo data to have flat catagory and improve related logic to get default accounts based on company localization from company record. task-3941328 Co-authored-by: Dev Reshamiya <dere@odoo.com> Co-authored-by: Kartik Chavda <kcv@odoo.com>
This update modernizes how automated product tours detect visible items during testing. It helps keep test behavior aligned with the current platform tools, reducing false positives and improving reliability without changing day-to-day user workflows.
Original PR description
In this commit, we replace the use of _legacyIsVisible by the visible option of hoot which refers to isVisible function of hoot-dom.js. This change implies changes in a few tours. For information, _legacyIsVisible accepts elements with a width of 0 or a length of 0 (which is a bit absurd) while isVisible does not, which implies the changes where we just add :not(:visible) to the trigger. The other main modifications implies tours where you have to hover the trigger to then see the element you want to click on. task~3974087 https://github.com/odoo/odoo/pull/175964
This update standardizes internal Point of Sale JavaScript method names to a consistent camelCase style across POS and related localization modules. It should not change how users work with the system, but it improves code consistency and maintainability for future updates.
Original PR description
In this commit: -------------------- - Renamed all js methods in point_of_sale and all related modules of point_of_sale to camelCase from snake_case. Related PR: https://github.com/odoo/odoo/pull/185252 Task: 4269182
Miscellaneous changes
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quic
Original PR description
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quickly by tweaking the value directly. task-3382308 Forward-Port-Of: odoo/enterprise#71793
commit [1] removes the hard-coded description on appointment calendar events. We still want to use the "attendee description" on crm leads as questions are not easily accessible from there. [1] 8b9a1a4462453bf64e7bc1307ededd0d127a27fa Forward-Port-Of: odoo/enterprise#74161
Original PR description
commit [1] removes the hard-coded description on appointment calendar events. We still want to use the "attendee description" on crm leads as questions are not easily accessible from there. [1] 8b9a1a4462453bf64e7bc1307ededd0d127a27fa Forward-Port-Of: odoo/enterprise#74161
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating th
Original PR description
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating the 325.50 form leads to a traceback. After the commit: Those irrelevant moves are ignored and the process carry on smoothly. task-id: None - Issue spotted on next ## [FIX] l10n_be_reports: 281.50, no 0-0-0-0-0 form The aim of this commit is to avoid generating a 281.50 form if there isn't any amounts to fill in the form. task-id: None - Dicussed with TSB Forward-Port-Of: odoo/enterprise#74142 Forward-Port-Of: odoo/enterprise#73842
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change. Steps to reproduce: ------------------- * Setup a preparation display for a PoS restaurant * O
Original PR description
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point…
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change. Steps to reproduce: ------------------- * Setup a preparation display for a PoS restaurant * Open PoS and add product A to the order * Double click on the order line to mark it as skip change * Add the same product to the order and click on the order button * At this point the preparation display should only show one product A * Add another different product B to the order * Click on the order button > Observation: The preparation display shows the product B and a second product A Why the fix: ------------ Instead of filtering based on the product we filter directly based on the line UUID that is unique and should avoid any further errors opw-4322597 Forward-Port-Of: odoo/enterprise#73826
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them. Moreover this commit fix the sign tests. This commit aims to fix an issue with test_archived_requests_dont_send_reminders. Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be use
Original PR description
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them.…
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them. Moreover this commit fix the sign tests. This commit aims to fix an issue with test_archived_requests_dont_send_reminders. Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be used. Another issue is that when we archive a sign request, its state is set to 'canceled', and for canceled sign requests we cannont update the validity, however the test was trying to update the validity (as a way of jumping to the future). But this is not the correct way of doing it, since we shouldn't change the validity if state is canceled. To fix the issue, a mock_datetime_and_now is introduced. Note: this is the backport of https://github.com/odoo/enterprise/pull/73156 task: 4294860 Forward-Port-Of: odoo/enterprise#74082
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#74078
Original PR description
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#74078
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
Original PR description
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
The "Predial Account" column appeared in all signed invoices, regardless of whether the invoice lines included rental products with a predial account. This resulted in a non-organized layout with an empty column for most invoices. Steps to reproduce: 1. Install the l10n_mx_edi module. 2. Create and sign an invoice with any product and customer. Expected behavior: The "Predial Account" column should only be displayed when the invoice contains products with a predial account. Actual be
Original PR description
The "Predial Account" column appeared in all signed invoices, regardless of whether the invoice lines included rental products with a predial account. This resulted in a non-organized layout with an empty column for most invoices. Steps to reproduce: 1. Install the l10n_mx_edi module. 2. Create and sign an invoice with any product and customer. Expected behavior: The "Predial Account" column should only be displayed when the invoice contains products with a predial account. Actual behavior: The "Predial Account" column is displayed in all invoices, even when it's empty. opw-4233358 Forward-Port-Of: odoo/enterprise#72364
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Community: https://github.com/odoo/odoo/pull/187269 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174) Forward-Port-Of: odoo/enterprise#73851
Original PR description
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Community: https://github.com/odoo/odoo/pull/187269 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174) Forward-Port-Of: odoo/enterprise#73851
As we immediatly call button_done on the wworkorder, the start_date is greater than the end_date which raises a user error. So we start the workorder before setting it to done Forward-Port-Of: odoo/enterprise#74139
Original PR description
As we immediatly call button_done on the wworkorder, the start_date is greater than the end_date which raises a user error. So we start the workorder before setting it to done Forward-Port-Of: odoo/enterprise#74139
In this commit, we simplify steps of the tour that check there are no add buttons in readonly mode. Forward-Port-Of: odoo/enterprise#74073
Original PR description
In this commit, we simplify steps of the tour that check there are no add buttons in readonly mode. Forward-Port-Of: odoo/enterprise#74073
This commit adds the missing neutralization necessary for the l10n_uk_hmrc module introduced in [1]. [1]: https://github.com/odoo/enterprise/pull/66766 Forward-Port-Of: odoo/enterprise#74036
Original PR description
This commit adds the missing neutralization necessary for the l10n_uk_hmrc module introduced in [1]. [1]: https://github.com/odoo/enterprise/pull/66766 Forward-Port-Of: odoo/enterprise#74036
The pricelist rule is now returned by the configurator methods, to be able to deduce the right strikethrough price. See also odoo/odoo#187436 Forward-Port-Of: odoo/enterprise#73993
Original PR description
The pricelist rule is now returned by the configurator methods, to be able to deduce the right strikethrough price. See also odoo/odoo#187436 Forward-Port-Of: odoo/enterprise#73993
This commit fixes two issues with the `lot_id` field in the move line form view in the Barcode app for the manufacturing operations. 1. The `lot_id` field was displayed when no product was selected. 2. The `lot_id` field was not displayed for by-product lines created at the creation of the MO. The first issue was there because the compute fields to determine if we want to hide `lot_id` and/or `lot_name` were false by default. The second issue was there because those fields depend of the
Original PR description
This commit fixes two issues with the `lot_id` field in the move line form view in the Barcode app for the manufacturing operations. 1. The `lot_id` field was displayed when no product was selected. 2. The `lot_id` field was not displayed for by-product lines created at the creation of the MO. The first issue was there because the compute fields to determine if we want to hide `lot_id` and/or `lot_name` were false by default. The second issue was there because those fields depend of the line's picking code which depends of the line's picking type which depend of the line's `production_id`. The issue is by-product lines has no `production_id` set. Forward-Port-Of: odoo/enterprise#73241
Issue: In the Chilean POS localization, the checkbox contained in the invoice button is always checked. This is confusing, since it seems the option is selected even when it isn't. Cause: By default, the checkbox depends on the order's "is_to_invoice" return value. In the Chilean POS, the "to_invoice" value is set to true by default and never updated, so "is_to_invoice" always returns true. Clicking on the invoice button only updates the value of the "invoice_type" field. Solution: Repl
Original PR description
Issue: In the Chilean POS localization, the checkbox contained in the invoice button is always checked. This is confusing, since it seems the option is selected even when it isn't. Cause: By default, the checkbox depends on the order's "is_to_invoice" return value. In the Chilean POS, the "to_invoice" value is set to true by default and never updated, so "is_to_invoice" always returns true. Clicking on the invoice button only updates the value of the "invoice_type" field. Solution: Replace the checkbox with one that uses the "invoice_type" field through the "isFactura" function. Ticket: opw-4298996 Forward-Port-Of: odoo/enterprise#73444
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall `account_followup` 3) Open the `partner ledger` report from the reporting 4) Click the `send` button and then `send & print` button Error:- ``` 'res.partner' object has no attribute '_get_partner_account_report_attachment' ``` The `_get_partner_account_report_attachment` method is define
Original PR description
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall…
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall `account_followup` 3) Open the `partner ledger` report from the reporting 4) Click the `send` button and then `send & print` button Error:- ``` 'res.partner' object has no attribute '_get_partner_account_report_attachment' ``` The `_get_partner_account_report_attachment` method is defined in `account_followup` and is referenced in `account_reports`. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_followup/models/res_partner.py#L295 When the user uninstalls the `followup` it leads to the above traceback when the below line of code executes. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_reports/wizard/account_report_send.py#L250 We can resolve this issue by moving the code from `account_followup` to `account_reports`. As we can see that `account_followup` depends on `account_reports`. sentry-6069400574 Forward-Port-Of: odoo/enterprise#74064
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73763 Forward-Port-Of: odoo/enterprise#73496
Original PR description
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73763 Forward-Port-Of: odoo/enterprise#73496
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOd
Original PR description
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOdoo with the latter causing this error. The option to cancel sign requests is available in saas-17.4 and above only. opw-4261794 Forward-Port-Of: odoo/enterprise#73375
task-4246523 Forward-Port-Of: odoo/enterprise#72701
Original PR description
task-4246523 Forward-Port-Of: odoo/enterprise#72701
A traceback may occur when the user tries to upload a vendor bill. Where the invoice has an Indian company and a rounding error. Error:- ``` KeyError: 'groups_by_subtotal' ``` This is because of the major refactor done from the below commit to calculate the tax_totals in the `account.tax` https://github.com/odoo/odoo/commit/73d585a85b093db07e4eb5541aaa03e74af5fd62 Initially, we have a `groups_by_subtotal` in tax_totals, but after the refactor we return subtotals containing `
Original PR description
A traceback may occur when the user tries to upload a vendor bill. Where the invoice has an Indian company and a rounding error. Error:- ``` KeyError: 'groups_by_subtotal' ``` This is because of the major refactor done from the below commit to calculate the tax_totals in the `account.tax` https://github.com/odoo/odoo/commit/73d585a85b093db07e4eb5541aaa03e74af5fd62 Initially, we have a `groups_by_subtotal` in tax_totals, but after the refactor we return subtotals containing `tax_groups`. The code has been adjusted according to the above commit by take the maximum `tax_group` based on `tax_amount_currency` and added the `fixed_round_error` to resolve this issue. sentry-5963987892 Forward-Port-Of: odoo/enterprise#71976
Reproduce: 1. Configure a default filter on Documents so that not all documents are visible 2. Select a document that does not match this default filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar / refresh page 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs, not otherwise (refresh the page after deselecting the document in the folder).
Original PR description
Reproduce: 1. Configure a default filter on Documents so that not all documents are visible 2. Select a document that does not match this default filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar / refresh page 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs, not otherwise (refresh the page after deselecting the document in the folder). Task-4342960 Forward-Port-Of: odoo/enterprise#74028
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - disable max_to_replenish_qty: `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - make replenish input cells readonly: When showing a
Original PR description
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the…
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - disable max_to_replenish_qty: `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - make replenish input cells readonly: When showing a bigger period type than the one selected in the settings (e.g. year > week), the replenish input fields are made readonly. This is because there's a loss of precision when showing bigger period and changing values may have unintended consequences that way. Also remove the colors on the replenish cells when in readonly. >[IMP] mrp_mps: more tests Adding more tests for various cases in MPS. Also, do `_get_date_range` in `setUpClass` for the month periods since it is the default. Remove all `_get_date_range` apart from when the default period has been changed in the settings. >[FIX] mrp_mps: use real dates with lead times When a bom has a lead time, we want to use the real date to compute the indirect demand forecast of the components in the MPS. Currently when showing the MPS in a period other than 'day', Odoo will do the sum of all forecast records for each period and base its calculation on the 1st day of the period. E.g. for the month of January, it will do the sum of all forecasts of that month then calculate lead times based on the 1st of January. > indirect_demand_qty > > Jan-25: 1000 > > Feb-25: 500 This causes issues with lead times when selecting bigger periods. This fix ensures that the forecasts are stored per date: > demand_qty_dict > > Jan-25 > > > 01-01-25: 200 > > > 01-07-25: 500 > > > 01-23-25: 300 > > Feb-25 > > > ... That way, when calculating lead times, it uses the real date for each forecast instead of the 1st day of the period shown. task 4172967 Forward-Port-Of: odoo/enterprise#72073
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
Original PR description
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
[REF] web_tour: remove MacroEngine class In this commit, we remove the MacroEngine class which duplicates the Macro class. Forward-Port-Of: odoo/enterprise#73792
Original PR description
[REF] web_tour: remove MacroEngine class In this commit, we remove the MacroEngine class which duplicates the Macro class. Forward-Port-Of: odoo/enterprise#73792