Saturday, February 10, 2024
32 changes · master
Enhancements to existing features
This update simplifies how Odoo prepares suggested recipients in chatter by handling the usual single-record case directly. It reduces unnecessary processing across several business apps while keeping the user-facing behavior the same.
Original PR description
*: crm, event, hr_recruitment, project, sale, survey, test_mail, website_event_exhibitor, website_event_track Before this PR: `_message_get_suggested_recipients` method returns suggested recipients for chatter as a dict of thread id (key) and list of recipients (value). In all use cases of this function (load chatter data), there's only one record so the return value is always a dict with length equal one. After this PR: `_message_get_suggested_recipients` method is changed to return a list of suggested recipients for one present thread. It makes the code simpler and avoid extra lines and operations to get the needed data. [Related Enterprise PR](https://github.com/odoo/enterprise/pull/56236)
The web module's expression editor tests were moved to a newer testing framework, improving maintainability and consistency for future development. This is an internal quality improvement with no direct change to day-to-day user workflows.
Original PR description
task-id: 3705027
The way Odoo prepares suggested recipients for chatter messages has been simplified for cases involving a single record. This reduces unnecessary processing and helps keep related Helpdesk and Studio features easier to maintain without changing the visible user experience.
Original PR description
*: helpdesk, web_studio Before this PR: `_message_get_suggested_recipients` method returns suggested recipients for chatter as a dict of thread id (key) and list of recipients (value). In all use cases of this function (load chatter data), there's only one record so the return value is always a dict with length equal one. After this PR: `_message_get_suggested_recipients` method is changed to return a list of suggested recipients for one present thread. It makes the code simpler and avoid extra lines and operations to get the needed data. [Related Odoo PR](https://github.com/odoo/odoo/pull/153402)
Resolved issues and error corrections
This update fixes and cleans up Odoo’s internal HOOT testing tools used by developers to validate web and messaging features. It improves test accuracy, reduces false failures, and makes future changes safer without directly changing end-user functionality.
Original PR description
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 This pull requests: - fixes linting errors in HOOT / HOOT-DOM - fixes issues with mock requests with simple string bodies - makes event helpers rely on mocked user agent or touch properties - properly handles the cleaning of registries after each test - moves test constants to a separate global file (instead of the session) - changes the default accessible URL in tests - exports missing HOOT-DOM helpers - fixes an issue with "multi" tests - changes the test/suite tags syntax from template tag to a named function --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
ba1a550 The above commit added some constraints on what can be used on the context of views. The key word 'force-email' is no longer relevant and will be removed from the context before reaching the next view/python code. This commit's purpose is to remove the force_email that were forgotten. In order to still open the simplified partner form view, the ref of the view is given in the context instead. While at it, we also fix the create option given on the partner_ids field that was inconsist
Original PR description
Subscription sales orders with recurring products are already meant to have a recurring plan, but this change adds an extra safeguard. It prevents invoicing from crashing if an order without a plan is encountered, improving reliability in edge cases.
Original PR description
We prevent creating subscription sale orders with recurring products and no recurring plans However it's better to be defensive to avoid crashes. This commit adds an additional condition before accessing order_id.plan_id Task: 3725476
ba1a550 The above commit added some constraints on what can be used on the context of views. The key word 'force-email' is no longer relevant and will be removed from the context before reaching the next view/python code. This commit's purpose is to remove the force_email that were forgotten. In order to still open the simplified partner form view, the ref of the view is given in the context instead. While at it, we also fix the create option given on the partner_ids field that was inconsistent. affected version 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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#149806
…fter refusal Before this commit, if a public holiday was created on dates overlapping an existing validated leave, the timesheet entries for the public holiday would not be created as they already existed for the leave. If the leave was then refused or cancelled, the timesheet records linked to it would be removed and the employee would have missing timesheet entries for the public holiday. This commit fixes this behavior by recreating the public holiday timesheet records for the affected
Original PR description
…fter refusal Before this commit, if a public holiday was created on dates overlapping an existing validated leave, the timesheet entries for the public holiday would not be created as they already existed for the leave. If the leave was then refused or cancelled, the timesheet records linked to it would be removed and the employee would have missing timesheet entries for the public holiday. This commit fixes this behavior by recreating the public holiday timesheet records for the affected employees when refusing their leave. opw-3550523 linked to com: https://github.com/odoo/odoo/pull/145522 Forward-Port-Of: odoo/odoo#153118 Forward-Port-Of: odoo/odoo#151522
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item that is marked dirty, because the ribbon doesn't have a savable parent. Solution ======== Flag the ribbon as dirty manually to trigger saving process Note ==== the reason why this is needed in 16.0 and not before is [1]. Before that we did not check for the presence of the dirty f
Original PR description
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item…
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item that is marked dirty, because the ribbon doesn't have a savable parent. Solution ======== Flag the ribbon as dirty manually to trigger saving process Note ==== the reason why this is needed in 16.0 and not before is [1]. Before that we did not check for the presence of the dirty flag (the "o_dirty" class) to determine if the page has to be saved. All of this has to be reviewed in the future, as explained by [2] and its following commits. Note that commits like [2] is probably the cause of ribbon not being savable anymore: parts of the DOM stopped being flagged with o_dirty by mistake... so the saving process was not triggered "by mistake" anymore. At the time of [1] for example: just clicking on a product image (to maybe then add a ribbon) was enough for it to be marked with the "o_dirty" class by mistake. This was probably solved later... creating the bug being solved here. [1]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70 [2]: https://github.com/odoo/odoo/commit/e8a86b860dcba5b7782fc26c4290eee48d9fcdee opw-3674520 Forward-Port-Of: odoo/odoo#153298 Forward-Port-Of: odoo/odoo#152694
Before this commit, an error was raised when attempting to print a receipt for a paid order in the restaurant module. opw-3735460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153406
Original PR description
Before this commit, an error was raised when attempting to print a receipt for a paid order in the restaurant module. opw-3735460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153406
Do not apply update method to avoid inadvertently overwrite on existing values. opw-3729318 Forward-Port-Of: odoo/odoo#153240
Original PR description
Do not apply update method to avoid inadvertently overwrite on existing values. opw-3729318 Forward-Port-Of: odoo/odoo#153240
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` w
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 -…
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Community part to allow the override for odoo/enterprise#55746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153145 Forward-Port-Of: odoo/odoo#152468
Steps: - Create an automation rule with a model X - Delete model X (need a way that keep the rule) Actual result: - Crash due to warning message Expected result: - Warning message is logged without issue opw-3722953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153078
Original PR description
Steps: - Create an automation rule with a model X - Delete model X (need a way that keep the rule) Actual result: - Crash due to warning message Expected result: - Warning message is logged without issue opw-3722953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153078
I. Commit [1] changed the code in toggleList such that variable block could not be a block. This commit updates the name of variable block to nodeToToggle. II. Previously, when changing the tag of a text node within a list, it transferred the list's attributes to the newly created tag. Ideally, this should only carry over the attributes of paragraph-related elements and not of lists. III. Make sure when changing style of a list item with class `nav-item` to normal wraps the text inside
Original PR description
I. Commit [1] changed the code in toggleList such that variable block could not be a block. This commit updates the name of variable block to nodeToToggle. II. Previously, when changing the tag of a text node within a list, it transferred the list's attributes to the newly created tag. Ideally, this should only carry over the attributes of paragraph-related elements and not of lists. III. Make sure when changing style of a list item with class `nav-item` to normal wraps the text inside of a `<p>` tag. [1]: https://github.com/odoo-dev/odoo/commit/d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9 task-3609500 Forward-Port-Of: odoo/odoo#153328 Forward-Port-Of: odoo/odoo#152871
Add some new members and update old ones with the due date. @Tecnativa Forward-Port-Of: odoo/odoo#152745
Original PR description
Add some new members and update old ones with the due date. @Tecnativa Forward-Port-Of: odoo/odoo#152745
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail when checking if the user can add a reaction to a message. There are two issues: - This step uses the `contains` helper and specify the live chat `ShadowRoot` as the target. However, the `contains` helper uses a mutation observer that observes the light DOM thus, changes in the shadow root are not correctly observed. - The target passed to the `contains` helper is the `ChatWindow` DOM element but this element can
Original PR description
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail when checking if the user can add a reaction to a message. There are two issues: - This step uses the `contains` helper and specify the live chat `ShadowRoot` as the target. However, the `contains` helper uses a mutation observer that observes the light DOM thus, changes in the shadow root are not correctly observed. - The target passed to the `contains` helper is the `ChatWindow` DOM element but this element can be unmounted in-between. This PR fixes this issue. Forward-Port-Of: odoo/odoo#153382
This commit addresses an issue where, upon application to an invoice, the Receivables, while accurate in terms of Amounts and Due Dates, have incorrect labels. The root cause of this problem was identified in the compute_name method of the account.move.line model. The modifications in this commit rectify the compute_name method to ensure that payment terms labels are computed correctly. task-3636484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su
Original PR description
This commit addresses an issue where, upon application to an invoice, the Receivables, while accurate in terms of Amounts and Due Dates, have incorrect labels. The root cause of this problem was identified in the compute_name method of the account.move.line model. The modifications in this commit rectify the compute_name method to ensure that payment terms labels are computed correctly. task-3636484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153364 Forward-Port-Of: odoo/odoo#147670
It is possible to have context keys being leaked from outside the context manager in the following case: * a new transaction starts with a new environment * the code calls `_disable_recursion` * all the existing environment are modified with the context key * inside of the context manager, a new environment is created without specifying a full context: we keep the previous one, which contains the context key * the code exits the context manager and cleans all the environment it was aware of
Original PR description
It is possible to have context keys being leaked from outside the context manager in the following case: * a new transaction starts with a new environment * the code calls `_disable_recursion` * all the existing environment are modified with the context key * inside of the context manager, a new environment is created without specifying a full context: we keep the previous one, which contains the context key * the code exits the context manager and cleans all the environment it was aware of <-- this is the issue * the environment that was created inside the context manager still contains the context key, if it is used and is never cleaned. Now, we also remove the context key of all the environments created inside the context manager. It is better to risk having some recursion (probably leading to operations being done multiple times) than doing nothing at all because the context disables some features. Forward-Port-Of: odoo/odoo#146336
Current behavior before PR: If base.partner_root email is modified before installing mail, mail will overwite it (since it is at install and not on update) Desired behavior after PR is merged: Set it up once: on database creating then let the user modify it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152665
Original PR description
Current behavior before PR: If base.partner_root email is modified before installing mail, mail will overwite it (since it is at install and not on update) Desired behavior after PR is merged: Set it up once: on database creating then let the user modify it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152665
To reproduce: - Put your fiscal year to the 30th of December (yes it's unlikely) - Create an asset - Compute depreciations => they are created for the 31th of December It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February opw-3704466 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
Original PR description
To reproduce: - Put your fiscal year to the 30th of December (yes it's unlikely) - Create an asset - Compute depreciations => they are created for the 31th of December It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February opw-3704466 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#152710
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of reconciliation batches 5. Precompute fields on partials 1: Handle the inverse fields of `account.full.reconcile` manually ----------------------------------------------------------------- In order to update the inverse fields of `reconciled_line_ids` and `partial_reconcile_ids`, the ORM is tr
Original PR description
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of…
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of reconciliation batches 5. Precompute fields on partials 1: Handle the inverse fields of `account.full.reconcile` manually ----------------------------------------------------------------- In order to update the inverse fields of `reconciled_line_ids` and `partial_reconcile_ids`, the ORM is triggering one query per full reconcile record. In the case of a big batch payment, that is a lot of round trips. This also bypasses the computation for possible tracking, which is expensive to do for 2 records at a time. That field is not tracked anyway. 2: Batch the update of matching numbers --------------------------------------- Basically the same as 1. without the tracking. 3: Batch the balance consistency test ------------------------------------- Use the various context managers around `__reconcile_plan` to check for the balance consistency only at the end in one single query. This avoids checking it at every single intermediate write done on the lines. Also doing it for the sync of dynamic lines. It should be useless but it doesn't cost anything, and allows to remove the context keys in enterprise without a cost. (they shouldn't be used explicitly, the context managers should always be used instead) Using these context managers also allows to remove all the `skip_` context keys, which should not be used: using them will mean that as soon as the journal entry is modified for any reason, some business fields will change because of the synchronisation since the context won't be the same anymore. This commit therefore also makes `_sync_dynamic_line` more resilient and avoids even more useless syncs. 4: Batch the construction of reconciliation batches --------------------------------------------------- Introduce `_reconciled_by_number`, which is basically a `_read_group`. In conjuction with `_filter_reconciled_by_number`, we can find all the reconciled lines in one single query, for as many batches as needed; as opposed to one query per batch before. 5: Precompute fields on partials -------------------------------- Simply avoid doing one batched `INSERT INTO` followed by one `UPDATE` for each record. Benchmark: ========== We are testing 2 use cases: * a lot of small matchings that are producing a full 2 by 2 * one big matching (also producing a full) To reconcile a batch payment of 500 (identical) lines in the bank reco: | | Queries | SQL | Other | |--------|---------|-------|--------| | Before | 4191 | 4.649 | 16.253 | | After | 226 | 0.989 | 3.581 | To reconcile one big batch of 1000 lines with the generic reco widget (spaghetti): | | Queries | SQL | Other | |--------|---------|-------|--------| | Before | 82 | 0.478 | 1.131 | | After | 66 | 0.634 | 0.974 | All the times are in seconds. We can see the the use case of the batch payment is improved a lot (the time is expected to be linear with regards to the number of payments), while the time for big batches is not impacted. Forward-Port-Of: odoo/odoo#152284
This patch is an improvement and simplification over the fix done in 5a64974501b5be231e2eed941f42ae6dfe110f18 When generating the company search query we should skip unloaded modules to avoid a `KeyError`. This issue became more visible now that the check in `ir.rule` is done for each domain. Refer to the above commit for steps on how to reproduce the issue. This issue has a high impact in upgrades since it potentially blocks all upgrades for which a `data_merge.record` entry exists for a
Original PR description
This patch is an improvement and simplification over the fix done in 5a64974501b5be231e2eed941f42ae6dfe110f18 When generating the company search query we should skip unloaded modules to avoid a `KeyError`. This issue became more visible now that the check in `ir.rule` is done for each domain. Refer to the above commit for steps on how to reproduce the issue. This issue has a high impact in upgrades since it potentially blocks all upgrades for which a `data_merge.record` entry exists for a custom model. Forward-Port-Of: odoo/enterprise#56228
Currently if you do not have any payroll rights and you are your own attendance manager, you will not be able to create or write attendances since those affect hr.work.entries that you do not have any rights on, this issue is fixed by using sudo in the work entry creation and modification task-3734639 Forward-Port-Of: odoo/enterprise#56176
Original PR description
Currently if you do not have any payroll rights and you are your own attendance manager, you will not be able to create or write attendances since those affect hr.work.entries that you do not have any rights on, this issue is fixed by using sudo in the work entry creation and modification task-3734639 Forward-Port-Of: odoo/enterprise#56176
Simply prefetch all the values because we are analyzing a list of recordsets without any prefetch ids. Forward-Port-Of: odoo/enterprise#55633
Original PR description
Simply prefetch all the values because we are analyzing a list of recordsets without any prefetch ids. Forward-Port-Of: odoo/enterprise#55633
Forward-Port-Of: odoo/enterprise#56255
Original PR description
Forward-Port-Of: odoo/enterprise#56255
We used to skip the SvcLvl node on generic ISO20022 payments. This caused some banks to reject the XML file generated for them (though this node is not supposed to be mandatory). We now always set in on them, with the default NURG code, indicating that the payment is non-urgent. OPW 3679650 Forward-Port-Of: odoo/enterprise#55451 Forward-Port-Of: odoo/enterprise#55038
Original PR description
We used to skip the SvcLvl node on generic ISO20022 payments. This caused some banks to reject the XML file generated for them (though this node is not supposed to be mandatory). We now always set in on them, with the default NURG code, indicating that the payment is non-urgent. OPW 3679650 Forward-Port-Of: odoo/enterprise#55451 Forward-Port-Of: odoo/enterprise#55038
Before this commit, when the user disables a feature in helpdesk in all helpdesk teams (by using the pager to switch helpdesk teams) the window is not reloaded when it should be expected (when the SLA feature is disabled in all helpdesk team). The reason is because the `fieldsToCheck` is not reset when the record changed and so the variable keeps the value of the previous record. This commit fixes the issue by adding a `onPatched` hook inside the custom form controller to reset `fieldsTo
Original PR description
Before this commit, when the user disables a feature in helpdesk in all helpdesk teams (by using the pager to switch helpdesk teams) the window is not reloaded when it should be expected (when the…
Before this commit, when the user disables a feature in helpdesk in all helpdesk teams (by using the pager to switch helpdesk teams) the window is not reloaded when it should be expected (when the SLA feature is disabled in all helpdesk team). The reason is because the `fieldsToCheck` is not reset when the record changed and so the variable keeps the value of the previous record. This commit fixes the issue by adding a `onPatched` hook inside the custom form controller to reset `fieldsToCheck`. This commit also improves a bit the performance by only checking the changes made by the user instead of checking the whole data of the record in the form view to know if the view has to be reloaded or not. Finally, it also calls the parent methods (`onWillRecordSaved` and `onRecordSaved`) since those methods defined in `HelpdeskTeamFormController` are methods overriden and not new methods in that class. Issue found during the testing of task-3549328 Forward-Port-Of: odoo/enterprise#55944
### Steps to reproduce - Install **sale_purchase_inter_company_rules** module - Go to **Settings** and activate I**nter-Company Transactions** option - Save then Go to **Settings** > **Inter-Company Transactions** and select **Synchronize Sales and Purchase Order** - Notice how **Copy Lots on Delivery Validation** is selected - Save - Now _Unselect_ the **Copy Lots on Delivery Validation**, Then Save - Go back to the Settings, **Copy Lots on Delivery Validation** is **_selected_** althoug
Original PR description
### Steps to reproduce - Install **sale_purchase_inter_company_rules** module - Go to **Settings** and activate I**nter-Company Transactions** option - Save then Go to **Settings** > **Inter-Company Transactions** and select **Synchronize Sales and Purchase Order** - Notice how **Copy Lots on Delivery Validation** is selected - Save - Now _Unselect_ the **Copy Lots on Delivery Validation**, Then Save - Go back to the Settings, **Copy Lots on Delivery Validation** is **_selected_** although it shouldn't ### Investigation - The following line https://github.com/odoo/enterprise/blob/40060d1a78c07aa9420fdc2963f96209e1b3f9d5/sale_purchase_inter_company_rules/models/res_config_settings.py#L26 at the `onchange_rule_type` sets the `copy_lots_delivery` when the settings are loaded back no matter what the value the client had set opw-3702544 Forward-Port-Of: odoo/enterprise#56002
The new design introduced in odoo/enterprise#41534 moved the details inside a column used in the several templates of the appointment flow, updating at each step. However, it is not shown for anytime and custom appointments. In order to avoid a large blank space on the right of the screen and a strange design effect, as well as to give the attendee the available details as soon as they are available, always display the details column. However, as the duration may vary in the custom categor
Original PR description
The new design introduced in odoo/enterprise#41534 moved the details inside a column used in the several templates of the appointment flow, updating at each step. However, it is not shown for anytime and custom appointments. In order to avoid a large blank space on the right of the screen and a strange design effect, as well as to give the attendee the available details as soon as they are available, always display the details column. However, as the duration may vary in the custom category, do not show duration field at time selection for those appointments. Show duration of selected slot on detail screen. Task-3701087 Forward-Port-Of: odoo/enterprise#55138
…s template Have a form view, with a subview form. That subview has a button_box. Before this commit, the button box was compiled in the context of the main view, eventually leading to crashes. After this commit, it is compiled only when navigation to that subview for edition. This issue and the fix are similar to odoo/odoo#149896 opw-3681966 Forward-Port-Of: odoo/enterprise#56191 Forward-Port-Of: odoo/enterprise#56130
Original PR description
…s template Have a form view, with a subview form. That subview has a button_box. Before this commit, the button box was compiled in the context of the main view, eventually leading to crashes. After this commit, it is compiled only when navigation to that subview for edition. This issue and the fix are similar to odoo/odoo#149896 opw-3681966 Forward-Port-Of: odoo/enterprise#56191 Forward-Port-Of: odoo/enterprise#56130
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` w
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Forward-Port-Of: odoo/enterprise#56109 Forward-Port-Of: odoo/enterprise#55746
This commit is a follow up of its community part. see : https://github.com/odoo/odoo/pull/149806 affected version: 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#54549
Original PR description
This commit is a follow up of its community part. see : https://github.com/odoo/odoo/pull/149806 affected version: 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#54549
To reproduce: 1. Install and configure the VoIP module in prod mode 2. Place a call to anyone 3. Block the browser from accessing the microphone Error: Invalid state transition from Terminated to Terminated Fixed in https://github.com/onsip/SIP.js/commit/f06939c119149a3e00ad8acf69f37360d3331a62 Adapt it in old version. Task-2810572 Forward-Port-Of: odoo/enterprise#54467 Forward-Port-Of: odoo/enterprise#53581
Original PR description
To reproduce: 1. Install and configure the VoIP module in prod mode 2. Place a call to anyone 3. Block the browser from accessing the microphone Error: Invalid state transition from Terminated to Terminated Fixed in https://github.com/onsip/SIP.js/commit/f06939c119149a3e00ad8acf69f37360d3331a62 Adapt it in old version. Task-2810572 Forward-Port-Of: odoo/enterprise#54467 Forward-Port-Of: odoo/enterprise#53581