Monday, April 25, 2022
36 changes · master
Enhancements to existing features
Odoo now handles missing default values more efficiently when many records are created at once. This prevents duplicate sequence numbers in batch-created records and reduces repeated database lookups, especially for product and partner-related workflows.
Original PR description
`_add_missing_default_values` is made to work in batch. Models with a sequence can take advantage of that to increase the sequence for each new record in the batch. Before this commit, all records…
`_add_missing_default_values` is made to work in batch. Models with a sequence can take advantage of that to increase the sequence for each new record in the batch. Before this commit, all records created in a batch would have the same sequence if no sequence was provided to `create`. The new sequence is computed after the parent `_add_missing_default_values` instead of before (or instead of in `create`) to keep the possibility to have the default value coming from other means, as computed in `default_get`. The opportunity is also taken to change the definition of some defaults methods that would lead to the execution of queries, because those queries would be done for each record in the batch. This is typically the case for defaults that use `ref` which does an `exists` (as opposed to `xmlid_to_res_model_res_id`) or it is obviously also the case for the defaults doing a `search` directly. Indeed the result of these queries would then either be read or be added as a many2one, both of which will already check the existence of the resource. The focus of this commit was on products and partners, but the same logic can be applied to other models if they have such defaults and the performance of their batch create is important.
Product variant records will now prevent missing combination information, reducing the chance of duplicate or inconsistent variants after migrations or external database updates. This helps keep product catalogs more reliable without changing day-to-day workflows.
Original PR description
On [1] it was wrongly assumed that `required` was unnecessary because the field is computed and the compute method never set NULL. However [2] highlighted cases where the field was NULL in database. This can especially happen after a migration, or more generally for any database change made outside the ORM. To avoid issues, we need to ensure the same product.template does not have two variants one with empty string and one with NULL, thus making the field required to prevent NULL values. [1] 22a11a6f4d0b08a56712fafd0f87a2e7bb5b00ec [2] 03e7efc3b4592c5f063c665130011a91fcc4d683
The chatter area now makes the attachment action easier to recognize and use. This helps users find and manage document attachments more confidently during everyday communication workflows.
Original PR description
task-2413814
This update adds test coverage to help ensure timesheet reminders, attendance reporting, multi-company timesheets, and time off-related timesheet entries behave correctly. It reduces the risk of payroll, approval, and absence-tracking issues by validating important business scenarios such as holidays overlapping with approved time off.
Original PR description
Reminders- - employee reminder: an email should be sent when the employee has timesheet less hours than he should have - manager reminder: an email should be sent when the manager has not validated timesheets within the corresponding timeframe. Timesheet / attendance report Time off - public holidays should not generate an entry if the employee is already on time off - the project and task set on the time off type should be set on the generated timesheets task-2727561
This update aligns the activity component with Odoo interface guidelines in Mail and eLearning slides. Users get a more consistent experience when viewing and managing activities across these areas.
Original PR description
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
Project task starring is now presented as priority, making the purpose clearer for users. Task assignment dates are cleaned up when assignees are removed, collaborators gain a helpful action shortcut, and task calendars can now be viewed by year for broader planning.
Original PR description
- The starred field was renamed as priority. - The assigned date is now set back to False when the user is unassigned from the task - An action helper was added to the collaborators view - The year mode was added to the calendar view of tasks task-2802506 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds checks to ensure timesheet reminder emails are sent when employees are short on hours and when managers have pending validations. It also improves testing around resetting validated timesheets back to draft, helping protect key timesheet approval workflows from regressions.
Original PR description
Reminders- - employee reminder: an email should be sent when the employee has timesheet less hours than he should have - manager reminder: an email should be sent when the manager has not validated timesheets within the corresponding timeframe. Timesheets validation - reset a timesheet to draft task-2727561
New PLM engineering change records created together now receive separate sequence numbers instead of sharing the same order. This improves list ordering and helps teams distinguish and manage newly created records more reliably.
Original PR description
`_add_missing_default_values` was made to work in batch, and this commit takes advantage of that to increase the sequence for each new record in the batch. Before this commit, all records created in a batch would have the same sequence. Enterprise counterpart of odoo/odoo#36704
Activity cards have been updated to follow the latest interface guidelines in Approvals, Documents, Sign, and VoIP. This creates a more consistent experience for users when reviewing and acting on activities across these apps.
Original PR description
* = approvals, documents, sign, voip
Code cleanup and technical improvements
This update reorganizes how HR, Time Off, and Live Chat messaging components are registered behind the scenes. It should make these areas easier to maintain and less prone to configuration inconsistencies, with limited direct impact on day-to-day users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue/feature this PR addresses: [Task-2809043](https://www.odoo.com/web#id=2809043&model=project.task) Current behavior before PR: SII's menu is not the best Desired behavior after PR is merged: SII's menu is clearer and more readable Forward-Port-Of: odoo/odoo#87101
Original PR description
Description of the issue/feature this PR addresses: [Task-2809043](https://www.odoo.com/web#id=2809043&model=project.task) Current behavior before PR: SII's menu is not the best Desired behavior after PR is merged: SII's menu is clearer and more readable Forward-Port-Of: odoo/odoo#87101
When using a template with inline placeholders in the body, the Test button will replace the placeholders, but they will remain in the final body when the mass mailing is sent for real. This commit fixes this issue by using the correct rendering engine for the Test button too. [OPW-2819032](https://www.odoo.com/web#model=project.task&id=2819032) [OPW-2828461](https://www.odoo.com/web#model=project.task&id=2828461) Forward-Port-Of: odoo/odoo#89031
Original PR description
When using a template with inline placeholders in the body, the Test button will replace the placeholders, but they will remain in the final body when the mass mailing is sent for real. This commit fixes this issue by using the correct rendering engine for the Test button too. [OPW-2819032](https://www.odoo.com/web#model=project.task&id=2819032) [OPW-2828461](https://www.odoo.com/web#model=project.task&id=2828461) Forward-Port-Of: odoo/odoo#89031
The autoplay option for youtube videos in a `.media_iframe_video` snippet does not currently work on mobile devices. This happens because the autoplay param in the url is only taken into account for desktop devices. Mobile autoplay can be forced by using the youtube js api, in the same way as is already the case for background videos. Therefore, the common code is extracted into a mixin, extended by both widgets. opw-2607308 Forward-Port-Of: odoo/odoo#89364 Forward-Port-Of: odoo/odoo#8791
Original PR description
The autoplay option for youtube videos in a `.media_iframe_video` snippet does not currently work on mobile devices. This happens because the autoplay param in the url is only taken into account for desktop devices. Mobile autoplay can be forced by using the youtube js api, in the same way as is already the case for background videos. Therefore, the common code is extracted into a mixin, extended by both widgets. opw-2607308 Forward-Port-Of: odoo/odoo#89364 Forward-Port-Of: odoo/odoo#87912
Impacted versions: - 15.0 Steps to reproduce (starting from ENTERPRISE 15.2): - enable Work Orders - create new BoM for a new product - add 1 operation w/ 1 step (e.g. Instructions) - add 1 component to BoM with operation_id (Consumed in Operation) = the operation - Create and confirm a MO with new BoM + 2 Quantity to Produce - Produce 1 product via the tablet view flow (i.e. complete instruction step + Validate 1 component in "Register Consumed Materials" step + Mark As Done) Curr
Original PR description
Impacted versions: - 15.0 Steps to reproduce (starting from ENTERPRISE 15.2): - enable Work Orders - create new BoM for a new product - add 1 operation w/ 1 step (e.g. Instructions) - add 1 component…
Impacted versions: - 15.0 Steps to reproduce (starting from ENTERPRISE 15.2): - enable Work Orders - create new BoM for a new product - add 1 operation w/ 1 step (e.g. Instructions) - add 1 component to BoM with operation_id (Consumed in Operation) = the operation - Create and confirm a MO with new BoM + 2 Quantity to Produce - Produce 1 product via the tablet view flow (i.e. complete instruction step + Validate 1 component in "Register Consumed Materials" step + Mark As Done) Current behaviour: Backorder is correctly created, but its workorder is missing the "Register Consumed Materials" step Expected behaviour: Step is correctly created Note: same issue occurs with Byproducts having a operation_id (i.e. "Produced in Operation") Issue is due to when `_split_productions()` first creates the backorders, they are created without `move_raw_ids` and `move_finished_ids` (see: `_get_backorder_mo_vals()`). When the backorders are created, they auto-create and auto-confirm their workorders. Since a quality point (e.g. operation step) exists for the workorder, the initial `_action_confirm` will `_create_checks()` for the quality point, but the "Register Consumed Materials" steps are created by the `operation_id` values in the `move_raw_ids` and `move_finished_ids` which haven't been set yet. This makes it so when the second `_action_confirm()` is called on the workorders (i.e. after their moves have been set) at the end of `_split_productions()`, the `_create_checks()` will be skipped because it assumes all the quality points have been created since one already exists. Task: 2800975 Enterprise PR: https://github.com/odoo/enterprise/pull/26437 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87681
Current behavior: When using 2 steps delivery and selling a kit product, not all moves had bom_line_id set. So if you go in the transfers you couldn't always see the "Kit" column in the operations. Steps to reproduce: - Activate 2 steps delivery - Create a Kit with 2 products - Create a quotation with kit and confirm it - Go in the delivery - In WH/Pick you can't see Kit column - In WH/Out you can see the Kit column opw-2796974 -- I confirm I have signed the CLA and read the PR
Original PR description
Current behavior: When using 2 steps delivery and selling a kit product, not all moves had bom_line_id set. So if you go in the transfers you couldn't always see the "Kit" column in the operations. Steps to reproduce: - Activate 2 steps delivery - Create a Kit with 2 products - Create a quotation with kit and confirm it - Go in the delivery - In WH/Pick you can't see Kit column - In WH/Out you can see the Kit column opw-2796974 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88587
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#89482 Forward-Port-Of: odoo/odoo#89391
Original PR description
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#89482 Forward-Port-Of: odoo/odoo#89391
In the "then" of readUngroupedList, list may have changed. This fix may work as long as readUngroupedList is guaranteed to return the right datapoint list. 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#88240
Original PR description
In the "then" of readUngroupedList, list may have changed. This fix may work as long as readUngroupedList is guaranteed to return the right datapoint list. 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#88240
Steps to reproduce: - install apps sale_timesheet,stock_account, delivery - Select any two storable product that has invoicing policy set on 'Delivery' - Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0 - Add shipping Issue: - The Invoice Status has changed to 'To Invoice' Solution: Add en extra filter to consider only lines that have not been invoiced. opw-2750861 Forward-Port-Of: odoo/odoo#89341 Forward-Port-
Original PR description
Steps to reproduce: - install apps sale_timesheet,stock_account, delivery - Select any two storable product that has invoicing policy set on 'Delivery' - Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0 - Add shipping Issue: - The Invoice Status has changed to 'To Invoice' Solution: Add en extra filter to consider only lines that have not been invoiced. opw-2750861 Forward-Port-Of: odoo/odoo#89341 Forward-Port-Of: odoo/odoo#88403
Current behavior: In PoS when you access payment screen with product tracked by SN and if some of the SN are not set you have no warning. Steps to reproduce: - Create product tracked by SN - Sell it in a PoS - Don't set the SN - Click on payment button - No warning is displayed Solution: Add a warning popup to inform the user that he is going to make a payment with missing SN opw-2818511 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Current behavior: In PoS when you access payment screen with product tracked by SN and if some of the SN are not set you have no warning. Steps to reproduce: - Create product tracked by SN - Sell it in a PoS - Don't set the SN - Click on payment button - No warning is displayed Solution: Add a warning popup to inform the user that he is going to make a payment with missing SN opw-2818511 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89411 Forward-Port-Of: odoo/odoo#88629
Forward-port of PR odoo/odoo#86643. Add a unittest for multi_step route on Ship Later warehouse to ensure that the fix https://github.com/odoo/odoo/commit/5959d77f3448eb4cafabeb744a94b21471353e02 is not unintentionally reverted. #### speed As for the v14 PR the speed depends on a number of things. First in a customer DB with no products tracked, realtime inventory valuation and no Bills of materials. Speedup when closing different sessions: - 149 orders, 346 lines, 288 products:
Original PR description
Forward-port of PR odoo/odoo#86643. Add a unittest for multi_step route on Ship Later warehouse to ensure that the fix https://github.com/odoo/odoo/commit/5959d77f3448eb4cafabeb744a94b21471353e02 is…
Forward-port of PR odoo/odoo#86643. Add a unittest for multi_step route on Ship Later warehouse to ensure that the fix https://github.com/odoo/odoo/commit/5959d77f3448eb4cafabeb744a94b21471353e02 is not unintentionally reverted. #### speed As for the v14 PR the speed depends on a number of things. First in a customer DB with no products tracked, realtime inventory valuation and no Bills of materials. Speedup when closing different sessions: - 149 orders, 346 lines, 288 products: 410s -> 380s - 381 orders, 1048 lines, 687 products: 766s -> 301s - 572 orders, 1395 lines, 830 products: 536s -> 367s Then, in a testing database with no products tracked, no anglo-saxon accounting, real-time inventory valuation, phantom boms for each product with 5-30 components: - 70 orders, 350 lines, 350 products: 32 min -> 13 min. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88972 Forward-Port-Of: odoo/odoo#87908
Steps : Install project and activate Timesheets. Go to a task and add a timesheet with 30', then click elsewhere. Issue : The hours spent adapts, rounding to integer. Cause : The digits are not specified. Fix : Specify them. opw-2822018 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
Original PR description
Steps : Install project and activate Timesheets. Go to a task and add a timesheet with 30', then click elsewhere. Issue : The hours spent adapts, rounding to integer. Cause : The digits are not specified. Fix : Specify them. opw-2822018 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#89561
…ount When showing the discount the to the public, the down payment and gift card products were taken into account in the discount computation shown in the receipt. This also fix a mistake made in fc546e0481ae0159e67791240833bc1e38a4440f where it was implemented in the wrong place and returning a wrong value in a reduce callback. related pr: https://github.com/odoo/odoo/pull/89028 Forward-Port-Of: odoo/odoo#89469 Forward-Port-Of: odoo/odoo#89325
Original PR description
…ount When showing the discount the to the public, the down payment and gift card products were taken into account in the discount computation shown in the receipt. This also fix a mistake made in fc546e0481ae0159e67791240833bc1e38a4440f where it was implemented in the wrong place and returning a wrong value in a reduce callback. related pr: https://github.com/odoo/odoo/pull/89028 Forward-Port-Of: odoo/odoo#89469 Forward-Port-Of: odoo/odoo#89325
Currently, the timezone offset is taken from the date with reverse timezone offset applied. So if there is a change of timezone offset between the wrong date and the local date, we apply the wrong timezone. Example: - be in "Australia/Sydney" timezone - select date in datetime field 2021-04-03 16:12:34 (at UTC+11) - save => time becomes 17:12:34 - change time to 17:12:35 and save => time becomes 18:12:35 - change time to 18:12:36 and save => time becomes 19:12:36 - ... - this issue is happeni
Original PR description
Currently, the timezone offset is taken from the date with reverse timezone offset applied. So if there is a change of timezone offset between the wrong date and the local date, we apply the wrong timezone. Example: - be in "Australia/Sydney" timezone - select date in datetime field 2021-04-03 16:12:34 (at UTC+11) - save => time becomes 17:12:34 - change time to 17:12:35 and save => time becomes 18:12:35 - change time to 18:12:36 and save => time becomes 19:12:36 - ... - this issue is happening until 01:59:59 of the following day Fix: When we are selecting "2021-04-03 16:01:23" we will get the timezone offset from the date "Sun Apr 04 2021 02:01:23 GMT+1000" (at UTC+10) but the DST change was at "2021-04-04 03:00:00 (UTC+11)" with time becoming "2021-04-04 02:00:00 (UTC+10)". With this changeset, we are getting the timezone from the local time, not from local time with reverse timezone offset applied. opw-2735369 Forward-Port-Of: odoo/odoo#88112
A change introduced in https://github.com/odoo/odoo/pull/84644 removed the 'token' variable from a call to the `portal.message_thread` template, which created a bug where a portal user trying to submit a comment to a task would encounter an "Access Denied" error. This PR reverts that change. Task-2832688 Forward-Port-Of: odoo/odoo#89629
Original PR description
A change introduced in https://github.com/odoo/odoo/pull/84644 removed the 'token' variable from a call to the `portal.message_thread` template, which created a bug where a portal user trying to submit a comment to a task would encounter an "Access Denied" error. This PR reverts that change. Task-2832688 Forward-Port-Of: odoo/odoo#89629
Setup at least 2 bank accounts [ACC1] and [ACC2] Setup a Journal [BNK1] with [ACC1] Setup a second journal [BNK2] with [ACC2] Create an Internal Transfer from [BNK1] to [BNK2] Save and confirm partner_bank_id will be choosen from the Journal, for inbound payment, ([ACC1]) or it from one of the company bank accounts in outbound payment, so either [ACC1] or [ACC2] This is wrong as [ACC2] should be used because defined on [BNK2] opw-2794081 Description of the issue/feature this PR a
Original PR description
Setup at least 2 bank accounts [ACC1] and [ACC2] Setup a Journal [BNK1] with [ACC1] Setup a second journal [BNK2] with [ACC2] Create an Internal Transfer from [BNK1] to [BNK2] Save and confirm partner_bank_id will be choosen from the Journal, for inbound payment, ([ACC1]) or it from one of the company bank accounts in outbound payment, so either [ACC1] or [ACC2] This is wrong as [ACC2] should be used because defined on [BNK2] opw-2794081 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#86846
If applied, this commit will fix the following bug by allowing prepayment accounts to be selected on deferred expense models as mentioned in the docs: https://www.odoo.com/documentation/15.0/applications/finance/accounting/payables/supplier_bills/deferred_expenses.html Steps to reproduce: 1- install accounting 2- Configuration > Deferred Expense Models 3- Click create and try to set deferred expense account 4- only accounts of type "Current Assets" are available Bug: the dom
Original PR description
If applied, this commit will fix the following bug by allowing prepayment accounts to be selected on deferred expense models as mentioned in the docs: https://www.odoo.com/documentation/15.0/applications/finance/accounting/payables/supplier_bills/deferred_expenses.html Steps to reproduce: 1- install accounting 2- Configuration > Deferred Expense Models 3- Click create and try to set deferred expense account 4- only accounts of type "Current Assets" are available Bug: the domain doesn't contain prepayment Fix: add prepayment account type to search domain OPW-2827435 Forward-Port-Of: odoo/enterprise#26564
TaskID: 2806432 Forward-Port-Of: odoo/enterprise#25698
Original PR description
TaskID: 2806432 Forward-Port-Of: odoo/enterprise#25698
current behavior: There is an action menu to automatically postpone timeoff to the next month in the scope of the to defer mechanic. If the time off is set on the verge of two months, it's not correctly working. after this commit: When you postpone a time off spitted between two months, you only take the part on the first month to postpone it on the other month. taskID 2810565 Co-authored-by: Yannick Tivisse <yti@odoo.com> Forward-Port-Of: odoo/enterprise#26411 Forward-Port-Of: od
Original PR description
current behavior: There is an action menu to automatically postpone timeoff to the next month in the scope of the to defer mechanic. If the time off is set on the verge of two months, it's not correctly working. after this commit: When you postpone a time off spitted between two months, you only take the part on the first month to postpone it on the other month. taskID 2810565 Co-authored-by: Yannick Tivisse <yti@odoo.com> Forward-Port-Of: odoo/enterprise#26411 Forward-Port-Of: odoo/enterprise#26377
task-2758779 Forward-Port-Of: odoo/enterprise#26445 Forward-Port-Of: odoo/enterprise#24860
Original PR description
task-2758779 Forward-Port-Of: odoo/enterprise#26445 Forward-Port-Of: odoo/enterprise#24860
The goal is to improve the XAF export's performance in `l10n_nl_reports`. Currently, it can lead to timeouts on large databases. A test is added as well, to make sure the file generated is identical before and after the refactor. In `master`, the old template is removed so that the new one can replace it from now on. opw-2703534 Forward-Port-Of: odoo/enterprise#26456 Forward-Port-Of: odoo/enterprise#24422
Original PR description
The goal is to improve the XAF export's performance in `l10n_nl_reports`. Currently, it can lead to timeouts on large databases. A test is added as well, to make sure the file generated is identical before and after the refactor. In `master`, the old template is removed so that the new one can replace it from now on. opw-2703534 Forward-Port-Of: odoo/enterprise#26456 Forward-Port-Of: odoo/enterprise#24422
Added a test for the bug that was fixed in linked community PR to test for the case where component registration steps were not properly created upon backorder creation from the tablet view. Task: 2800975 Community PR: https://github.com/odoo/odoo/pull/87681 Forward-Port-Of: odoo/enterprise#26437
Original PR description
Added a test for the bug that was fixed in linked community PR to test for the case where component registration steps were not properly created upon backorder creation from the tablet view. Task: 2800975 Community PR: https://github.com/odoo/odoo/pull/87681 Forward-Port-Of: odoo/enterprise#26437
In the cohort graph inside the reporting in sale_subscription was throwing an error, as it used date_start for groupby. Since it's a computed field, we can't use groupby. To prevent the error, we changed the graph's start date to use date_order, as this field is stored. Forward-Port-Of: odoo/enterprise#26498
Original PR description
In the cohort graph inside the reporting in sale_subscription was throwing an error, as it used date_start for groupby. Since it's a computed field, we can't use groupby. To prevent the error, we changed the graph's start date to use date_order, as this field is stored. Forward-Port-Of: odoo/enterprise#26498
How to reproduce: - Insert a Pivot in a spraedsheet - Merge of the PIVOT/PIVOT.HEADER cells with a neighbouring cell (e.g. C3:D3) - select another cell then right click on the neighbouring cell (e.g. D3) - click on see records -> crash because we are trying to read the formula of a technically empty cell. We need to get the MainCell. task 2829721 Forward-Port-Of: odoo/enterprise#26482 Forward-Port-Of: odoo/enterprise#26441
Original PR description
How to reproduce: - Insert a Pivot in a spraedsheet - Merge of the PIVOT/PIVOT.HEADER cells with a neighbouring cell (e.g. C3:D3) - select another cell then right click on the neighbouring cell (e.g. D3) - click on see records -> crash because we are trying to read the formula of a technically empty cell. We need to get the MainCell. task 2829721 Forward-Port-Of: odoo/enterprise#26482 Forward-Port-Of: odoo/enterprise#26441
Before this PR: in helpdesk tour tip for drag&drop ticket to change stage of ticket also visible kanban view of the team. After this PR: tour tip for drag&drop ticket to change the stage of the ticket will only be visible in ticket kanban view. task-2758779 Forward-Port-Of: odoo/enterprise#26400 Forward-Port-Of: odoo/enterprise#24817
Original PR description
Before this PR: in helpdesk tour tip for drag&drop ticket to change stage of ticket also visible kanban view of the team. After this PR: tour tip for drag&drop ticket to change the stage of the ticket will only be visible in ticket kanban view. task-2758779 Forward-Port-Of: odoo/enterprise#26400 Forward-Port-Of: odoo/enterprise#24817
When using the salary configurator and changing the value of a select field, the "Some required fields are not filled" message is displayed even if the personal information have not been submitted yet. https://github.com/odoo/enterprise/pull/22844 pull request and https://github.com/odoo/enterprise/commit/1bdac0f1409c4faa24ba02136c1cf8a03f58a2fd commit introduce a call of checkFormValidity when there is a change of value of a select field task-2804859 Forward-Port-Of: odoo/enterprise#2
Original PR description
When using the salary configurator and changing the value of a select field, the "Some required fields are not filled" message is displayed even if the personal information have not been submitted yet. https://github.com/odoo/enterprise/pull/22844 pull request and https://github.com/odoo/enterprise/commit/1bdac0f1409c4faa24ba02136c1cf8a03f58a2fd commit introduce a call of checkFormValidity when there is a change of value of a select field task-2804859 Forward-Port-Of: odoo/enterprise#26524
The intrastat cbs export did not initially contain the product origin country, as it was not required. Changes since 2022 have lead to the code being used for the ICV flow. I've also changed the default unknown country code for the intrastat report to QV (an unknown European member state, rather than any unknown state). Forward-Port-Of: odoo/enterprise#26511 Forward-Port-Of: odoo/enterprise#26016
Original PR description
The intrastat cbs export did not initially contain the product origin country, as it was not required. Changes since 2022 have lead to the code being used for the ICV flow. I've also changed the default unknown country code for the intrastat report to QV (an unknown European member state, rather than any unknown state). Forward-Port-Of: odoo/enterprise#26511 Forward-Port-Of: odoo/enterprise#26016