[IMP] mail: registering main components via services #201771
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
seb-odoo
approved these changes
Mar 14, 2025
alexkuhn
reviewed
Mar 14, 2025
addons/mail/static/src/discuss/core/public_web/bus_connection_alert.js
Outdated
Show resolved
Hide resolved
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo#201504
maki-odoo
force-pushed
the
18.0-lazy_main_components-maki
branch
from
68a729f to
defc98b
Compare
|
@robodoo delegate+ r+ |
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Mar 17, 2025
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo/odoo#201504 closes odoo/odoo#201771 Related: odoo/enterprise#81462 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
tsm-odoo
added a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 18, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo#201771
robodoo
pushed a commit
that referenced
this pull request
Mar 18, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: #201771 closes #202329 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 18, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo#201771 X-original-commit: d4da098
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 18, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo#201771 X-original-commit: d4da098
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 18, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo#201771 X-original-commit: d4da098
robodoo
pushed a commit
that referenced
this pull request
Mar 19, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: #201771 closes #202410 X-original-commit: d4da098 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Mar 19, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: #201771 closes #202425 X-original-commit: d4da098 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Mar 19, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: #201771 closes #202418 X-original-commit: d4da098 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
omar-sherif9992
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 26, 2025
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo#201504 closes odoo#201771 Related: odoo/enterprise#81462 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
omar-sherif9992
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 26, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo#201771 closes odoo#202329 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Mar 27, 2025
The live chat module uses the chat hub inside its shadow root. To avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: odoo/odoo#201771 closes odoo/odoo#202329 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we create a public root, we do:
MainComponentsContainerIn a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already
available. The problem with the lazy loading chatter bundle is that one of the
services in the second step is responsible for loading that bundle. So while
the lazy bundle is loading, new services and main components are being added to
the registry.
The steps could become like this:
It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services.
This PR defines a new service for each main component that are added through the
chatter bundle to ensure that main components are registered when their
dependent services are deployed.
backport of #201504
Related to: odoo/enterprise#81462