Saturday, February 10, 2024
37 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)
Recruiters can now choose an email template, include attachments, and save template changes when emailing multiple applicants at once. This makes bulk applicant communication faster, more consistent, and easier to reuse across hiring workflows.
Original PR description
Enhanced the functionality to allow users to pick an email template, add attachments, and save the template when sending emails to multiple applicants. Task-3501161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 spreadsheet engine has been updated to a newer version with performance improvements for formula processing and cell handling. It also fixes issues with editing, filters, exports, formatting, and chart panel behavior, making spreadsheets faster and more reliable for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1b33cf4ed [REL] 17.2.0-alpha.4 https://github.com/odoo/o-spreadsheet/commit/b3b63611c [PERF] tokenizer: faster…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1b33cf4ed [REL] 17.2.0-alpha.4 https://github.com/odoo/o-spreadsheet/commit/b3b63611c [PERF] tokenizer: faster tokenize Task: 3735948 https://github.com/odoo/o-spreadsheet/commit/3e32adaec [PERF] tokenizer: faster parenthesis tokenize Task: 3735948 https://github.com/odoo/o-spreadsheet/commit/9dd9e5afa [PERF] tokenizer: faster number tokenize Task: 3735948 https://github.com/odoo/o-spreadsheet/commit/04ec9957f [PERF] tokenizer: faster symbol tokenize Task: 3735948 https://github.com/odoo/o-spreadsheet/commit/de91d9a75 [FIX] Composer: Persistent composition when starting the edition Task: 3685891 https://github.com/odoo/o-spreadsheet/commit/855f32673 [IMP] stores: export stores for external use https://github.com/odoo/o-spreadsheet/commit/ca4087464 [FIX] DataFilter: Fix overlapping filters Task: 3728009 https://github.com/odoo/o-spreadsheet/commit/8b0d0794d [FIX] export: unbound formula stays unbound in snapshots https://github.com/odoo/o-spreadsheet/commit/c22e2e2e2 [PERF] cell: remove useless binded function Task: 3721226 https://github.com/odoo/o-spreadsheet/commit/ce91f2a19 [PERF] cell: remove range string closure Task: 3721226 https://github.com/odoo/o-spreadsheet/commit/989c3113c [PERF] cells: transform dependencies without closure Task: 3721226 https://github.com/odoo/o-spreadsheet/commit/3cbb2c5f0 [PERF] functions: lookup function return error https://github.com/odoo/o-spreadsheet/commit/c572f0739 [REF] Renderer: use layer name for rendering Task: 3719197 https://github.com/odoo/o-spreadsheet/commit/79c6fdab3 [REF] Renderer: convert `RendererPlugin` to store Task: 3719197 https://github.com/odoo/o-spreadsheet/commit/e8f8fa321 [REF] evaluation: unify the formula payload with the evaluated cell type Task: 3685074 https://github.com/odoo/o-spreadsheet/commit/be2e676b5 [IMP] data: remove key `entities` in exported data https://github.com/odoo/o-spreadsheet/commit/bf7166e1a [FIX] formatting: do not show escape character Task: 3698283 https://github.com/odoo/o-spreadsheet/commit/5f29fcb69 [REM] composer: remove CTRL+Space shortcut Task: 3504025 https://github.com/odoo/o-spreadsheet/commit/3253c5953 [FIX] chart: fix incoherent side_pannel state Task: 3380568
The spreadsheet engine used in Odoo has been updated to a newer alpha version. This should improve spreadsheet-related behavior and reliability across document spreadsheets, lists, and pivot views, while supporting ongoing product improvements.
Original PR description
…-alpha.4
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)
Canceled sales orders will no longer leave unplanned service shifts that keep getting scheduled automatically. This avoids unnecessary resource planning for work that is no longer needed, while still creating new shifts if the order is later re-confirmed.
Original PR description
…ed SOs Before this commit, planning will auto-plan shifts linked to canceled SOs. This doesn't make sense as the service no longer needs to be provided. In addition, the user cannot easily delete the related unplanned shift so it will keep getting scheduled automatically every time the feature is used. In this commit, when an SO is canceled, the related unplanned shift will be automatically deleted (excluding shifts that are already scheduled). If the SO is reset to quotation and confirmed again, a new shift will be generated to plan for the remaining hours. task-3603886
Resolved issues and error corrections
Odoo now handles errors while opening views in a consistent way, such as returning users to a list or previous screen instead of showing an empty page or behaving differently depending on how they navigated. This makes the web interface more reliable and less confusing when records are missing or cannot be loaded.
Original PR description
Before this commit, there are multiples different behaviours, handled by different parts of the code, when an error occurs when loading a view : - If we loaded a faulty form view (wrong id) from the…
Before this commit, there are multiples different behaviours, handled by different parts of the code, when an error occurs when loading a view : - If we loaded a faulty form view (wrong id) from the url, the page is reloaded on the multi-record view of the same action. - If we loaded a faulty form view (error in loading) from the url, an empty page is shown. - If we clicked on a deleted record (form view) on the breadcrumb, we stay on the current view. - If we clicked on the back button of the browser, that it lead us to a deleted record (form view), the page is reloaded on the multi-record view of the same action. - If we clicked on a previously deleted record in a multi-record view, we stay on the multi-record view. These multiple behaviours for handling errors when loading a view is confusing and error-prone. Now, the action service will handle all the behaviour when an error occurs when loading a view consistently : - If an error occurs when clicking on the breadcrumb, the previous view of the faulty one is loaded. - If an error occurs when loading a new view, from an url or from the back button, a multi-record view will be loaded. - If an error occurs when loading a new view, from another view, we stay on that view. Note that, this commit also fixes an issue in fetchRecordErrorHandler. Since [1], the handler was not working properly, it was raising another error because of a typographical error. This commit also fix the tests that weren't failing because they were doing a doAction and not a loadState. [1] : 016a72bae9c3194459b1f25d9ae5678ce50aead7
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
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
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