This update removes unused chatbot-related code from the live chat area. It helps keep the system easier to maintain without changing the experience for users or customers.

Task-2891941

Live chat internals were updated to make the chat button behavior and chatbot test mode easier to configure. This helps future website live chat changes be added more consistently with limited direct impact on end users.

*: website_livechat

This will allow for newly introduced fields to be quite declarative immediately.

Task-2892011

Live Chat and Website Live Chat were updated to make new chat button and chatbot test data easier to define and reuse. This supports faster, more consistent rollout of future live chat behavior without changing the customer-facing experience immediately.

*: website_livechat

This will allow for newly introduced fields to be quite declarative immediately.

Task-2892034

The live chat module now organizes button display and chatbot state handling in a clearer way. This makes it easier to add and manage future live chat options while keeping the customer-facing experience stable.

This will allow for newly introduced fields to be quite declarative immediately.

Task-2892041

This update improves how the website live chat button connects to its chat channel. It helps make the live chat experience more reliable and easier to maintain without changing the visible workflow for visitors.

Task-2891875

The live chat button now determines chatbot behavior through clearer stored settings instead of scattered logic. This makes chatbot display and testing behavior more consistent across website live chat experiences, reducing maintenance risk while preserving the user-facing flow.

Task-2892067

The live chat module now supports defining new button and session-related settings more directly. This makes future improvements, such as chatbot state handling, easier to add and maintain without changing the customer-facing experience immediately.

This allows defining some new fields immediately in a declarative way, such as `LivechatButtonView/chatbotState`

Task-2892083

This update makes the live chat button easier to configure internally, allowing new live chat fields to be defined more quickly and consistently. It supports future enhancements such as chatbot state handling while keeping the visible customer experience largely unchanged.

This allows defining some new fields immediately in a declarative way, such as `LivechatButtonView/chatbotState`

Task-2892092

Live chat now manages chatbot-related session and test data in a more consistent, declarative way. This should make the chat button behavior easier to maintain and more reliable across website live chat scenarios, without changing the user-facing workflow.

Task-2892074

This update prepares the live chat area for a gradual modernization of its underlying interface code. It helps keep existing live chat behavior working while the system transitions to newer components, reducing migration risk without changing the customer-facing experience.

So that models can introduce models, that rely on legacy widgets
while code is being converted fully to using models and components

Task-2892617

The test setup for chatter features now opens real form views in the web client instead of using a simplified helper. This improves confidence in mail and eLearning behavior and helps unblock related development work without changing end-user functionality.

The createChatterContainer helper was used during tests to mount
a chatter container and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient and open a form view
containing a chatter.

enterprise: https://github.com/odoo/enterprise/pull/28684

The mail settings interface now gives users clearer guidance about what allowed mail gateway models do and which system setting they affect. The list view is simplified by removing a technical normalized email field and renaming the email label, making the screen easier to understand.

Purpose
=======
Add an action helper that explain what does the model and with which
system parameter it interacts.


Remove the normalized email from the list view and rename the label of
the email field.

Task-2885455

Demo sales orders using timesheets now create a single related project instead of duplicate projects. This keeps sample data simpler and more realistic, making demonstrations and testing easier to understand.

Since 12bc2ab, there are two projects created for each SO instead of one in the demo data.

This is because in the sale lines, one product creates a project with a template, but others create a project without a template, which creates two projects.

This PR adds a project template to the products without one to create a single project per SO.

Mail component tests now run in an environment closer to real user usage by mounting the full web client instead of a simplified test helper. This improves confidence in future mail changes and helps unblock related development work without directly changing user-facing features.

The createMessageComponent  helper was used during tests to mount
a message component  and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient so that the message component
can be mounted in its real environment.

enterprise: https://github.com/odoo/enterprise/pull/28720

The CRM app can now generate sample leads for performance and volume testing. This helps teams validate how CRM behaves with large numbers of leads before real-world usage grows.

Testing for enterprise mail message attachments now runs in an environment closer to how users actually experience the application. This reduces the risk of test-only behavior and helps unblock related improvements without changing day-to-day functionality.

The createMessageComponent  helper was used during tests to mount
a message component  and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient so that the message component
can be mounted in its real environment.

community: https://github.com/odoo/odoo/pull/94243

The test setup for chatter-related features now uses a fuller application flow instead of a simplified test-only container. This helps make automated testing closer to real user behavior and reduces the risk of future changes being blocked by unrealistic test assumptions.

*: account_invoice_extract, approvals, voip.

The createChatterContainer helper was used during tests to mount
a chatter container and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient and open a form view
containing a chatter.

community: https://github.com/odoo/odoo/pull/94175