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

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

Themes define records which are used as templates for the creation of base model records on theme installation on a website. E.g. a "theme.ir.attachment" record's purpose is to be a template for an "ir.attachment" record creation on theme installation on a website. Those final records have extra fields to indicate from which theme template they come from. If those records are ever to be duplicated, they should not duplicate those links to the theme templates otherwise it may cause issue

Themes define records which are used as templates for the creation of
base model records on theme installation on a website.
E.g. a "theme.ir.attachment" record's purpose is to be a template for an
"ir.attachment" record creation on theme installation on a website.

Those final records have extra fields to indicate from which theme
template they come from. If those records are ever to be duplicated,
they should not duplicate those links to the theme templates otherwise
it may cause issues when uninstalling/updating a theme (you want the
records linked to the theme to be deleted/updated but not the duplicated
ones, which do not act differently from user created ones).

Duplicate ones will be linked to the website anyway (just like "normal"
user created ones) and should only be automatically removed if that
website is deleted.

The issue is more visible from 14.0 where applying some modifications to
images via the editor (crop / filter / optimization / ...) will
duplicate the original image before modifying it.

Co-authored-by: Samuel Degueldre <sad@odoo.com>

Forward-Port-Of: odoo/odoo#63940

**PURPOSE** from 14.0 Go to the "How to choose the right hotel" blog post -> the title is white -> edit -> change some *content* text (not even the title) -> save -> the title is now black **LINKS** TaskID: 2387990 Closes https://github.com/odoo/odoo/pull/62004 Forward-Port-Of: odoo/odoo#62004

**PURPOSE**
from 14.0
Go to the "How to choose the right hotel" blog post -> the title is white -> edit -> change some *content* text (not even the title) -> save -> the title is now black

**LINKS**
TaskID: 2387990
Closes https://github.com/odoo/odoo/pull/62004

Forward-Port-Of: odoo/odoo#62004

Previously, the transparency color for shapes was not taken into account when handling the preview state transitions of the background shape snippet option. This caused strange behaviours where the shape transparency color would always get reset when it was a class color, either when changing to a different shape (expected, all shape colors should get reset) or when changing any other shape setting like other shape colors or flipping the shape (not expected). On the other hand, if the tra

Previously, the transparency color for shapes was not taken into account
when handling the preview state transitions of the background shape
snippet option. This caused strange behaviours where the shape
transparency color would always get reset when it was a class color,
either when changing to a different shape (expected, all shape colors
should get reset) or when changing any other shape setting like other
shape colors or flipping the shape (not expected). On the other hand, if
the transparency color was not a class color, it would always remain
untouched, when changing other shapes settings (expected) but also when
changing shape type (eg Origins 01 -> Blocks 02, unwanted).

This commit fixes that by cloning the entire shape container during
preview, and restoring it on preview-reset.

task-2380815

Forward-Port-Of: odoo/odoo#61903
Forward-Port-Of: odoo/odoo#61710

-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63518

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

Forward-Port-Of: odoo/odoo#63518

Problem ------- Recruitment pipe is design to work better if you archive the lost/refused candidate rather than moving them in a specific column this practice is reinforced by hr_referral. Therefore, the other application button should take into account archive applicant Solution -------- - count archived applicant - show archived applicant -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63501

Problem
-------
Recruitment pipe is design to work better if you archive the
lost/refused candidate rather than moving them in a specific column
this practice is reinforced by hr_referral.

Therefore, the other application button should take into account
archive applicant

Solution
--------

- count archived applicant
- show archived applicant


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

Forward-Port-Of: odoo/odoo#63501

When performing the onchange for the first time on a new record, if a field has a default value, it could be two times in the `todo` field list to compute. Forward-Port-Of: odoo/odoo#63983

When performing the onchange for the first time on a new record, if a field has a default value, it could be two times in the `todo` field list to compute.

Forward-Port-Of: odoo/odoo#63983

Behavior prior to this commit: - normally when editing the Scheduled Date on a MO, the date on the related stock moves is updated. However this does not happen once the MO is planned - if the date is edited and the MO is planned, the MO is automatically unplanned, but the date on the stock moves is not automatically updated Behavior after this commit: - the dates on the stock moves will automatically update, whether the MO is planned or not (since the MO will be unplan once

Behavior prior to this commit:

 - normally when editing the Scheduled Date on a MO, the date on the
 related stock moves is updated.  However this does not happen once the
 MO is planned
 - if the date is edited and the MO is planned, the MO is automatically
 unplanned, but the date on the stock moves is not automatically updated

Behavior after this commit:

 - the dates on the stock moves will automatically update, whether the
 MO is planned or not (since the MO will be unplan once it saves anyway
 if you update the date, there is no point in restricting those writes)

opw-2417108

Forward-Port-Of: odoo/odoo#63953
Forward-Port-Of: odoo/odoo#63652

This fixes an issue that occurs when marking fields to compute in the following situation: - it occurs before the actual modification, - a relational field is marked to compute, - the same field is traversed to inverse some dependency. When the marking occurs after the modification, the traversal of the field should actually recompute the field. However, if the marking occurs before the modification, the inversion of dependencies must be based on the current value of the field. Th

This fixes an issue that occurs when marking fields to compute in the
following situation:
 - it occurs before the actual modification,
 - a relational field is marked to compute,
 - the same field is traversed to inverse some dependency.

When the marking occurs after the modification, the traversal of the
field should actually recompute the field.  However, if the marking
occurs before the modification, the inversion of dependencies must be
based on the current value of the field.  This is the case with method
unlink(): we call method modified() to mark the fields that currently
depend on the records to be deleted, and the fields must be computed
only after the deletion!

Forward-Port-Of: odoo/odoo#63686
Forward-Port-Of: odoo/odoo#63293

Steps to reproduce the bug: -Let's consider two vendor bills VB1 and VB2 -VB1 and VB2 have both a PDF in attachment P1 and P2 respectively (the original bills from the suppliers) -Let's consider that P2 is encrypted - In the list view of vendor bills, select VB1 and VB2 and print original bills Bug: An error was raised because it is not possible to merge P2 with P1 as P2 is encrypted. opw:2389679 Forward-Port-Of: odoo/odoo#63921

Steps to reproduce the bug:

-Let's consider two vendor bills VB1 and VB2
-VB1 and VB2 have both a PDF in attachment P1 and P2 respectively (the original bills from the suppliers)
-Let's consider that P2 is encrypted
- In the list view of vendor bills, select VB1 and VB2 and print original bills

Bug:

An error was raised because it is not possible to merge P2 with P1 as P2 is encrypted.

opw:2389679

Forward-Port-Of: odoo/odoo#63921

The button "Group By" and "Measures" were untranslated opw-2421769 Forward-Port-Of: odoo/odoo#63995 Forward-Port-Of: odoo/odoo#63977

The button "Group By" and "Measures" were untranslated

opw-2421769

Forward-Port-Of: odoo/odoo#63995
Forward-Port-Of: odoo/odoo#63977

STEPS: * create fresh db with default lang fr_CH * install website * activate additional language, e.g. en_GB * set for website only one available language: fr_CH * for admin user set lang en_GB * open website and add form BEFORE: the form doesn't work, because action url is "/en_GB/website_form/" AFTER: action url is not changed WHY: 1. ``is_multilang_url`` returns ``True``, because there is no route ``/website_form/`` https://github.com/odoo/odoo/blob/0adcb9a09fe5714fe8

STEPS:
* create fresh db with default lang fr_CH
* install website
* activate additional language, e.g. en_GB
* set for website only one available language: fr_CH
* for admin user set lang en_GB
* open website and add form

BEFORE: the form doesn't work, because action url is "/en_GB/website_form/"

AFTER: action url is not changed

WHY:

1.

``is_multilang_url`` returns ``True``, because there is no route ``/website_form/``

https://github.com/odoo/odoo/blob/0adcb9a09fe5714fe8479df9450ddcefa7ba0688/addons/http_routing/models/ir_http.py#L233-L244

2.

Model name in action is added after rendering only, this is why ``is_multilang_url`` is
called with ``/website_form/`` and not real url

https://github.com/odoo/odoo/blob/0adcb9a09fe5714fe8479df9450ddcefa7ba0688/addons/website_form/static/src/js/website_form.js#L144

3.

As result we get error on trying to make request ``/en_GB/website_form/mail.mail``

---

opw-2413960

Forward-Port-Of: odoo/odoo#63690

Before this commit, we check if the bill_type in the project is equal to 'customer_type' but this field can only be either 'customer_task' or 'customer_project'. Thus, this condition will always be False. This commit changes the condition to check if the bill_type is equal to 'customer_project'. Then, this condition can be True if the project has a SOL and his bill_type field is equal to 'customer_project'. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/

Before this commit, we check if the bill_type in the project is equal
to 'customer_type' but this field can only be either 'customer_task' or
'customer_project'. Thus, this condition will always be False.

This commit changes the condition to check if the bill_type is equal to
'customer_project'. Then, this condition can be True if the project has
a SOL and his bill_type field is equal to 'customer_project'.

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

Forward-Port-Of: odoo/odoo#63988

Previously, if you double-clicked an image in the web editor with the intention to change it, but the image had already been optimized, and then repicked the same, already optimized image, the image would be optimized again even though it had not changed. This commit fixes that by making the media-dialog not trigger an image_changed event in those cases, and by leaving the initial image untouched. Linked to issue #57604 Forward-Port-Of: odoo/odoo#57910

Previously, if you double-clicked an image in the web editor with the
intention to change it, but the image had already been optimized, and
then repicked the same, already optimized image, the image would be
optimized again even though it had not changed. This commit fixes that
by making the media-dialog not trigger an image_changed event in those
cases, and by leaving the initial image untouched.

Linked to issue #57604

Forward-Port-Of: odoo/odoo#57910

Before this commit, we check if the bill_type in the project is equal to 'customer_type' but this field can only be either 'customer_task' or 'customer_project'. Thus, this condition will always be False. This commit changes the condition to check if the bill_type is equal to 'customer_project'. Then, this condition can be True if the project has a SOL and his bill_type field is equal to 'customer_project'. Forward-Port-Of: odoo/enterprise#15522

Before this commit, we check if the bill_type in the project is equal
to 'customer_type' but this field can only be either 'customer_task' or
'customer_project'. Thus, this condition will always be False.

This commit changes the condition to check if the bill_type is equal
to 'customer_project'. Then, this condition can be True if the project
has a SOL and his bill_type field is equal to 'customer_project'.

Forward-Port-Of: odoo/enterprise#15522

Source: https://www.sd.be/ellawebsite/fr/legalnews/65eba248-d923-414b-b429-1c1e17d55d91 Forward-Port-Of: odoo/enterprise#15520

Source:
https://www.sd.be/ellawebsite/fr/legalnews/65eba248-d923-414b-b429-1c1e17d55d91

Forward-Port-Of: odoo/enterprise#15520

Purpose ======= The withholding taxes have to be declared to the Federal State. - The taxes on the classic salary has to be declared on a 274.10 sheet. - The tax exemptions for researchers has to be declared on a: - 274.32 sheet for the doctors / civil engineers - 274.33 sheet for the masters - 274.34 sheet for the bachelors. - The tax on the intellectual property has to be declared on a 273S sheet. All those data should be exported on a XML file to be uploaded on the

Purpose
=======

The withholding taxes have to be declared to the Federal State.

- The taxes on the classic salary has to be declared on a 274.10 sheet.
- The tax exemptions for researchers has to be declared on a:
    - 274.32 sheet for the doctors / civil engineers
    - 274.33 sheet for the masters
    - 274.34 sheet for the bachelors.
- The tax on the intellectual property has to be declared on a 273S sheet.

All those data should be exported on a XML file to be uploaded on the state platform (FINPROF)

On the other hand, the accounting entries for all those transactions should be valid.


Specification
=============

All those commits ensure that:
- The generation of the needed XML,XLSX,PDF files are available
- The accounting entries are correctly generated for the monthly pay and the commissions payslips.
- Several issues are also fixed on the commits history.

See the specific commits for more information.

TaskIDS: 2383006, 2409438, 2419771, 2418002, 2421375

Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>

Forward-Port-Of: odoo/enterprise#15467
Forward-Port-Of: odoo/enterprise#15364

Forward-Port-Of: odoo/enterprise#15431

Forward-Port-Of: odoo/enterprise#15431

The generation of reports makes SQL queries without care for pending recomputations and updates. Forward-Port-Of: odoo/enterprise#15423 Forward-Port-Of: odoo/enterprise#15421

The generation of reports makes SQL queries without care for pending
recomputations and updates.

Forward-Port-Of: odoo/enterprise#15423
Forward-Port-Of: odoo/enterprise#15421

Strap down, this one is a mess: - Install hr_payroll with demo data - Uninstall hr_work_entry_contract (on which hr_payroll depends) - Reinstall hr_work_entry_contract -> The ORM will complain that the field 'contract_id' cannot be set to NOT NULL because NULL values exist. Here's a quick overview of the way in which these modules depend on each other: hr_work_entry <-- hr_work_entry_contract <-- hr_payroll hr_work_entry_contract will introduce the `contrac

Strap down, this one is a mess:
    - Install hr_payroll with demo data
    - Uninstall hr_work_entry_contract (on which hr_payroll depends)
    - Reinstall hr_work_entry_contract
    -> The ORM will complain that the field 'contract_id' cannot be set
    to NOT NULL because NULL values exist.

Here's a quick overview of the way in which these modules depend on each
other:

    hr_work_entry <-- hr_work_entry_contract <-- hr_payroll

hr_work_entry_contract will introduce the `contract_id` field on model
`hr.work.entry` which is required.

`hr_payroll` calls `generate_work_entries` in order to create demo
records of `hr.work.entry`, these `hr.work.entry` records use the
extended version of the model introduced by `hr_work_entry_contract`,
meaning the required `contract_id` is provided.

Since the demo records were created using a generic function on
`hr.employee`, no corresponding `ir.model.data` fields are generated,
thus when `hr_work_entry_contract` is uninstalled (i.e. `hr_payroll` is
uninstalled), the demo records are not unlinked, they linger in the
database and the `contract_id` column is dropped.

Upon reinstalling hr_work_entry_contract, the ORM will fail to set the
field `contract_id` to `NOT NULL` because of the existing demo data from
`hr_payroll`.

The best fix I could find for a stable version was to simulate the
behaviour of `generate_work_entries`, except instead of generating new
work entries it simply tries to match existing ones and update their
contract_id from NULL to a valid value during the column's
initialisation.

In master though, better fixes include, but are not limited to:
    - Not using a function to create demo data and instead creating
    records by hand in the XML file.
    - If using a function to create demo data, making sure to create the
    corresponding ir.model.data so that the ORM can do automatic cleanup
    upon uninstall.
    - Making `contract_id` on `hr.work.entry` not a required field.

Note that only the last of the three proposals would fix the scenario in
which a real customer in production has multiple existing
hr.work.entry and decides to install hr_work_entry_contract or
hr_payroll, and in fact this fix does not completely handle that
scenario either, it's a best effort that might work if a contract exists
for a given employee and it happens to be valid during the existing work
entries.

Forward-Port-Of: odoo/enterprise#15526

The card was not translated as the visitor language was not transmitted. With this commit, the route will be called with as `/fr_BE/social_push_notifications/fetch_push_configuration` and `fr_BE` will be set in the context, to translate the fallback sentences Forward-Port-Of: odoo/enterprise#15429

The card was not translated as the visitor language was not transmitted.

With this commit, the route will be called with as
`/fr_BE/social_push_notifications/fetch_push_configuration`
and `fr_BE` will be set in the context, to translate the fallback sentences

Forward-Port-Of: odoo/enterprise#15429

On a deferred expense, when editing the expense of a line, if at least one has been posted, the "Next Period Expense" field of the next lines won't be correctly computed. To reproduce the error: (Hint: use demo data) 1. Go to Accounting > Accounting > Management > Deferred Expenses 2. Create a new one, e.g.: - Original value: $10,000 - Acquisition Date: 01/01/2020 - Number of recognitions: 5 Months - Deferred Expense Journal: 141000 Prepayments - Expense Account: 961000 RD Expe

On a deferred expense, when editing the expense of a line, if at least
one has been posted, the "Next Period Expense" field of the next lines
won't be correctly computed.

To reproduce the error:
(Hint: use demo data)
1. Go to Accounting > Accounting > Management > Deferred Expenses
2. Create a new one, e.g.:
	- Original value: $10,000
	- Acquisition Date: 01/01/2020
	- Number of recognitions: 5 Months
	- Deferred Expense Journal: 141000 Prepayments
	- Expense Account: 961000 RD Expenses
	- Journal: Miscellaneous Operations (USD)
3. Save, Confirm
4. Select the first depreciation line, Post it
5. Refresh the page
6. Click on Edit
7. Select the second line to update it:
	- Set the Expense field to $1,000 (instead of $2,000)

=> The "Next Period Expense" field of the selected line is now $5,000
but it should be $7,000

The system based the computations on the `value_residual` field of the
deferred expense. Since one line has been posted, this field is worth
$8,000. It then removes the first entry ($2,000) and the new value for
the second line ($1,000). This is the reason why it displays $5,000.
Obviously, due to a cascade effect, the next lines will also be incorrect.

OPW-2409086

Forward-Port-Of: odoo/enterprise#15515
Forward-Port-Of: odoo/enterprise#15500

Issue - Install "Subscriptions" module - Set user language to "Arabic" - Go to Subscriptions -> Reporting -> Revenue KPIs Multiple traceback raised. Cause On update, JS send to backend date in arabic. Python 'datetime' library does not manage arabic date. Solution Convert date format for the "server" on js-side. In this case, it will also translate arabic numbers. opw-2421289 Forward-Port-Of: odoo/enterprise#15513 Forward-Port-Of: odoo/enterprise#15479

Issue

	- Install "Subscriptions" module
	- Set user language to "Arabic"
	- Go to Subscriptions -> Reporting -> Revenue KPIs

	Multiple traceback raised.

Cause

	On update, JS send to backend date in arabic.
	Python 'datetime' library does not manage arabic date.

Solution

	Convert date format for the "server" on js-side.
	In this case, it will also translate arabic numbers.

opw-2421289

Forward-Port-Of: odoo/enterprise#15513
Forward-Port-Of: odoo/enterprise#15479

Fine tuning of 83da5fe9f47c8e8c8a3d4e14f93b1757bf12ef10 Steps to reproduce: 1. Go to Employees 2. Archive an employee 3. Go to payroll module 4. Go Payslips / Batches 5. Create a new one, and click on Generate payslips button 6. Select Add a line, a list of employees will show up. Bug: The list includes archived employees, listed, directly, without using the archive filter. opw:2421663 Forward-Port-Of: odoo/enterprise#15508 Forward-Port-Of: odoo/enterprise#15502

Fine tuning of 83da5fe9f47c8e8c8a3d4e14f93b1757bf12ef10

Steps to reproduce:

1. Go to Employees
2. Archive an employee
3. Go to payroll module
4. Go Payslips / Batches
5. Create a new one, and click on Generate payslips button
6. Select Add a line, a list of employees will show up.

Bug:

The list includes archived employees, listed, directly, without using the archive filter.

opw:2421663

Forward-Port-Of: odoo/enterprise#15508
Forward-Port-Of: odoo/enterprise#15502

Behavior prior to this commit: When you open the Journal Items from a financial report (for example P&L report), then view one of the entries and go back (or reload the window with the journal items), a SQL error is shown: psycopg2.DataError: invalid input syntax for integer: "financial_report_group_4_21" LINE 1: ...company_id" in (1))) AND "account_account".id IN ('financial... Behavior after this commit: Able to go back to the journal items, or refresh the journal items

Behavior prior to this commit:

When you open the Journal Items from a financial report (for example P&L
report), then view one of the entries and go back (or reload the window
with the journal items), a SQL error is shown:

    psycopg2.DataError: invalid input syntax for integer: "financial_report_group_4_21"
    LINE 1: ...company_id" in (1))) AND "account_account".id IN ('financial...

Behavior after this commit:

Able to go back to the journal items, or refresh the journal items
window, without a SQL error

Note:

The error was caused by the fact that the `active_id` was defaulted to
the current view id, i.e. the report XML id, a string, but the action
(`action_move_line_select`) has a context of:
`{'search_default_account_id': [active_id]}`.  The system was thus
attempting to use the string "financial_report_group_4_21" as an account
id.  To work around the account id, as passed to the open_journal_items
method, was returned as `active_id` key in the result context.

opw-2416831

Forward-Port-Of: odoo/enterprise#15480

**Before this commit** **-->** Survey Feedback link is not added to activity description. **-->** Survey activity is not visible in chatter while asking feedback from Employee. **After this commit** **-->** Adding a link to survey activities which directly redirects to selected survey template's URL. **-->** Activity is visible in chatter after removing specific context on "Ask Feedback" from Employee. **LINKS** PR https://github.com/odoo/enterprise/pull/15198 Task-2354467

**Before this commit**

**-->** Survey Feedback link is not added to activity description.

**-->** Survey activity is not visible in chatter while asking feedback from Employee.

**After this commit**

**-->** Adding a link to survey activities which directly redirects to selected survey
template's URL.

**-->** Activity is visible in chatter after removing specific context on "Ask Feedback"
from Employee.

**LINKS**
PR https://github.com/odoo/enterprise/pull/15198
Task-2354467

Forward-Port-Of: odoo/enterprise#15198

Problem ------- Since the inheritance order is not garantuee between hr_timesheet.hr_timesheet_line_my_timesheet_search and timesheet_grid.timesheet_view_search the view timesheet_grid.hr_timesheet_line_inherit_my_timesheet_search that depends on the first one but hide a filter defined in the second one. In some case (ie: migrated database), this can lead to the following error: ValueError: Element '<filter name="my_team_timesheet">' cannot be located in parent view Solution ----

Problem
-------

Since the inheritance order is not garantuee between
hr_timesheet.hr_timesheet_line_my_timesheet_search and timesheet_grid.timesheet_view_search
the view timesheet_grid.hr_timesheet_line_inherit_my_timesheet_search
that depends on the first one but hide a filter defined in the second
one. In some case (ie: migrated database), this can lead to the
following error:

ValueError: Element '<filter name="my_team_timesheet">' cannot be located in parent view

Solution
--------
To make sure timesheet_grid.timesheet_view_search is loaded before
hr_timesheet.hr_timesheet_line_my_timesheet_search. Make the latter
inherit from the view define in timesheet_grid

Forward-Port-Of: odoo/enterprise#15236