User login names are now handled in lowercase, so people can sign in even if they type uppercase letters in their email or username. This reduces failed login attempts and makes access more intuitive for customers and other users.

Description of the issue/feature this PR addresses:
- create a e-commerce website used by your grand mother or your grand father (for exemple :-) )
- create a user with this login many@gmail.com
- try to connect with MANY@GMAIL.COM
--> Issues it doesn't work

For better experience it should be logical that login is insensitive.

@odony 

https://github.com/odoo/odoo/pull/24517

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

New Odoo databases can now automatically fill in missing company details using the partner autocomplete service, based on the company email or website. This improves the first-use experience by making company records look more complete without overwriting existing user-entered information, except for the logo.

In order to make a wow effect right after DB install we enrich the base
company based on the given email address or company website at install.
In order to achieve that goal we use the partner_autocomplete service from
IAP. It uses free credits that are offered to new clients on saas platform.

Only the fields that are not filled yet are enriched to avoid erasing user
entered data, except logo. Indeed as partner_autocomplete is probably installed
as a core app (mail -> iap -> partner_autocomplete auto install chain) it is
unlikely that people already updated their company logo.

We consider that having a call to IAP consuming a token is ok for a standard
use case, especially that

  * if no iap service is configured call to IAP won't add much timing;
  * on Odoo SaaS free credits are given and company is enriched;
  * on custom SaaS with custom iap service, at db creation probably no
    credits are given and call will simply give no results back;

We decided to call IAP asynchronously at client web load. Session combined to
a boolean field on company model allows to do this call only once per company.
Doing this allows to avoid adding yet another post init hook. It also eases
behavior tweak through inheritance.

This call is limited to admin for obvious security reasons as well as
performance reason (limiting calls to external providers). As call will be
done once per company generally admin is the first person to log into the
its newly created Odoo.

In addition to enriching companies on the fly, we also enrich companies
when creating them. It allows to have an enrich on companies existing
before using autocomplete, and have results of enrich directly at create
for companies created after installing this module.

LINKS

Task ID-2322455
PR odoo/odoo#64600
PR odoo/upgrade#2086

Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>

Online store product search snippets can now show customer ratings and allow sorting or filtering by rating. Rating totals and averages are stored for faster browsing and more reliable ordering, helping shoppers compare products more easily.

The search product snippet can now display the rating of the products.

task-1961400

Event teams can now choose whether each event tag category is visible as a filter on the website event page. This lets businesses keep internal tags for reporting and organization without exposing them to website visitors.

PURPOSE
Allow users to use event tags both externally (filter on the /event page) as well as internally [NDLR: which is considered the "advanced mode"] (reports, filters, o-spreadsheets, ...).

SPECIFICATIONS

Current
User cannot decide the filter by tag category on website should be shown.

To be
Add a boolean field on event tag categories.
Default value is TRUE.
If true, the category is shown on event page in header in website
If false... Well, hide it!


LINKS

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

Financial reports now use a more consistent way to identify and manage report lines, aligning them with the accounting report framework. This should make future report improvements easier and help reduce inconsistencies across accounting reports without changing day-to-day workflows.

This also opens the doors to further refactoring of the caret options, once the existing account.report instances have all been converted to account.account.report.

Task 2347659

The Social app settings menu is now hidden unless debug mode is enabled, keeping advanced demo-related options out of the regular user interface. The demo option wording was clarified so users understand it requires demo data to be active before it can work.

Purpose
=======
We want to hide the settings menu in non-debug mode so the option
"Demo Module" is considered as an advanced feature.

Reword the option "enable demo", so the users know that they need the
demo data to be activated to make the option work.

Task 2253851

Accounting users can now more easily tell whether a journal entry comes from a payment or a bank statement line. New direct navigation helps users open the related payment or bank statement from Bank and Cash views, reducing confusion and saving time during reconciliation or review.

Increase the distinction between a journal entry linked to a bank
statement line and another one linked to a payment by adding a smart
button linked to them.

Also, improve the navigation from the Bank And Cash view to directly
open the linked bank statement line or payment.

Task id #2448618

Outbound payments now appear as negative amounts in the batch payment view. This makes the displayed total more accurate by reducing the total when money is going out, helping users understand the net payment position at a glance.

In batch payment view :
- show payments amount as negative when payment is outbound
- "Total" must also reflect this (negative amount decrease total)

Task: 2429361

Batch payment views now show outbound payment amounts as negative values. This makes totals easier to understand because outgoing payments reduce the displayed total instead of increasing it.

In batch payment view :
- show payments amount as negative when payment is outbound
- "Total" must also reflect this (negative amount decrease total)

Task: 2429361

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