Bug === Since 569d35bc2dd3f2071c084e81331af0afad981202 a fix have been provided to fix the vertical position of the emoji widget in mobile view. But the fix have been done in a wrong way and we should use the Odoo CSS class instead to detect mobile (and not a bootstrap media query). Task 2253851 Forward-Port-Of: odoo/odoo#64689

Bug
===
Since 569d35bc2dd3f2071c084e81331af0afad981202 a fix have been provided
to fix the vertical position of the emoji widget in mobile view.

But the fix have been done in a wrong way and we should use the Odoo CSS
class instead to detect mobile (and not a bootstrap media query).

Task 2253851

Forward-Port-Of: odoo/odoo#64689

As Fedora 32 was the current release when Odoo 14.0 was released, this should be the supported version. Also, a few old libs were still in mentioned in the packaging files. They flew under the radar because they never broke the packaging. This is not the case anymore, those libs disappeared from the Fedora repos. It seems that pyparsing is not used anymore since 5a1c06a19 and thus can be safely removed from `requirements.txt` too. pychart is not used anymore since 3425752ea. Fi

As Fedora 32 was the current release when Odoo 14.0 was released, this should be
the supported version.

Also, a few  old libs were still in mentioned in the packaging files.
They flew under the radar because they never broke the packaging.
This is not the case anymore, those libs disappeared from the Fedora
repos.

It seems that pyparsing is not used anymore since 5a1c06a19 and thus can
be safely removed from `requirements.txt` too.

pychart is not used anymore since 3425752ea.

Fixes #63719

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

Bug === Since e598e74648576e8812592583fa1a9dec65ead0d2 the action button "Launch" in the mailing form view was renamed. Therefor, the mass mailing tour is broken and need to be updated. Task 2446835 Forward-Port-Of: odoo/odoo#65047

Bug
===
Since e598e74648576e8812592583fa1a9dec65ead0d2 the action button "Launch"
in the mailing form view was renamed. Therefor, the mass mailing tour is
broken and need to be updated.

Task 2446835

Forward-Port-Of: odoo/odoo#65047

Steps: - As admin, go to Settings > Users & Companies > Users - Edit Mark Demo (demo) - In Human Resources > Attendances, select Manual Attendance or blank - As demo, go to My Profile - Click the smart button showing the hours worked for the last month - Remove all filters Bug: The demo user, who hasn't the rights to see the other employees attendances, can see them. Explanation: Every user must have the right to read attendances in order to see their own attendances. Not giving

Steps:
- As admin, go to Settings > Users & Companies > Users
- Edit Mark Demo (demo)
- In Human Resources > Attendances, select Manual Attendance or blank
- As demo, go to My Profile
- Click the smart button showing the hours worked for the last month
- Remove all filters

Bug:
The demo user, who hasn't the rights to see the other employees
attendances, can see them.

Explanation:
Every user must have the right to read attendances in order to see their
own attendances. Not giving the users the read rights in the security
record rule prevents the record rule from being applied when reading
attendances. This makes the read access rights the only rule and allows
everyone to see the attendances of the others.

This commit also fixes the default selected employee when going to the
attendances tree view on these paths:
- User
- Employee
- User > Employee

In fact, sometime, `active_id` is the ÌD of the user and not of the
employee. This leads to incorrect results since another employee's
attendances are shown.

Finally, this commit prevents users from creating attendances from other
apps since only attendance officers and above can have access to the
creation form within the Attendances app.

opw:2440117

Forward-Port-Of: odoo/odoo#64866

- Go to Point of Sale > Configuration > Settings & enable "Cash Rounding" - Configure POS: * Enable Invoicing * Enable "Cash Rounding" and "Only on cash methods" * Select 0.05 HALF-UP Rounding Method - Start POS session - Select a Product and change its Price to a value that should be rounded (i.e. $ 16.51) - Select a Customer - Proceed to Payment - Enable Invoice - Select Bank Payment method - Validate An error is raised: "Could not fully process the POS Order: Order / is not

- Go to Point of Sale > Configuration > Settings & enable "Cash Rounding"
- Configure POS:
  * Enable Invoicing
  * Enable "Cash Rounding" and "Only on cash methods"
  * Select 0.05 HALF-UP Rounding Method
- Start POS session
- Select a Product and change its Price to a value that should be rounded (i.e. $ 16.51)
- Select a Customer
- Proceed to Payment
- Enable Invoice
- Select Bank Payment method
- Validate
An error is raised: "Could not fully process the POS Order: Order / is not fully paid.".
And a popup is diplayed: "Please print the invoice from backend"

The issue comes from the fact that amount is also rounded for other payment methods
than cash, even if "Only on cash methods" has been enabled.

opw-2449222

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#65317
Forward-Port-Of: odoo/odoo#65297

During loading, the registry clears all `ormcache` data multiple times, in order to ensure consistency with the newly loaded module data. This is done by calling `self.clear_cache()`, with the side-effect of signalling to all other worker processes that the cache *needs* to be invalidated, which is untrue. If the other workers have any reason to reload their own registries, they will also clear their own cache in the process - there is no need to forcefully invalidate it globally. One c

During loading, the registry clears all `ormcache` data multiple times, in order to ensure consistency with the newly loaded module data.

This is done by calling `self.clear_cache()`, with the side-effect of signalling to all other worker processes that the cache *needs* to be invalidated, which is untrue.

If the other workers have any reason to reload their own registries, they will also clear their own cache in the process - there is no need to forcefully invalidate it globally.

One could think that combining the pre-fork mode with the `-d <db>` parameter would mitigate this issue, by making all workers inherit from a fully loaded registry, In reality it doesn't work, because they also inherit from the `cache_invalidated=True` flag, that was never cleared in the master process. So despite having a fully loaded registry, the newly forked workers will signal a cache invalidation upon serving their first request.

Further, in a multi-tenant setup with large numbers of databases, registries may be recycled and loaded much more frequently than new workers are starting, due to the limited registry LRU, amplifying this effect a bit.

~~

This patch directly clears the cache LRU without going through `clear_cache()`, avoiding setting the `cache_invalidated` flag of the registry, and thus not signalling to other workers.

This is similar to what was being done before 083c70bbb63f27839b2c9a4b549e216947bc4dd1, where the LRU was dropped like all other lazy properties.


**Edit:** Added a second commit with a complementary approach: `check_signaling()` can always reset the `cache_invalidated` flag at the beginning of each request, after verifying that it did indeed execute any invalidation. This ensures that any future "involuntary leak" of the `cache_invalidated` flag from the master process can never trigger the problem again.


PS: a future version of the `clear_caches()` API might take a parameter to decide whether signalling is desirable.

Forward-Port-Of: odoo/odoo#65303

When a user on website sends livechat feedbacks: - Good -> send an average smiley 😐 - Average -> send ?? instead of smiley This is because in e4a4ffb value of good (😊) was changed from 10 to 5, and value for average (😐) was changed from 5 to 3, but it was not refelcted in one part of the code. opw-2447246 Forward-Port-Of: odoo/odoo#65328

When a user on website sends livechat feedbacks:

- Good -> send an average smiley 😐
- Average -> send ?? instead of smiley

This is because in e4a4ffb value of good (😊) was changed from 10 to 5,
and value for average (😐) was changed from 5 to 3, but it was not
refelcted in one part of the code.

opw-2447246

Forward-Port-Of: odoo/odoo#65328

Before this commit dynamic snippet and dynamic carousel were always available. To reduce the number of available snippets for new users it was decided to make these two snippets available only in debug mode. Also, the dynamic products was displaying a message on drop indicating it had to be configured. After this commit dynamic snippet and dynamic carousel are available only in debug mode. Also, the dynamic products is pre-configured so that it is displayed as soon as it gets initially

Before this commit dynamic snippet and dynamic carousel were always
available. To reduce the number of available snippets for new users it
was decided to make these two snippets available only in debug mode.
Also, the dynamic products was displaying a message on drop indicating
it had to be configured.

After this commit dynamic snippet and dynamic carousel are available
only in debug mode. Also, the dynamic products is pre-configured so that
it is displayed as soon as it gets initially dropped.

task-2446024

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#65247
Forward-Port-Of: odoo/odoo#64982

When using the windows installer in French language, the `Hôte` label used to configure postgresql server does not display correctly. The LangString documentation does not specify how to use the special characters but after some tests, specifying a BOM for the nsi file seems to be the way to go. Forward-Port-Of: odoo/odoo#65354

When using the windows installer in French language, the `Hôte` label
used to configure postgresql server does not display correctly.

The LangString documentation does not specify how to use the special
characters but after some tests, specifying a BOM for the nsi file seems
to be the way to go.

Forward-Port-Of: odoo/odoo#65354

This commit of merge fix multiple issues in the dynamic routing. Fix RequestUID error in 308 redirect Support MissingError / unexisting ID in 308 redirect Correctly rewrite url on rendering by url_for for non editor user Related to opw-2420562 Forward-Port-Of: odoo/odoo#64397 Forward-Port-Of: odoo/odoo#64328

This commit of merge fix multiple issues in the dynamic routing.

Fix RequestUID error in 308 redirect
Support MissingError / unexisting ID in 308 redirect
Correctly rewrite url on rendering by url_for for non editor user

Related to opw-2420562

Forward-Port-Of: odoo/odoo#64397
Forward-Port-Of: odoo/odoo#64328

Steps to reproduce: 1. Go to Project App 2. Open and edit a task 3. Click on Customer => search more 5. Click on "Filters" 6. Click on "Group by" => The "Filters" and "Group by" dropdown are open at same time => bug Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way to prevent bs and owl dropdown to be open in the same time. But when the web-editor is present, the CSS selector used to match the opened modal ("search more" in this case) conflicts with the DOM c

Steps to reproduce:
1. Go to Project App
2. Open and edit a task
3. Click on Customer => search more
5. Click on "Filters"
6. Click on "Group by"
=> The "Filters" and "Group by" dropdown are open at same time => bug

Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way
to prevent bs and owl dropdown to be open in the same time.

But when the web-editor is present, the CSS selector used to match the
opened modal ("search more" in this case) conflicts with the DOM created
by the web-editor  (modals identified by the classes: .web-editor,
.note-picture-dialog, .note-link-dialog, .note-help-dialog).

To avoid this conflict, this commit uses a more restrictive CSS selector
to match only the first (active) opened modal (as web-editor doesn't
attach its modals at the root of the body).

Forward-Port-Of: odoo/odoo#65274

Two instances (database) of Odoo can't run with the same connection towards a banking institution. In case such a scenario happens, The duplicated database will receive an error. The problem is that users can't remove their connections on such db as an error is raised even when trying to delete the duplicated connection. This commit fixes this problem by ignoring - signature errors - account not found errors - provider data corrupted errors when trying to delete a connection. This will

Two instances (database) of Odoo can't run with the same connection
towards a banking institution. In case such a scenario happens,
The duplicated database will receive an error.
The problem is that users can't remove their connections on such db
as an error is raised even when trying to delete the duplicated
connection. This commit fixes this problem by ignoring
- signature errors
- account not found errors
- provider data corrupted errors
when trying to delete a connection. This will allow the user to remove
their record from their database and will keep the existing information
on the proxy.

Forward-Port-Of: odoo/enterprise#16057