Now that message list view exists, it should be used whenever possible, in
preparation of future commits.
Part of task-2801089
closesodoo/odoo#87113
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, implementation of `useXToModel` performed
essentially 2 updates in succession, even when ref or component
hasn't changed.
This is a problem, especially when 2 components in hierarchy make
use of `useXToComponents`, as this could lead to infinite loops.
closesodoo/odoo#83344
X-original-commit: 95cb2648484f8529947e2bed14d86a20e6ad37b6
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
To simplify messaging components in the future, they all need to have a similar
shape. It is done for messaging menu and activity notice in this commit, which
requires to move the waiting on "messaging becoming created" to a parent
non-messaging component.
closesodoo/odoo#80482
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, sometimes component do not properly
render changes in the models. Although the modeling is correct,
there is a problem in the component not re-rendering itself.
The shouldUpdateBasedOnProps component hook did not consider
update attempts that could be canceled. This commit adds this
consideration, so that it ensures component is eventually
rendered correctly
Task-2410314
Task-2705078
closesodoo/odoo#80877
X-original-commit: 12c77f52c5a16c95e57de31587d67eda4d582bde
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
Currently, in Discuss, the chat activates the drop zone when try to drag and
drop any user's avatar (or any text). The same thing happens if we do it in
the chat window or chatter.
After this commit:
The chat will not be activated drop zone if the drag is not actually
a file/a document.
Task-2590510
closesodoo/odoo#80464
X-original-commit: 0e2f46bc2cfd36dc3508a56601239c15e2301571
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = hr, hr_holidays, sms, snailmail, website_livechat
Message model incorrectly contained data related to a specific component (only
one) even though there can be multiple message components per message model.
This cascaded to adapting related component/models to the same principle.
closesodoo/odoo#76718closesodoo/odoo#77779
Related: odoo/enterprise#20964
Related: odoo/enterprise#21426
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Element.removeEventListener takes the same instance of the handler function
added with addEventListener. Giving it another function (either via a bind or an arrow)
wouldn't have any effect, leaving the handler actually in place.
This commit corrects some code in that direction.
X-original-commit: 82d710ee24ee01dad8fcf6a460fc064a498b5b02
Part-of: odoo/odoo#77285
*: hr_holidays, im_livechat, sms, snailmail, website_slides
Most messaging related components have common needs concerning
subscribing to model changes, and not needing to be rerendered unless
their props change. Previously, most components would call the hooks
"useModels" and "useShouldUpdateBasedOnProps" individually. Messaging
components also depend on one another quite a bit, requiring a lot of
explicit imports of other components. It would also be useful to be able
to have cyclic dependencies between component (eg Message renders a
component that allows to delete the message, and the delete component
renders the message in a confirmation dialog), but that doesn't work
with explicit imports (the odoo module system doesn't support cyclic
dependencies).
This commit adds a Component decorator that:
- Registers the component in an internal registry
- Makes all components in this registry available at render time to
components that have been registered in this way
- Calls the useModels and useShouldUpdateBasedOnProps hooks during
component initialization (setup)
enterprise PR: odoo/enterprise#20304closesodoo/odoo#74982
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Opportunity is taken to clean the various follow/join/invite methods into only
one `add_members` method.
Part of task-2360169
closesodoo/odoo#74425
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* = hr, hr_holidays, im_livechat, sms, snailmail, website_livechat,
website_slides
Exporting directly on the line of the class or variable definition is less lines
of code and less repetition (and risk or mistake).
Exporting with a name instead of default allows to catch typos more easily when
importing and ensures the same name is used for consistency (and ease of grep).
closesodoo/odoo#72597
Related: odoo/enterprise#19224
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = hr_holidays, im_livechat, website_livechat
A huge amount of components where rendered for no reason, notably when typing a
new message (at every key press), which significantly slowed down the interface.
There were 2 causes to this number of renders:
- OWL rendering all children automatically, even if their props didn't change,
unless `shouldUpdate` is overridden, which is now done.
- `useStore` selectors being way too generous in what they observed
task-2399731
closesodoo/odoo#64958
X-original-commit: a0472425251d429a0828eff1675c84b3f24527d8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The intent of the test was to count renders but it counted calls to `onUpdate`
which was the same "by luck", but the function was changed to be called more
often than renders to fix another bug.
Proper way to count renders (after the initial mount) is just to use `patched`.
closesodoo/odoo#64352
X-original-commit: c7375ebaf8d4baa6e02534425ed634c7264ce90f
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit the dropzone was relative to div.content. This would create
some bad position where the dropzone was covering the form view but not the
chatter.
task-2389929
closesodoo/odoo#62402
X-original-commit: bb650a9a1f4ff8280bd1e3467624991bc87517b9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This change highlighted issues with the async behavior of `useUpdate`, which
was no longer necessary and therefore reverted.
This in turn highlighted issue with animation of chat window unfolding, making
restoring of scroll position not work as intended due to the message list not
having its whole height available during some time after render. This animation
being minor (and even annoying in some cases) it was decided to remove it.
task-2387729
closesodoo/odoo#61962
X-original-commit: f22c34e7f61f7f8ac5b9ab7f9579cc4e6dd0e334
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when an invalid element was dropped (e.g. dragging a
mention) the drop area freeze and make the UI unusable.
task-2373971
closesodoo/odoo#61792
X-original-commit: 629b54dc1249c77d1e30240c0b5a91e22a1ae110
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The `_update` of some components must take place before the `_update`
of other (usually sibling) components that might directly influence their
layout. This is in particular the case for `_update` that are relying on height.
Prevent force save of scroll position if there are pending hints to adjust it,
and prevent pending hints from overriding new scroll value.
Prevent flicker with message date.
This should fix all known issues related to incorrectly saving or restoring
scroll position.
task-2344226
task-2358066
task-2369332
task-2372339
task-2373741
closesodoo/odoo#61791
X-original-commit: 2002c6a599a685f4a18fc670a9f7992c8d595c0f
Related: odoo/enterprise#14759
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Sébastien Theys