Single payslip creation now checks for missing work entries before allowing the payslip to be created. This prevents incorrect payroll documents and aligns individual payslip creation with existing batch payroll safeguards.

When creating a single payslip it is currently possible to do this with missing work entries, resulting in a faulty payslip being created. With this change we perform the same check that is done when generating payslips in batch (in the work entries overview) to make this impossible.

task-3055129

This change streamlines how Odoo handles certain page reloads and navigation actions by removing an unnecessary internal redirect helper. Users should not see a functional difference, but the web client code becomes easier to maintain and less prone to confusion around reload behavior.

The redirect function in the router exists only for the wait option. This option is only used in one case (client action home). We have therefore decided to remove the redirect function and to call browser.location.assign(...) directly.

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

Odoo's web module has been cleaned up by removing old checkbox and systray compatibility code that is no longer used. This reduces maintenance overhead and helps keep the interface codebase simpler without changing current user workflows.

This commit removes the legacy CustomCheckbox and the backward compatibility layer for the systray items. Both of them are no longer used.

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

The user can use arrows up/down to change the value of an input in the editor (inputs that handle numerical values). Unfortunately if this input does not trigger a preview (data-no-preview="true"), the modifications made by the user with arrow up/down are not saved. This commit solves this problem by notifying that the value has changed at the input blur (or on ENTER key press) if arrow up/down has been used. Details: Since we use text inputs in the editor, (even to manage numerical val

The user can use arrows up/down to change the value of an input in the
editor (inputs that handle numerical values). Unfortunately if this
input does not trigger a preview (data-no-preview="true"), the
modifications made by the user with arrow up/down are not saved. This
commit solves this problem by notifying that the value has changed at
the input blur (or on ENTER key press) if arrow up/down has been used.

Details:
Since we use text inputs in the editor, (even to manage numerical value)
the management of arrow up/down is done manually, so Javascript does not
consider the value of the input has changed and therefore does not
trigger the change event. Another solution would have been to say that
when we know that the input is going to manage a numeric value, we put
the type="number" on it but in this case, the change event is triggered
at each arrow up/down which breaks the fact that some inputs do not want
to have a preview.

Steps to reproduce the problem:
- Drop the Products block in a page
- Use arrow up/down to change the value of the Slider Speed input
- Save and Edit again
=> The change made with arrow up/down has not been saved.

task-2765868

Forward-Port-Of: odoo/odoo#88791

Very similar to the usecase in commit https://github.com/odoo/odoo/commit/dafe732e6874fbdd15dfd213b5c5c0cde93e534e - Install Accounting, Sales, Stock - Create a product category PC: - Costing method: FIFO - Inventory Valuation: Automated - Create a product P: - Type: Storable - Product Category: PC - Create a Sales Order SO with 1 x P at cost 10 - Confirm delivery - SO > Create Invoice > Post - SO > Return the delivery - Change product price from 10 to 6. - SO > Create Invoic

Very similar to the usecase in commit https://github.com/odoo/odoo/commit/dafe732e6874fbdd15dfd213b5c5c0cde93e534e

- Install Accounting, Sales, Stock
- Create a product category PC:
	- Costing method: FIFO
	- Inventory Valuation: Automated
- Create a product P:
    - Type: Storable - Product Category: PC
- Create a Sales Order SO with 1 x P at cost 10
- Confirm delivery
- SO > Create Invoice > Post
- SO > Return the delivery
- Change product price from 10 to 6.
- SO > Create Invoice (!!)
- The invoice will be marked as a credit note automatically
- Post the invoice

Issue:

The product is listed in the journal items, which is correct, but its value is 6 while it should be 10.

If we create the invoice from the Sales Order instead of adding a credit note, then the move lines will not be considered reversed, since they do not have an associated invoice.

Solution:

Consider the move type when deciding if the move line is reversed or not.

opw-3077772

Forward-Port-Of: odoo/odoo#112503
Forward-Port-Of: odoo/odoo#111035

The employee should be subscribed to their own record in order to receive communication send to them. TaskID: 2749585 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#112700 Forward-Port-Of: odoo/odoo#84772

The employee should be subscribed to their own record in order to
receive communication send to them.

TaskID: 2749585

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#112700
Forward-Port-Of: odoo/odoo#84772

## Current behaviour In the eCommerce, if you add a product that has a sale description (properly translated) in a website that is set in another language than the default for the company, the description of the product in the shopping cart was the default for the company, not the one set on the website. ## Expected behaviour Product description language should follow the website's language, in both the eCommerce, and in the shopping cart. ## Steps to reproduce - Install eCommerce - Ad

## Current behaviour
In the eCommerce, if you add a product that has a sale description (properly translated) in a website that is set in another language than the default for the company, the description of the product in the shopping cart was the default for the company, not the one set on the website.

## Expected behaviour
Product description language should follow the website's language, in both the eCommerce, and in the shopping cart.

## Steps to reproduce
- Install eCommerce
- Add a second language of choice and add it to the website
- On a product add a sale's description in both languages
- Logout, go on the e-shop on your product, switch the website to language 2
- Observe that the language of the description is indeed language 2
- Add it to cart, go in the cart.
- Observe that the language of the description is language 1, not 2.

## Reason for the problem
Since the cart is a `sales.order`, and each item in it is a `sale.order.line`, we use the language of the partner for the description. But by default the language of the public user is the same as the company, not the one from the current context, which would be the one from the website.

## Fix
We don't take the language of the partner, if that partner is the `public user`.

## Affected versions
- saas-15.2
- 16.0
- saas-16.1
- master
---
opw-3142666

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112658
Forward-Port-Of: odoo/odoo#112310

With this commit, when importing an account, we post the opening move only if it is draft. Steps to reproduce: - import a coa template -> an opening move has been created and posted - import an account -> Error: The entry MISC/XXXX/XX/XXXX (id XX) is already posted Issue happened because we try to post the opening move when entering in the account_account.load method. With this commit we post the opening move only if it's draft. opw-3105083 Forward-Port-Of: odoo/odoo#110071

With this commit, when importing an account,
we post the opening move only if it is draft.

Steps to reproduce:

- import a coa template
-> an opening move has been created and posted
- import an account
-> Error: The entry MISC/XXXX/XX/XXXX (id XX) is already posted

Issue happened because we try to post the opening move
when entering in the account_account.load method.
With this commit we post the opening move only if
it's draft.

opw-3105083

Forward-Port-Of: odoo/odoo#110071

Before this commit, when obtaining link URL suggestions, both the specific and the matching generic page were suggested. After this commit, only the most specific ones are kept in the suggested list. This commit also adapts the sitemap in the same way. In stable, a condition on a dedicated context key is used in case those methods were called with the goal of obtaining both generic and specific pages. In 16.0, those methods will always filter duplicates pages as it was supposed at fir

Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.

After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.

Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.

task-2968292

Forward-Port-Of: odoo/odoo#112693
Forward-Port-Of: odoo/odoo#111603

Some changes were made to the default/demo/test data to be more consistent: - Duplicates of "Paid Time Off" time off types are consolidated into one type (inluding year specific versions, ig "Paid Time Off 2019" - Annual Time Off is renamed back to Paid Time Off (both for the work entry type as the time off type) to be consistent everywhere. - All mentions of years in work entry types and time off types have been removed, as this is no longer relevant with the new allocation rules. -

Some changes were made to the default/demo/test data to be more consistent:
  - Duplicates of "Paid Time Off" time off types are consolidated into one type (inluding year specific versions, ig "Paid Time Off 2019"
  - Annual Time Off is renamed back to Paid Time Off (both for the work entry type as the time off type) to be consistent everywhere.
  - All mentions of years in work entry types and time off types have been removed, as this is no longer relevant with the new allocation rules.
  - Time off types in the default data have been explicitely made company agnostic, in order for them to be available to all companies and not just the one company that was select when installing hr_holidays. This was already the case for the be_payroll data, but not for the standard hr_holidays ones.
  - Various small cosmetic / functional fixes and simplifications (eg deduplication of data)
  - expense_other_input has been made country agnostic, in order for it to be available in all countries.

task-2978513

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#112173

Steps to reproduce the bug: - Get the website module. - Go to Settings > Website > Shipping. - Activate "On Site Payments & Picking" and save. - Go to the same setting again and click on "Customize Pickup Sites". - Pick the only delivery method that exists. - Inside the delivery method, select a warehouse of the current company and try to save. Issue: We won't be able to add a warehouse as the hidden field of the `company_id` is not set. Solution: We added the `company_id` fi

Steps to reproduce the bug:

- Get the website module.
- Go to Settings > Website > Shipping.
- Activate "On Site Payments & Picking" and save.
- Go to the same setting again and click on "Customize Pickup Sites".
- Pick the only delivery method that exists.
- Inside the delivery method, select a warehouse of the current company and try to save.

Issue:

We won't be able to add a warehouse as the hidden field of the `company_id` is not set.

Solution:

We added the `company_id` field in the `delivery_carrier.py` with the proper default value in order to get the right company.

opw-3097424

Forward-Port-Of: odoo/odoo#108356

Bug === The unlink of the <mail.mail> in the CRON is problematic because we accumulate a lot of records, and the CRON timeout. Task-3179157 Forward-Port-Of: odoo/odoo#112593 Forward-Port-Of: odoo/odoo#112307

Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we accumulate a lot of records, and the CRON timeout.

Task-3179157

Forward-Port-Of: odoo/odoo#112593
Forward-Port-Of: odoo/odoo#112307

With this commit, we add the shipping address to the invoice report when it is different from the invoicing address. We do the same way as in l10n_de_sale/models/sale.py and l10n_de_purchase/models/purchase.py, by adding the computed field l10n_de_addresses in account_move. opw-3090418 Forward-Port-Of: odoo/odoo#112643 Forward-Port-Of: odoo/odoo#108675

With this commit, we add the shipping address
to the invoice report when it is different from
the invoicing address.
We do the same way as in l10n_de_sale/models/sale.py
and l10n_de_purchase/models/purchase.py,
by adding the computed field l10n_de_addresses
in account_move.

opw-3090418

Forward-Port-Of: odoo/odoo#112643
Forward-Port-Of: odoo/odoo#108675

Steps to reproduce: - Install `mass_mailing` module - Go to mass_mailing and create a new mailing - Add a `from scratch` snippet - Add a `footer center` block - Save and click on `Mail Debug` tab Issue: The `Unsubscribe` link is not displayed in the preview. Cause: When converting the Bootstrap rows to table, we convert only the row's childrens that have a `col` class: https://github.com/odoo/odoo/blob/4ba61316a4dd212d6a572e3f9fcc250815b912f0/addons/web_edito

Steps to reproduce:

  - Install `mass_mailing` module
  - Go to mass_mailing and create a new mailing
  - Add a `from scratch` snippet
  - Add a `footer center` block
  - Save and click on `Mail Debug` tab

Issue:

  The `Unsubscribe` link is not displayed in the preview.

Cause:

  When converting the Bootstrap rows to table, we convert only the row's
  childrens that have a `col` class:
https://github.com/odoo/odoo/blob/4ba61316a4dd212d6a572e3f9fcc250815b912f0/addons/web_editor/static/src/js/backend/convert_inline.js#L12
https://github.com/odoo/odoo/blob/4ba61316a4dd212d6a572e3f9fcc250815b912f0/addons/web_editor/static/src/js/backend/convert_inline.js#L186

Solution:

  Add a `col-lg` CSS class on the first children of the row.

opw-3104011

Forward-Port-Of: odoo/odoo#112051

The PR #105579 introduce the call of `setupCollaboration` in `resetEditor` but did not remove the instructions in `resetEditor` that will be called in `setupCollaboration`. `this._getNewPtp` should be called by `setupCollaboration` as it is called after an asynchronous call. Additionally, `this._peerToPeerLoading` has to be awaited to prevent concurrency issues. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:

The PR #105579 introduce the call of `setupCollaboration` in `resetEditor` but did not remove the instructions in `resetEditor` that will be called in `setupCollaboration`.

`this._getNewPtp` should be called by `setupCollaboration` as it is called after an asynchronous call.

Additionally, `this._peerToPeerLoading` has to be awaited to prevent concurrency issues.

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#110150

This commit fixes the wrong label that was displayed when options are defined inside groups. Since displayValue was only looking for a label on choices set using the choices props, the getter was only returning the technical value for choices defined in groups. A test has been modified to verify that the correct label is shown, also on choices present inside of a group. This test previously asserted that, but only on choices given by the choices props. I encountered this bug when writing d

This commit fixes the wrong label that was displayed when options are defined inside groups. Since displayValue was only looking for a label on choices set using the choices props, the getter was only returning the technical value for choices defined in groups.

A test has been modified to verify that the correct label is shown, also on choices present inside of a group. This test previously asserted that, but only on choices given by the choices props.

I encountered this bug when writing documentation for the component

Forward-Port-Of: odoo/odoo#112656

SO portal page may have `[Order Again]` button. It's visible when there is at least one line with a product that might be reordered ("Added to cart"). This check fails with error "Expected singleton: product.product()" if first line is a section name or a note. Fix it by excluding such lines from `any(...)` check. STEPS: * Activate "Re-order From Portal" * Create and confirm order that has section (or a note) as a first line * Click `Customer Preview` smart button Call stack: ht

SO portal page may have `[Order Again]` button. It's visible when there is at least one line with a product that might be reordered ("Added to cart"). This check fails with error "Expected singleton: product.product()" if first line is a section name or a note.

Fix it by excluding such lines from `any(...)` check.

STEPS:

* Activate "Re-order From Portal"
* Create and confirm order that has section (or a note) as a first line
* Click `Customer Preview` smart button

Call stack:

https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/website_sale/views/templates.xml#L2466-L2471 https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/website_sale/models/sale_order.py#L420-L422 https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/website_sale/models/sale_order_line.py#L62-L64 https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/website_sale/models/product_product.py#L95-L97

Original commit that introduces re-order feature:

https://github.com/odoo/odoo/commit/fef332bec4447b7ce8d789af8773c56688f4958a

opw-3141929

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#111354

repro steps: 1) in any kanban view that is not grouped, use the arrow key to focus the last card 2) use the up key to focus the previous card 3) use the TAB key to focus any element inside that card 4) use the down key to try to navigate to the last card -> traceback The error comes from the fact that `focusNextCard` assumes that the focus is exactly on the card element and not on any of its children. This fix lets focusNextCard try to find the focus on the cards excactly, then if it can

repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card 2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card 4) use the down key to try to navigate to the last card -> traceback

The error comes from the fact that `focusNextCard` assumes that the focus is exactly on the card element and not on any of its children.

This fix lets focusNextCard try to find the focus on the cards excactly, then if it cannot, will try to find the focus on the children of the cards.

Implementation is in 2 phases because `HtmlElement.contains` AFAIK cannot be as performant as a strict equality of elements which is the general case.

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#112407

- Create an asset model without saving it - Click on one of the accounts of the asset model - You can now define an asset model for the account while you would want to have the one you just defined We want to let the user choose an asset model, when coming from an asset or from an asset model that we can chosse (so with an active_id). Only with an asset model that is not yet saved should we prevent the selection of the asset model. task-2937569 Forward-Port-Of: odoo/enterprise#35239

- Create an asset model without saving it
- Click on one of the accounts of the asset model
- You can now define an asset model for the account while you would want to have the one you just defined

We want to let the user choose an asset model, when coming from
an asset or from an asset model that we can chosse (so with an active_id).
Only with an asset model that is not yet saved should we prevent the selection of the asset model.

task-2937569

Forward-Port-Of: odoo/enterprise#35239

Steps to reproduce: - create a trial database with the Belgium accounting or l10n_be without demo data - Click on Accounting > reporting > partner VAT listing Issue: - Traceback Cause: When there is no demo data and therefor no partner_ids, `_report_custom_engine_partner_vat_listing` returns an empty list which causes problem further in the process. Solution: Instead of changing all `column_value`, returns the result of an empty result to avoid the error opw-3121418 Forward-Por

Steps to reproduce:
- create a trial database with the Belgium accounting or l10n_be without demo data
- Click on Accounting > reporting > partner VAT listing

Issue:
- Traceback

Cause:
When there is no demo data and therefor no partner_ids, `_report_custom_engine_partner_vat_listing` returns an empty list which causes problem further in the process.

Solution:
Instead of changing all `column_value`, returns the result of an empty result to avoid the error

opw-3121418

Forward-Port-Of: odoo/enterprise#36380

The generic tax report handler makes use of an sql query to gather the lines necessary to construct the closing entry. It is necessary to flush the fields that it makes use of to ensure the correct entry is generated. The domain for the query is inserted into the query using the output of the method '_get_options_domain'. Part of the domain is the 'parent_state', which was updated in v16 (from 'account_move.state'). This commit appends the 'parent_state' to the list of fields flushed on th

The generic tax report handler makes use of an sql query to gather the lines necessary to construct the closing entry. It is necessary to flush the fields that it makes use of to ensure the correct entry is generated.

The domain for the query is inserted into the query using the output of the method '_get_options_domain'. Part of the domain is the 'parent_state', which was updated in v16 (from 'account_move.state').

This commit appends the 'parent_state' to the list of fields flushed on the account.move.line model before the closing entry query is executed.

Forward-Port-Of: odoo/enterprise#37025

When importing a CODA file with a collective transfer, the statement line created takes the account number of the first counter party. It should remain blank. By checking the transaction family and the transaction code, we ensure that the counterparty Number remains empty. opw-3054312 Forward-Port-Of: odoo/enterprise#37083 Forward-Port-Of: odoo/enterprise#36243

When importing a CODA file with a collective
transfer, the statement line created takes
the account number of the first counter party.
It should remain blank.

By checking the transaction family and the
transaction code, we ensure that the
counterparty Number remains empty.

opw-3054312

Forward-Port-Of: odoo/enterprise#37083
Forward-Port-Of: odoo/enterprise#36243

before this commit, on creating a appraisal by clicking the appraisal calendar, the entered value in the quick add pop up is not recorded anywhere. after this commit, on clicking the appraisal calendar the form view will be opened to create the appraisal Forward-Port-Of: odoo/enterprise#37085

before this commit, on creating a appraisal by clicking the appraisal calendar, the entered value in the quick add pop up is not recorded anywhere.

after this commit, on clicking the appraisal calendar the form view will be opened to create the appraisal

Forward-Port-Of: odoo/enterprise#37085

When one of the 3 grid 48 tags is impacted positively (by making a credit note with a EU tax for example), it should reduce the corresponding total in the EC Sales List (48s44 => 44, 48s46T => 46T, 48s46L => 46L). This wasn't the case before this commit. Forward-Port-Of: odoo/enterprise#37063

When one of the 3 grid 48 tags is impacted positively (by making a credit note with a EU tax for example), it should reduce the corresponding total in the EC Sales List (48s44 => 44, 48s46T => 46T, 48s46L => 46L). This wasn't the case before this commit.

Forward-Port-Of: odoo/enterprise#37063

Previous to this commit, there was an access error raised when trying to create a team when all the other teams were archived. Unfortunately, it was not possible to have the rule in place and thus it was removed. In order to not have stages of multiple companies shown to the user, the stages menu is only shown in debug mode. These changes also make the helpdesk app more in line with the project app, which handles task stages similarly. Task-3177229 Forward-Port-Of: odoo/enterprise#368

Previous to this commit, there was an access error raised when trying to create a team when all the other teams were archived.

Unfortunately, it was not possible to have the rule in place and thus it was removed. In order to not have stages of multiple companies shown to the user, the stages menu is only shown in debug mode.

These changes also make the helpdesk app more in line with the project app, which handles task stages
similarly.

Task-3177229

Forward-Port-Of: odoo/enterprise#36868

Change the way options['order_column'] works. Instead of just having the index of the column to be sort (with potentially a - in front) now it is a dictionnary with the expression_label of the column to be sort and the direction of the sort (ASC or DESC). This fixes the issue were if we have columns not displayed because they are empty it will not break the sort since it is not based on an index (which can change) but on an expression label (which can **not** change). Forward-Port-Of: odoo/e

Change the way options['order_column'] works. Instead of just having the index of the column to be sort (with potentially a - in front) now it is a dictionnary with the expression_label of the column to be sort and the direction of the sort (ASC or DESC).

This fixes the issue were if we have columns not displayed because they are empty it will not break the sort since it is not based on an index (which can change) but on an expression label (which can **not** change).

Forward-Port-Of: odoo/enterprise#36582

This PR will fix some issues the mobile users can have while using Knowledge. [FIX] knowledge: always display hidden buttons on touch screens In Knowledge, some buttons are hidden by default and becomes visible on mouse hover. When the user uses a touch screen, the user will not be able to see those buttons and interact with them. This commit will add a new media query to ensure that the css rules hiding the buttons become active only when the user has the hover capability. The touch sc

This PR will fix some issues the mobile users can have while using Knowledge.

[FIX] knowledge: always display hidden buttons on touch screens

In Knowledge, some buttons are hidden by default and becomes visible on mouse hover. When the user uses a touch screen, the user will not be able to see those buttons and interact with them.

This commit will add a new media query to ensure that the css rules hiding the buttons become active only when the user has the hover capability. The touch screen users will then be able to see and interact with all buttons of Knowledge.

[FIX] knowledge: improve dropdown menu usability

Currently, there are two issues with the dropdown menus of Knowledge that makes them unusable on mobile devices:
- The first issue is that the dropdown menus are not responsive and can go off screen. To fix that, we will force the dropdown menu to have a maximal width of 100vw and we will automatically truncate the text of the share dropdown menu to ensure that it will never overflow the parent container.
- The second issue is that the dropdown menus can go under the editor toolbar of the editor which makes some dropdown items unreachable. To fix that, we will update the z-index of the dropdown menus to ensure that it will always appear above the editor toolbar.

[FIX] knowledge: disable drag and drop on article tree for mobiles

Currently, the NestedSortable library may capture the swipe gesture made over the article tree and may prevent the user from scrolling the page. This behavior can be really annoying when the tree takes the whole screen.

To avoid that, we will disable the NestedSortable library when the user uses a mobile device. That way, the swipe gesture will not be captured and the user can scroll the page easily. The mobile users can use the "Move To" modal to move an article.

task-2867059

Forward-Port-Of: odoo/enterprise#37029

It only make sense to edit the name of a Customer Invoice for fiduciaries. Hence, we will now only fill it when this mode is activated. Forward-Port-Of: odoo/enterprise#37078 Forward-Port-Of: odoo/enterprise#37040

It only make sense to edit the name of a Customer Invoice for fiduciaries. Hence, we will now only fill it when this mode is activated.

Forward-Port-Of: odoo/enterprise#37078
Forward-Port-Of: odoo/enterprise#37040

…ting group is activated before this commit, in budget analysis form view and search view analytic account was showing even if the analytic account group is not active after this commit, the analytic account field will be displaying only if analytic account group is activated Forward-Port-Of: odoo/enterprise#36294 Forward-Port-Of: odoo/enterprise#36246

…ting group is activated

before this commit, in budget analysis form view and search view analytic account was showing even if the analytic account group is not active

after this commit, the analytic account field will be displaying only if analytic account group is activated

Forward-Port-Of: odoo/enterprise#36294
Forward-Port-Of: odoo/enterprise#36246

There existed an issue when a user visited an appointment page on the website at a time such that current_time + minimum lead time was still in the same day but current_time + minimum lead time + apt duration was in the next day (overflowing 24 hours). In that case slots would be generated from that overflowed time to the end hour of the current slot, on the next day. Effectively on our instance, with appointments of 1 hour and a lead time of 12 hours visiting these appointments at 1

There existed an issue when a user visited an appointment page on the website at a time
such that current_time + minimum lead time was still in the same day 
but current_time + minimum lead time + apt duration 
was in the next day (overflowing 24 hours).
In that case slots would be generated from that overflowed time to the end hour 
of the current slot, on the next day.

Effectively on our instance, with appointments of 1 hour and a lead time of 12 hours
visiting these appointments at 11AM GMT+1(winter) would result in a number of time slots 
being duplicated.

Simply check that the date of the start datetime corresponds to the day being processed.

task-3111413

Forward-Port-Of: odoo/enterprise#35898

Purpose ======= Revert the unlink in batch of the <mail.mail>, and so update the query count tests. Task-3179157 See odoo/odoo/pull/112307 Forward-Port-Of: odoo/enterprise#37043 Forward-Port-Of: odoo/enterprise#36930

Purpose
=======
Revert the unlink in batch of the <mail.mail>, and so update the query count tests.

Task-3179157
See odoo/odoo/pull/112307

Forward-Port-Of: odoo/enterprise#37043
Forward-Port-Of: odoo/enterprise#36930

before this commit, in quality check form view, the uom was shown even if the multi units of measure is not active after this commit , the uom field will be showing only when multi uom is activated Forward-Port-Of: odoo/enterprise#36613 Forward-Port-Of: odoo/enterprise#36166

before this commit, in quality check form view, the uom was shown even if the multi units of measure is not active

after this commit , the uom field will be showing only when multi uom is activated

Forward-Port-Of: odoo/enterprise#36613
Forward-Port-Of: odoo/enterprise#36166

Some changes were made to the default/demo/test data to be more consistent: - Duplicates of "Paid Time Off" time off types are consolidated into one type (inluding year specific versions, ig "Paid Time Off 2019" - Annual Time Off is renamed back to Paid Time Off (both for the work entry type as the time off type) to be consistent everywhere. - All mentions of years in work entry types and time off types have been removed, as this is no longer relevant with the new allocation rules. -

Some changes were made to the default/demo/test data to be more consistent:
  - Duplicates of "Paid Time Off" time off types are consolidated into one type (inluding year specific versions, ig "Paid Time Off 2019"
  - Annual Time Off is renamed back to Paid Time Off (both for the work entry type as the time off type) to be consistent everywhere.
  - All mentions of years in work entry types and time off types have been removed, as this is no longer relevant with the new allocation rules.
  - Time off types in the default data have been explicitely made company agnostic, in order for them to be available to all companies and not just the one company that was select when installing hr_holidays. This was already the case for the be_payroll data, but not for the standard hr_holidays ones.
  - Various small cosmetic / functional fixes and simplifications (eg deduplication of data)
  - expense_other_input has been made country agnostic, in order for it to be available in all countries.

task-2978513

Forward-Port-Of: odoo/enterprise#36796

Steps to reproduce: - Go to the Documents app. - Click on any workspace - On the access rights set any group which the user has. - Then go to the documents where the user cannot access any of the buttons (like share). Currently, the user has access to the workspace but cannot share it. Now he can share it. task-3103506 Forward-Port-Of: odoo/enterprise#37056 Forward-Port-Of: odoo/enterprise#35758

Steps to reproduce:
- Go to the Documents app.
- Click on any workspace
- On the access rights set any group which the user has.
- Then go to the documents where the user cannot access any of the buttons (like share).

Currently, the user has access to the workspace but cannot share it. Now he can share it.

task-3103506

Forward-Port-Of: odoo/enterprise#37056
Forward-Port-Of: odoo/enterprise#35758